Så här fungerar förtroenderelationer för skogar i Active Directory
Active Directory-domän Services (AD DS) ger säkerhet över flera domäner eller skogar via domän- och skogsförtroenderelationer. Innan autentisering kan ske mellan förtroenden måste Windows först kontrollera om domänen som begärs av en användare, dator eller tjänst har en förtroenderelation med domänen för det begärande kontot.
För att söka efter den här förtroenderelationen beräknar Windows säkerhetssystem en förtroendesökväg mellan domänkontrollanten (DC) för servern som tar emot begäran och en domänkontrollant i domänen för det begärande kontot.
Mekanismerna för åtkomstkontroll som tillhandahålls av AD DS och den distribuerade Windows-säkerhetsmodellen ger en miljö för driften av domän- och skogsförtroenden. För att dessa förtroenden ska fungera korrekt måste varje resurs eller dator ha en direkt förtroendesökväg till en domänkontrollant i domänen där den finns.
Förtroendesökvägen implementeras av tjänsten Net Logon med hjälp av en Autentiserad RPC-anslutning (Remote Procedure Call) till den betrodda domänmyndigheten. En skyddad kanal utökas även till andra AD DS-domäner via relationer med interdomänförtroende. Den här skyddade kanalen används för att hämta och verifiera säkerhetsinformation, inklusive säkerhetsidentifierare (SID) för användare och grupper.
Kommentar
Domain Services stöder flera riktningar för skogsförtroende, inklusive dubbelriktade förtroenden och enkelriktade förtroenden som kan vara inkommande eller utgående.
En översikt över hur förtroenden gäller för Domain Services finns i Skogsbegrepp och funktioner.
Kom igång med förtroenden i Domain Services genom att skapa en hanterad domän som använder skogsförtroenden.
Förtroenderelationsflöden
Flödet av säker kommunikation över förtroenden avgör elasticiteten hos ett förtroende. Hur du skapar eller konfigurerar ett förtroende avgör hur långt kommunikationen sträcker sig inom eller över skogar.
Kommunikationsflödet över förtroenden bestäms av förtroendets riktning. Förtroenden kan vara enkelriktade eller dubbelriktade och kan vara transitiva eller icke-transitiva.
Följande diagram visar att alla domäner i Träd 1 och Träd 2 har transitiva förtroenderelationer som standard. Därför kan användare i Träd 1 komma åt resurser i domäner i Träd 2 och användare i Träd 2 kan komma åt resurser i Träd 1 när rätt behörigheter tilldelas till resursen.
Enkelriktade och dubbelriktade förtroenden
Förtroenderelationer ger åtkomst till resurser kan vara enkelriktade eller dubbelriktade.
Ett enkelriktat förtroende är en enkelriktad autentiseringssökväg som skapats mellan två domäner. I ett enkelriktad förtroende mellan domän A och domän B kan användare i domän A komma åt resurser i domän B. Användare i domän B kan dock inte komma åt resurser i domän A.
Vissa enkelriktade förtroenden kan vara antingen icke-transitiva eller transitiva beroende på vilken typ av förtroende som skapas.
I ett dubbelriktad förtroende litar Domän A på domän B och Domän B litar på domän A. Den här konfigurationen innebär att autentiseringsbegäranden kan skickas mellan de två domänerna i båda riktningarna. Vissa dubbelriktade relationer kan vara icke-transitiva eller transitiva beroende på vilken typ av förtroende som skapas.
Alla domänförtroenden i en lokal AD DS-skog är dubbelriktade transitiva förtroenden. När en ny underordnad domän skapas skapas ett dubbelriktad, transitivt förtroende automatiskt mellan den nya underordnade domänen och den överordnade domänen.
Transitiva och icke-transitiva förtroenden
Transitivitet avgör om ett förtroende kan utökas utanför de två domäner som det skapades med.
- Ett transitivt förtroende kan användas för att utöka förtroenderelationer med andra domäner.
- Ett icke-transitivt förtroende kan användas för att neka förtroenderelationer med andra domäner.
Varje gång du skapar en ny domän i en skog skapas en dubbelriktad, transitiv förtroenderelation automatiskt mellan den nya domänen och dess överordnade domän. Om underordnade domäner läggs till i den nya domänen flödar förtroendesökvägen uppåt genom domänhierarkin och utökar den inledande förtroendesökvägen som skapats mellan den nya domänen och dess överordnade domän. Transitiva förtroenderelationer flödar uppåt genom ett domänträd när det bildas, vilket skapar transitiva förtroenden mellan alla domäner i domänträdet.
Autentiseringsbegäranden följer dessa förtroendesökvägar så att konton från alla domäner i skogen kan autentiseras av alla andra domäner i skogen. Med en enkel inloggningsprocess kan konton med rätt behörighet komma åt resurser i alla domäner i skogen.
Skogsförtroenden
Skogsförtroenden hjälper dig att hantera en segmenterad AD DS-infrastruktur och stödja åtkomst till resurser och andra objekt i flera skogar. Skogsförtroenden är användbara för tjänsteleverantörer, företag som genomgår fusioner eller förvärv, extranät för samarbetsföretag och företag som söker en lösning för administrativ autonomi.
Med hjälp av skogsförtroenden kan du länka två olika skogar till en enkelriktad eller dubbelriktad transitiv förtroenderelation. Med ett skogsförtroende kan administratörer ansluta två AD DS-skogar med en enda förtroenderelation för att ge en sömlös autentiserings- och auktoriseringsupplevelse i skogarna.
Ett skogsförtroende kan bara skapas mellan en skogsrotsdomän i en skog och en skogsrotsdomän i en annan skog. Skogsförtroenden kan bara skapas mellan två skogar och kan inte implicit utökas till en tredje skog. Det här beteendet innebär att om ett skogsförtroende skapas mellan skog 1 och skog 2 och ett annat skogsförtroende skapas mellan skog 2 och skog 3, har skog 1 inget implicit förtroende med skog 3.
Följande diagram visar två separata skogsförtroenderelationer mellan tre AD DS-skogar i en enda organisation.
Den här exempelkonfigurationen ger följande åtkomst:
- Användare i Skog 2 kan komma åt resurser i valfri domän i antingen Skog 1 eller Skog 3
- Användare i Skog 3 kan komma åt resurser i valfri domän i Skog 2
- Användare i Skog 1 kan komma åt resurser i valfri domän i Skog 2
Den här konfigurationen tillåter inte att användare i Skog 1 får åtkomst till resurser i Skog 3 eller vice versa. För att användare i både Skog 1 och Skog 3 ska kunna dela resurser måste ett dubbelriktad transitivt förtroende skapas mellan de två skogarna.
Om ett enkelriktat skogsförtroende skapas mellan två skogar kan medlemmar i den betrodda skogen använda resurser som finns i den betrodda skogen. Men förtroendet fungerar bara i en riktning.
När ett enkelriktat skogsförtroende till exempel skapas mellan skog 1 (den betrodda skogen) och skog 2 (den betrodda skogen):
- Medlemmar i Skog 1 har åtkomst till resurser i Skog 2.
- Medlemmar i Skog 2 kan inte komma åt resurser som finns i Skog 1 med samma förtroende.
Viktigt!
Microsoft Entra Domain Services stöder flera riktningar för skogsförtroenden.
Krav för skogsförtroende
Innan du kan skapa ett skogsförtroende måste du kontrollera att du har rätt DNS-infrastruktur (Domain Name System). Skogsförtroenden kan bara skapas när någon av följande DNS-konfigurationer är tillgänglig:
En enskild ROT-DNS-server är rot-DNS-servern för båda dns-namnrymderna i skogen – rotzonen innehåller delegeringar för vart och ett av DNS-namnrymderna och rottipsen för alla DNS-servrar inkluderar rot-DNS-servern.
När det inte finns någon delad DNS-rotserver och rot-DNS-servrarna i varje DNS-namnområde i skogen använder DNS-villkorliga vidarebefordrare för varje DNS-namnområde för att dirigera frågor om namn i det andra namnområdet.
Viktigt!
Alla Microsoft Entra Domain Services-skogar med ett förtroende måste använda den här DNS-konfigurationen. Att vara värd för ett annat DNS-namnområde än skogens DNS-namnområde är inte en funktion i Microsoft Entra Domain Services. Villkorsstyrda vidarebefordrare är rätt konfiguration.
När det inte finns någon delad DNS-rotserver och dns-rotservrarna i varje dns-namnområde i skogen används konfigureras DNS-sekundära zoner i varje DNS-namnområde för att dirigera frågor om namn i det andra namnområdet.
Om du vill skapa ett skogsförtroende i AD DS måste du vara medlem i gruppen Domänadministratörer (i skogens rotdomän) eller gruppen Företagsadministratörer i Active Directory. Varje förtroende tilldelas ett lösenord som administratörerna i båda skogarna måste känna till. Medlemmar i Företagsadministratörer i båda skogarna kan skapa förtroenden i båda skogarna samtidigt och i det här scenariot genereras ett lösenord som är kryptografiskt slumpmässigt automatiskt och skrivs för båda skogarna.
En hanterad domänskog stöder upp till fem envägs utgående skogsförtroenden till lokala skogar. Det utgående skogsförtroendet för Microsoft Entra Domain Services skapas i administrationscentret för Microsoft Entra. Det inkommande skogsförtroendet måste konfigureras av en användare med de behörigheter som tidigare antecknades i lokal Active Directory.
Förtroendeprocesser och interaktioner
Många transaktioner mellan domäner och mellan skogar är beroende av domän- eller skogsförtroenden för att kunna utföra olika uppgifter. I det här avsnittet beskrivs de processer och interaktioner som sker när resurser nås mellan förtroenden och autentiseringsreferenser utvärderas.
Översikt över autentiseringsreferensbearbetning
När en begäran om autentisering hänvisas till en domän måste domänkontrollanten i domänen avgöra om det finns en förtroenderelation med den domän som begäran kommer från. Riktningen för förtroendet och om förtroendet är transitivt eller icke-överförande måste också fastställas innan det autentiserar användaren för att få åtkomst till resurser i domänen. Autentiseringsprocessen mellan betrodda domäner varierar beroende på vilket autentiseringsprotokoll som används. Kerberos V5- och NTLM-protokollen bearbetar hänvisningar för autentisering till en domän på olika sätt
Kerberos V5-hänvisningsbearbetning
Kerberos V5-autentiseringsprotokollet är beroende av net-inloggningstjänsten på domänkontrollanter för klientautentisering och auktoriseringsinformation. Kerberos-protokollet ansluter till ett KDC (Online Key Distribution Center) och Active Directory-kontoarkivet för sessionsbiljetter.
Kerberos-protokollet använder också förtroenden för tjänster som beviljar biljetter mellan områden (TGS) och för att validera PRIVILEGE Attribute Certificates (PACs) över en skyddad kanal. Kerberos-protokollet utför endast autentisering mellan områden med Kerberos-sfärer som inte är av Windows-varumärke, till exempel en MIT Kerberos-sfär och behöver inte interagera med tjänsten Net Logon.
Om klienten använder Kerberos V5 för autentisering begär den ett ärende till servern i måldomänen från en domänkontrollant i sin kontodomän. Kerberos KDC fungerar som en betrodd mellanhand mellan klienten och servern och tillhandahåller en sessionsnyckel som gör det möjligt för de två parterna att autentisera varandra. Om måldomänen skiljer sig från den aktuella domänen följer KDC en logisk process för att avgöra om en autentiseringsbegäran kan hänvisas:
Är den aktuella domänen direkt betrodd av domänen på den server som begärs?
- Om ja, skicka klienten en hänvisning till den begärda domänen.
- Om nej går du till nästa steg.
Finns det en transitiv förtroenderelation mellan den aktuella domänen och nästa domän på förtroendesökvägen?
- Om ja, skicka klienten en hänvisning till nästa domän på förtroendesökvägen.
- Om nej skickar du ett meddelande om nekad inloggning till klienten.
NTLM-hänvisningsbearbetning
NTLM-autentiseringsprotokollet är beroende av net-inloggningstjänsten på domänkontrollanter för klientautentisering och auktoriseringsinformation. Det här protokollet autentiserar klienter som inte använder Kerberos-autentisering. NTLM använder förtroenden för att skicka autentiseringsbegäranden mellan domäner.
Om klienten använder NTLM för autentisering går den första autentiseringsbegäran direkt från klienten till resursservern i måldomänen. Den här servern skapar en utmaning som klienten svarar på. Servern skickar sedan användarens svar till en domänkontrollant i sin datorkontodomän. Den här domänkontrollanten kontrollerar användarkontot mot dess databas för säkerhetskonton.
Om kontot inte finns i databasen avgör domänkontrollanten om du vill utföra direktautentisering, vidarebefordra begäran eller neka begäran med hjälp av följande logik:
Har den aktuella domänen en direkt förtroenderelation med användarens domän?
- Om ja skickar domänkontrollanten klientens autentiseringsuppgifter till en domänkontrollant i användarens domän för direktautentisering.
- Om nej går du till nästa steg.
Har den aktuella domänen en transitiv förtroenderelation med användarens domän?
- Om ja skickar du autentiseringsbegäran vidare till nästa domän i förtroendesökvägen. Den här domänkontrollanten upprepar processen genom att kontrollera användarens autentiseringsuppgifter mot sin egen databas för säkerhetskonton.
- Om nej skickar du ett meddelande om nekad inloggning till klienten.
Kerberos-baserad bearbetning av autentiseringsbegäranden över skogsförtroenden
När två skogar är anslutna av ett skogsförtroende kan autentiseringsbegäranden som görs med Kerberos V5- eller NTLM-protokoll dirigeras mellan skogar för att ge åtkomst till resurser i båda skogarna.
När ett skogsförtroende först upprättas samlar varje skog in alla betrodda namnområden i partnerskogen och lagrar informationen i ett betrott domänobjekt. Betrodda namnområden omfattar domännamn, UPN-suffix (User Principal Name), SPN-suffix (Service Principal Name) och SID-namnområden (Security ID) som används i den andra skogen. TDO-objekt replikeras till den globala katalogen.
Kommentar
Alternativa UPN-suffix för förtroenden stöds inte. Om en lokal domän använder samma UPN-suffix som Domain Services måste inloggningen använda sAMAccountName.
Innan autentiseringsprotokoll kan följa skogsförtroendesökvägen måste tjänstens huvudnamn (SPN) för resursdatorn matchas till en plats i den andra skogen. Ett SPN kan vara ett av följande namn:
- DNS-namnet på en värd.
- DNS-namnet på en domän.
- Det unika namnet på ett tjänstanslutningspunktobjekt.
När en arbetsstation i en skog försöker komma åt data på en resursdator i en annan skog kontaktar Kerberos-autentiseringsprocessen domänkontrollanten för en tjänstbiljett till SPN för resursdatorn. När domänkontrollanten frågar den globala katalogen och fastställer att SPN inte finns i samma skog som domänkontrollanten skickar domänkontrollanten en hänvisning för sin överordnade domän tillbaka till arbetsstationen. Då frågar arbetsstationen den överordnade domänen om tjänstbiljetten och fortsätter att följa referenskedjan tills den når domänen där resursen finns.
Följande diagram och steg innehåller en detaljerad beskrivning av Kerberos-autentiseringsprocessen som används när datorer som kör Windows försöker komma åt resurser från en dator som finns i en annan skog.
User1 loggar in på Workstation1 med autentiseringsuppgifter från europe.tailspintoys.com domän. Användaren försöker sedan komma åt en delad resurs på FileServer1 i den usa.wingtiptoys.com skogen.
Workstation1 kontaktar Kerberos KDC på en domänkontrollant i domänen ChildDC1 och begär en tjänstbiljett för FileServer1 SPN.
ChildDC1 hittar inte SPN i sin domändatabas och frågar den globala katalogen för att se om några domäner i den tailspintoys.com skogen innehåller det här SPN:et. Eftersom en global katalog är begränsad till en egen skog, hittas inte SPN.
Den globala katalogen kontrollerar sedan databasen för information om eventuella skogsförtroenden som upprättas med dess skog. Om det hittas jämförs namnsuffixen som anges i TDO (Forest Trust Trusted Domain Object) med suffixet för mål-SPN för att hitta en matchning. När en matchning hittas ger den globala katalogen en routningstips tillbaka till ChildDC1.
Routningstips hjälper dig att dirigera autentiseringsbegäranden mot målskogen. Tips används bara när alla traditionella autentiseringskanaler, till exempel lokal domänkontrollant och sedan global katalog, inte hittar ett SPN.
ChildDC1 skickar en hänvisning för sin överordnade domän tillbaka till Workstation1.
Workstation1 kontaktar en domänkontrollant i ForestRootDC1 (dess överordnade domän) för en hänvisning till en domänkontrollant (ForestRootDC2) i skogens rotdomän för den wingtiptoys.com skogen.
Workstation1 kontaktar ForestRootDC2 i den wingtiptoys.com skogen för en tjänstbiljett till den begärda tjänsten.
ForestRootDC2 kontaktar sin globala katalog för att hitta SPN och den globala katalogen hittar en matchning för SPN och skickar tillbaka den till ForestRootDC2.
ForestRootDC2 skickar sedan hänvisningen till usa.wingtiptoys.com tillbaka till Workstation1.
Workstation1 kontaktar KDC på ChildDC2 och förhandlar om biljetten för User1 för att få åtkomst till FileServer1.
När Workstation1 har en tjänstbiljett skickar den tjänstbiljetten till FileServer1, som läser Användar1:s säkerhetsautentiseringsuppgifter och skapar en åtkomsttoken i enlighet med detta.
Betrott domänobjekt
Varje domän- eller skogsförtroende i en organisation representeras av ett TDO (Trusted Domain Object) som lagras i systemcontainern inom dess domän.
TDO-innehåll
Informationen i en TDO varierar beroende på om en TDO har skapats av ett domänförtroende eller av ett skogsförtroende.
När ett domänförtroende skapas representeras attribut som DNS-domännamn, domän-SID, förtroendetyp, förtroendetransitivitet och det ömsesidiga domännamnet i TDO:t. TDO:er för skogsförtroende lagrar ytterligare attribut för att identifiera alla betrodda namnområden från partnerskogen. Dessa attribut omfattar domännamn, UPN-suffix (User Principal Name), SPN-suffix (Service Principal Name) och SID-namnområden (Security ID).
Eftersom förtroenden lagras i Active Directory som TDO:er har alla domäner i en skog kunskap om de förtroenderelationer som finns i hela skogen. På samma sätt har skogsrotsdomänerna i varje skog kunskap om de förtroenderelationer som finns i alla domäner i betrodda skogar när två eller flera skogar kopplas samman via skogsförtroenden.
Ändringar av TDO-lösenord
Båda domänerna i en förtroenderelation delar ett lösenord som lagras i TDO-objektet i Active Directory. Som en del av kontounderhållsprocessen ändrar den betrodda domänkontrollanten lösenordet som lagras i TDO var 30:e dag. Eftersom alla dubbelriktade förtroenden faktiskt är två enkelriktade förtroenden som går i motsatta riktningar sker processen två gånger för dubbelriktade förtroenden.
Ett förtroende har en betrodd och betrodd sida. På den betrodda sidan kan alla skrivbara domänkontrollanter användas för processen. På förtroendesidan utför PDC-emulatorn lösenordsändringen.
Om du vill ändra ett lösenord slutför domänkontrollanterna följande process:
Den primära domänkontrollanten (PDC) i den betrodda domänen skapar ett nytt lösenord. En domänkontrollant i den betrodda domänen initierar aldrig lösenordsändringen. Den initieras alltid av pdc-emulatorn med förtroende.
PDC-emulatorn i den betrodda domänen anger fältet OldPassword i TDO-objektet till det aktuella NewPassword-fältet .
PDC-emulatorn i den betrodda domänen anger fältet NewPassword för TDO-objektet till det nya lösenordet. Om du behåller en kopia av det tidigare lösenordet kan du återgå till det gamla lösenordet om domänkontrollanten i den betrodda domänen inte kan ta emot ändringen, eller om ändringen inte replikeras innan en begäran görs som använder det nya förtroendelösenordet.
PDC-emulatorn i den betrodda domänen gör ett fjärranrop till en domänkontrollant i den betrodda domänen och ber den att ange lösenordet för förtroendekontot till det nya lösenordet.
Domänkontrollanten i den betrodda domänen ändrar förtroendelösenordet till det nya lösenordet.
På varje sida av förtroendet replikeras uppdateringarna till de andra domänkontrollanterna i domänen. I den betrodda domänen utlöser ändringen en brådskande replikering av det betrodda domänobjektet.
Lösenordet har nu ändrats på båda domänkontrollanterna. Normal replikering distribuerar TDO-objekten till de andra domänkontrollanterna i domänen. Det är dock möjligt för domänkontrollanten i den betrodda domänen att ändra lösenordet utan att uppdatera en domänkontrollant i den betrodda domänen. Det här scenariot kan inträffa eftersom det inte gick att upprätta en skyddad kanal som krävs för att bearbeta lösenordsändringen. Det är också möjligt att domänkontrollanten i den betrodda domänen kanske inte är tillgänglig någon gång under processen och kanske inte får det uppdaterade lösenordet.
För att hantera situationer där lösenordsändringen inte har kommunicerats ändrar domänkontrollanten i den betrodda domänen aldrig det nya lösenordet om det inte har autentiserats (konfigurerat en skyddad kanal) med det nya lösenordet. Det här beteendet är anledningen till att både gamla och nya lösenord sparas i TDO-objektet för den betrodda domänen.
En lösenordsändring slutförs inte förrän autentiseringen med lösenordet har slutförts. Det gamla, lagrade lösenordet kan användas via den skyddade kanalen tills domänkontrollanten i den betrodda domänen tar emot det nya lösenordet, vilket möjliggör oavbruten tjänst.
Om autentiseringen med det nya lösenordet misslyckas eftersom lösenordet är ogiltigt försöker den betrodda domänkontrollanten autentisera med det gamla lösenordet. Om det autentiseras med det gamla lösenordet återupptas lösenordsändringsprocessen inom 15 minuter.
Uppdateringar av betrodda lösenord måste replikeras till domänkontrollanterna på båda sidor av förtroendet inom 30 dagar. Om förtroendelösenordet ändras efter 30 dagar och en domänkontrollant bara har N-2-lösenordet kan det inte använda förtroendet från förtroendesidan och kan inte skapa en säker kanal på den betrodda sidan.
Nätverksportar som används av förtroenden
Eftersom förtroenden måste distribueras över olika nätverksgränser kan de behöva sträcka sig över en eller flera brandväggar. I så fall kan du antingen använda tunnelförtroendetrafik över en brandvägg eller öppna specifika portar i brandväggen så att trafiken kan passera.
Viktigt!
Active Directory-domän Services stöder inte begränsning av Active Directory RPC-trafik till specifika portar.
Läs avsnittet Windows Server 2008 och senare versioner i Microsoft Support-artikeln Så här konfigurerar du en brandvägg för Active Directory-domäner och -förtroenden för att lära dig mer om de portar som behövs för ett skogsförtroende.
Stöd för tjänster och verktyg
För att stödja förtroenden och autentisering används några ytterligare funktioner och hanteringsverktyg.
Net-inloggning
Tjänsten Net Logon har en skyddad kanal från en Windows-baserad dator till en domänkontrollant. Det används också i följande förtroenderelaterade processer:
Förtroendekonfiguration och hantering – Net Logon hjälper till att upprätthålla förtroendelösenord, samlar in förtroendeinformation och verifierar förtroenden genom att interagera med LSA-processen och TDO.
För skogsförtroenden innehåller förtroendeinformationen FTInfo-posten (Forest Trust Information), som innehåller den uppsättning namnområden som en betrodd skog påstår sig hantera, kommenterad med ett fält som anger om varje anspråk är betrott av den betrodda skogen.
Autentisering – Tillhandahåller användarautentiseringsuppgifter via en skyddad kanal till en domänkontrollant och returnerar domän-SID och användarrättigheter för användaren.
Plats för domänkontrollant – Hjälper till med att hitta eller hitta domänkontrollanter i en domän eller mellan domäner.
Direktverifiering – Autentiseringsuppgifter för användare i andra domäner bearbetas av Net-inloggning. När en betrodd domän behöver verifiera en användares identitet skickar den användarens autentiseringsuppgifter via Net-inloggning till den betrodda domänen för verifiering.
Pac-verifiering (Privilege Attribute Certificate) – När en server som använder Kerberos-protokollet för autentisering måste verifiera PAC i en tjänstbiljett skickar den PAC över den säkra kanalen till sin domänkontrollant för verifiering.
Lokal säkerhetskontroll
LSA (Local Security Authority) är ett skyddat undersystem som underhåller information om alla aspekter av lokal säkerhet i ett system. LSA kallas lokalt säkerhetsprincip och tillhandahåller olika tjänster för översättning mellan namn och identifierare.
LSA-säkerhetsundersystemet tillhandahåller tjänster i både kernelläge och användarläge för validering av åtkomst till objekt, kontroll av användarbehörigheter och generering av granskningsmeddelanden. LSA ansvarar för att kontrollera giltigheten för alla sessionsbiljetter som presenteras av tjänster i betrodda eller ej betrodda domäner.
Hanteringsverktyg
Administratörer kan använda Active Directory-domän och förtroenden, Netdom och Nltest för att exponera, skapa, ta bort eller ändra förtroenden.
- Active Directory-domän och förtroenden är Microsoft Management Console (MMC) som används för att administrera domänförtroenden, domän- och skogsfunktionsnivåer och suffix för användarens huvudnamn.
- Kommandoradsverktygen Netdom och Nltest kan användas för att hitta, visa, skapa och hantera förtroenden. Dessa verktyg kommunicerar direkt med LSA-utfärdaren på en domänkontrollant.
Nästa steg
Information om hur du kommer igång med att skapa en hanterad domän med ett skogsförtroende finns i Skapa och konfigurera en domän som hanteras av Domain Services. Du kan sedan skapa ett skogsförtroende för utgående trafik till en lokal domän.