Så här fungerar förtroenderelationer för skogar i Active Directory (förhandsversion)

Active Directory Domain 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örtroendeväg till en domänkontrollant i domänen där den finns.

Tjänsten Net Logon implementerar förtroendesökvägen med hjälp av en autentiserad RPC-anslutning (Remote Procedure Call) till den betrodda domänmyndigheten. Skyddad kanal utökas även till andra AD DS-domäner via domänöverskridande förtroenderelationer. 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.

Anteckning

Domain Services stöder flera riktningar för skogsdomänförtroende, inklusive en aktuell förhandsversion av dubbelriktade förtroenden och enkelriktade förtroenden som kan vara antingen inkommande eller utgående.

För en översikt över hur förtroenden tillämpas i Domäntjänster, se Skogsbegrepp och funktioner.

För att komma igång med förtroenden i Domain Services 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.

Riktningen på förtroendet avgör kommunikationsflödet genom förtroenden. Förtroenden kan vara enkelriktade eller dubbelriktade och kan vara transitiva eller icke-transitiva.

Följande diagram visar att alla domäner i Tree 1 och Tree 2 har transitiva förtroenderelationer som standard. Därför kan användare i Tree 1 komma åt resurser i domäner i Tree 2 och användare i Tree 2 komma åt resurser i Tree 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 ensidig autentiseringsväg som skapas mellan två domäner. I ett enkelriktat förtroende mellan Domän A och Domän Bkan 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 dubbelriktat förtroende litar Domain A på Domain B och Domain B på Domain 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.

Skogsstiftelser

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 2och ett annat skogsförtroende skapas mellan Skog 2 och Skog 3, Skog 1 inte har ett implicit förtroende med Forest 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 alla domäner i Skog 2

Den här konfigurationen tillåter inte att användare i Forest 1 får åtkomst till resurser i Forest 3 eller vice versa. För att användare i både Forest 1 och Forest 3 ska kunna dela resurser måste ett dubbelriktat transitivt förtroende skapas mellan de två skogar.

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.

Om du till exempel skapar ett enkelriktat skogsförtroende mellan Skog 1 (den betrodda skogen) och Skog 2 (den förtroendegivande skogen):

• Medlemmar i Forest 1 kan komma åt resurser i Forest 2.
• Medlemmar i Forest 2 kan inte komma åt resurser som finns i Forest 1 med samma förtroende.

Viktig

Microsoft Entra Domain Services stöder flera riktningar för skogsförtroenden.

Krav för skogsförvaltning

Innan du kan skapa ett skogsförtroende måste du kontrollera att du har rätt DNS-infrastruktur (Domain Name System). Skogsförvaltningsobjekt kan endast skapas när en 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 gemensam DNS-rotserver och rot-DNS-servrarna i varje DNS-namnrymd i skogsstrukturen använder DNS-villkorliga vidarebefordrare för varje DNS-namnrymd för att dirigera förfrågningar om namn i den andra namnrymden.

  Viktig

  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ågra delade DNS-rotservrar och DNS-rotservrarna i varje skogs-DNS-namnområde 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 trust tilldelas ett lösenord som administratörerna i båda skogarna måste känna till. Medlemmar av Enterprise Admins i båda skogarna kan skapa förtroendeförhållanden i båda skogarna samtidigt, och i det här scenariot genereras och lagras ett kryptografiskt slumpmässigt lösenord automatiskt 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. En användare med de behörigheter som tidigare antecknades i den lokala Active Directory-miljön måste konfigurera det inkommande skogsföreträdde.

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 över förtroenden och autentiseringshänvisningar 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å behörigheter för biljettbeviljande tjänster 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 en biljett till servern i måldomänen från en domänkontrollant i sin konto-domä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:

1. Är den nuvarande domänen direkt betrodd av den domän för servern 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.

2. 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:

1. 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.

2. 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 behandling av autentiseringsförfrågningar över skogsdomäntruster

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 från sin partnerskog och lagrar informationen i ett betrott domänobjekt. Betrodda namnrymder omfattar domänträdnamn, UPN-suffix (User Principal Name), SPN-suffix (Service Principal Name) och SID-namnrymder (Security ID) som används i en annan skog. TDO-objekt replikeras till den globala katalogen.

Notera

Alternativa UPN-suffix för tillitsrelationer 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 då domänkontrollanten en hänvisning till dess överordnade domän tillbaka till arbetsstationen. Vid den tidpunkten begär arbetsstationen serviceticket från den överordnade domänen 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.

1. User1 loggar in på Workstation1 med autentiseringsuppgifter från europe.tailspintoys.com domänen. Användaren försöker sedan få åtkomst till en delad resurs på FileServer1 som finns i usa.wingtiptoys.com domänstrukturen.

2. Workstation1 kontaktar Kerberos KDC på en domänkontrollant i sin domän, ChildDC1, och begär en servicebiljett för FileServer1 SPN.

3. ChildDC1 hittar inte SPN i sin domändatabas och frågar efter den globala katalogen för att se om några domäner i tailspintoys.com skog innehåller detta SPN. 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örbindelser 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 ett routingtips 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.

4. ChildDC1 skickar en hänvisning för sin överordnade domän tillbaka till Workstation1.

5. 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 skogen wingtiptoys.com.

6. Workstation1 kontakter ForestRootDC2 i den wingtiptoys.com skog för en serviceticket till den begärda tjänsten.

7. 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.

8. ForestRootDC2 skickar sedan hänvisningen till usa.wingtiptoys.com tillbaka till Workstation1.

9. Workstation1 kontaktar KDC på ChildDC2 och förhandlar om biljetten för User1 för att få åtkomst till FileServer1.

10. När Workstation1 har en tjänstbiljett skickar den tjänstbiljetten till FileServer1, som läser User1säkerhetsautentiseringsuppgifter och skapar en åtkomsttoken i enlighet med detta.

Betrott domänobjekt

Ett betrott domänobjekt (TDO) som lagras i containern System i domänen representerar varje domän eller skogsförtroende inom en organisation.

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 förtroendefull och en 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:

1. 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 för den betrodda domänen.

2. PDC-emulatorn i den betrodda domänen anger fältet OldPassword för TDO-objektet till det aktuella fältet NewPassword.

3. 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.

4. 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.

5. Domänkontrollanten i den betrodda domänen ändrar förtroendelösenordet till det nya lösenordet.

6. 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 förtroendeskapande 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 den betrodda sidan 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.

Viktig

Active Directory Domain 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 Logon

Tjänsten Net Logon upprätthåller en säker 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 posten Forest Trust Information (FTInfo), 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 – Identitetsuppgifter för användare i andra domäner bearbetas av Net Logon. 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äkerhetsmyndighet

LSA (Local Security Authority) är ett skyddat undersystem som underhåller information om alla aspekter av lokal säkerhet i ett system. Tillsammans kända som lokal säkerhetspolicy, tillhandahåller LSA 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äner och förtroenden, Netdom och Nltest för att exponera, skapa, ta bort eller ändra förtroenden.

• Active Directory Domains and Trusts ä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ändarhuvudnamn.
• Kommandoradsverktygen Netdom och Nltest kan användas för att hitta, visa, skapa och hantera förtroenden. Dessa verktyg kommunicerar direkt med LSA-myndigheten på en domänkontrollenhet.

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.