Hoe vertrouwensrelaties werken voor forests in Active Directory
Active Directory-domein Services (AD DS) biedt beveiliging voor meerdere domeinen of forests via domein- en forestvertrouwensrelaties. Voordat verificatie kan plaatsvinden tussen vertrouwensrelaties, moet Windows eerst controleren of het domein dat wordt aangevraagd door een gebruiker, computer of service een vertrouwensrelatie heeft met het domein van het aanvragende account.
Om te controleren op deze vertrouwensrelatie, berekent het Windows-beveiligingssysteem een vertrouwenspad tussen de domeincontroller (DC) voor de server die de aanvraag ontvangt en een DC in het domein van het aanvragende account.
De mechanismen voor toegangsbeheer die worden geleverd door AD DS en het gedistribueerde Windows-beveiligingsmodel bieden een omgeving voor de werking van domein- en forestvertrouwensrelaties. Voor een goede werking van deze vertrouwensrelaties moet elke resource of computer een direct vertrouwenspad hebben naar een domeincontroller in het domein waarin deze zich bevindt.
Het vertrouwenspad wordt geïmplementeerd door de Net Logon-service met behulp van een geverifieerde RPC-verbinding (Remote Procedure Call) met de vertrouwde domeininstantie. Een beveiligd kanaal is ook van toepassing op andere AD DS-domeinen via vertrouwensrelaties tussen domeinen. Dit beveiligde kanaal wordt gebruikt voor het verkrijgen en verifiëren van beveiligingsgegevens, waaronder beveiligings-id's (SID's) voor gebruikers en groepen.
Notitie
Domain Services ondersteunt meerdere forestvertrouwensrichtingen, waaronder tweerichtingsvertrouwensrelaties en eenrichtingsvertrouwensrelaties die binnenkomend of uitgaand kunnen zijn.
Zie Forest-concepten en -functies voor een overzicht van hoe vertrouwensrelaties van toepassing zijn op Domain Services.
Als u aan de slag wilt gaan met vertrouwensrelaties in Domain Services, maakt u een beheerd domein dat gebruikmaakt van forestvertrouwensrelaties.
Vertrouwensrelatiestromen
De stroom van beveiligde communicatie over vertrouwensrelaties bepaalt de elasticiteit van een vertrouwensrelatie. Hoe u een vertrouwensrelatie maakt of configureert, bepaalt hoe ver de communicatie zich uitbreidt binnen of tussen forests.
De communicatiestroom over vertrouwensrelaties wordt bepaald door de richting van de vertrouwensrelatie. Vertrouwensrelaties kunnen eenrichtings- of tweerichtingsrelatie zijn en kunnen transitief of niet-transitief zijn.
In het volgende diagram ziet u dat alle domeinen in Tree 1 en Tree 2 standaard transitieve vertrouwensrelaties hebben. Als gevolg hiervan hebben gebruikers in Structuur 1 toegang tot resources in domeinen in Structuur 2 en gebruikers in Tree 2 toegang tot resources in Tree 1 wanneer de juiste machtigingen aan de resource zijn toegewezen.
Eenrichtings- en tweerichtingsvertrouwensrelaties
Vertrouwensrelaties maken toegang tot resources mogelijk in één richting of in twee richtingen.
Een eenrichtingsvertrouwensrelatie is een unidirectioneel verificatiepad dat tussen twee domeinen is gemaakt. In een eenrichtingsvertrouwen tussen domein A en domein B hebben gebruikers in domein A toegang tot resources in domein B. Gebruikers in domein B hebben echter geen toegang tot resources in domein A.
Sommige eenrichtingsvertrouwensrelaties kunnen niet-transitief of transitief zijn, afhankelijk van het type vertrouwen dat wordt gemaakt.
In een tweerichtingsvertrouwensrelatie vertrouwt Domein A domein B en Domein B domein A. Deze configuratie betekent dat verificatieaanvragen tussen de twee domeinen in beide richtingen kunnen worden doorgegeven. Sommige tweerichtingsrelaties kunnen niet-transitief of transitief zijn, afhankelijk van het type vertrouwen dat wordt gemaakt.
Alle domeinvertrouwensrelaties in een on-premises AD DS-forest zijn transitieve vertrouwensrelaties in twee richtingen. Wanneer een nieuw onderliggend domein wordt gemaakt, wordt er automatisch een transitieve vertrouwensrelatie gemaakt tussen het nieuwe onderliggende domein en het bovenliggende domein.
Transitieve en niet-transitieve vertrouwensrelaties
Transitiviteit bepaalt of een vertrouwensrelatie kan worden uitgebreid buiten de twee domeinen waarmee deze is gevormd.
- Een transitieve vertrouwensrelatie kan worden gebruikt om vertrouwensrelaties met andere domeinen uit te breiden.
- Een niet-transitieve vertrouwensrelatie kan worden gebruikt om vertrouwensrelaties met andere domeinen te weigeren.
Telkens wanneer u een nieuw domein in een forest maakt, wordt automatisch een transitieve vertrouwensrelatie tussen het nieuwe domein en het bovenliggende domein gemaakt. Als onderliggende domeinen worden toegevoegd aan het nieuwe domein, loopt het vertrouwenspad omhoog door de domeinhiërarchie, waardoor het eerste vertrouwenspad dat is gemaakt tussen het nieuwe domein en het bovenliggende domein, wordt uitgebreid. Transitieve vertrouwensrelaties stromen omhoog door een domeinstructuur terwijl deze wordt gevormd, waardoor transitieve vertrouwensrelaties tussen alle domeinen in de domeinstructuur worden gemaakt.
Verificatieaanvragen volgen deze vertrouwenspaden, zodat accounts van elk domein in het forest kunnen worden geverifieerd door elk ander domein in het forest. Met een proces voor eenmalige aanmelding hebben accounts met de juiste machtigingen toegang tot resources in elk domein in het forest.
Forestvertrouwensrelaties
Forestvertrouwensrelaties helpen u bij het beheren van gesegmenteerde AD DS-infrastructuren en ondersteunen de toegang tot resources en andere objecten in meerdere forests. Forestvertrouwensrelaties zijn nuttig voor serviceproviders, bedrijven die fusies of overnames ondergaan, samenwerkingsbedrijven en bedrijven die op zoek zijn naar een oplossing voor administratieve autonomie.
Met forestvertrouwensrelaties kunt u twee verschillende forests koppelen om een transitieve of tweerichtingsrelatie te vormen. Met een forestvertrouwensrelatie kunnen beheerders twee AD DS-forests verbinden met één vertrouwensrelatie om een naadloze verificatie- en autorisatie-ervaring in de forests te bieden.
Een forestvertrouwensrelatie kan alleen worden gemaakt tussen een foresthoofddomein in één forest en een foresthoofddomein in een ander forest. Forestvertrouwensrelaties kunnen alleen tussen twee forests worden gemaakt en kunnen niet impliciet worden uitgebreid naar een derde forest. Dit gedrag betekent dat als er een forestvertrouwensrelatie tussen Forest 1 en Forest 2 wordt gemaakt en een andere forestvertrouwensrelatie tussen Forest 2 en Forest 3 wordt gemaakt, Forest 1 geen impliciete vertrouwensrelatie heeft met Forest 3.
In het volgende diagram ziet u twee afzonderlijke forestvertrouwensrelaties tussen drie AD DS-forests in één organisatie.
Deze voorbeeldconfiguratie biedt de volgende toegang:
- Gebruikers in Forest 2 hebben toegang tot resources in elk domein in Forest 1 of Forest 3
- Gebruikers in Forest 3 hebben toegang tot resources in elk domein in Forest 2
- Gebruikers in Forest 1 hebben toegang tot resources in elk domein in Forest 2
Met deze configuratie hebben gebruikers in Forest 1 geen toegang tot resources in Forest 3 of omgekeerd. Als u wilt dat gebruikers in forest 1 en Forest 3 resources kunnen delen, moet er een transitieve tweerichtingsvertrouwensrelatie tussen de twee forests worden gemaakt.
Als er een eenrichtingsforestvertrouwensrelatie tussen twee forests wordt gemaakt, kunnen leden van het vertrouwde forest resources gebruiken die zich in het vertrouwende forest bevinden. Het vertrouwen werkt echter in slechts één richting.
Als er bijvoorbeeld een eenzijdige forestvertrouwensrelatie wordt gemaakt tussen Forest 1 (het vertrouwde forest) en Forest 2 (het vertrouwende forest):
- Leden van Forest 1 hebben toegang tot resources in Forest 2.
- Leden van Forest 2 hebben geen toegang tot resources die zich in Forest 1 bevinden met dezelfde vertrouwensrelatie.
Belangrijk
Microsoft Entra Domain Services ondersteunt meerdere richtingen voor forestvertrouwensrelaties.
Vereisten voor forestvertrouwen
Voordat u een forestvertrouwensrelatie kunt maken, moet u controleren of u de juiste DNS-infrastructuur (Domain Name System) hebt. Forestvertrouwensrelaties kunnen alleen worden gemaakt wanneer een van de volgende DNS-configuraties beschikbaar is:
Een enkele DNS-hoofdserver is de hoofd-DNS-server voor beide forest-DNS-naamruimten: de hoofdzone bevat delegaties voor elk van de DNS-naamruimten en de hoofdhints van alle DNS-servers bevatten de hoofd-DNS-server.
Wanneer er geen gedeelde DNS-hoofdserver is en de hoofd-DNS-servers in elke FOREST DNS-naamruimte gebruikmaken van voorwaardelijke doorstuurservers voor elke DNS-naamruimte om query's voor namen in de andere naamruimte te routeren.
Belangrijk
Elke Microsoft Entra Domain Services-forest met een vertrouwensrelatie moet deze DNS-configuratie gebruiken. Het hosten van een andere DNS-naamruimte dan de DNS-naamruimte van het forest is geen functie van Microsoft Entra Domain Services. Voorwaardelijke doorstuurservers zijn de juiste configuratie.
Wanneer er geen gedeelde DNS-hoofdserver is en de hoofd-DNS-servers in elke DNS-naamruimte van het forest dns worden gebruikt, worden secundaire DNS-zones geconfigureerd in elke DNS-naamruimte om query's voor namen in de andere naamruimte te routeren.
Als u een forestvertrouwensrelatie in AD DS wilt maken, moet u lid zijn van de groep Domein Beheer s (in het hoofddomein van het forest) of de groep Enterprise Beheer s in Active Directory. Aan elke vertrouwensrelatie wordt een wachtwoord toegewezen dat de beheerders in beide forests moeten weten. Leden van Enterprise-Beheer s in beide forests kunnen de vertrouwensrelaties in beide forests tegelijk maken en in dit scenario wordt een wachtwoord dat cryptografisch willekeurig is automatisch gegenereerd en geschreven voor beide forests.
Een beheerd domeinforest ondersteunt maximaal vijf uitgaande forestvertrouwensrelaties in één richting naar on-premises forests. De uitgaande forestvertrouwensrelatie voor Microsoft Entra Domain Services wordt gemaakt in het Microsoft Entra-beheercentrum. De binnenkomende forestvertrouwensrelatie moet worden geconfigureerd door een gebruiker met de bevoegdheden die eerder zijn genoteerd in de on-premises Active Directory.
Vertrouwensprocessen en interacties
Veel transacties tussen domeinen en forests zijn afhankelijk van domein- of forestvertrouwensrelaties om verschillende taken uit te voeren. In deze sectie worden de processen en interacties beschreven die optreden wanneer resources worden geopend in vertrouwensrelaties en verificatieverwijzingen worden geëvalueerd.
Overzicht van verificatieverwijzingsverwerking
Wanneer een aanvraag voor verificatie naar een domein wordt verwezen, moet de domeincontroller in dat domein bepalen of er een vertrouwensrelatie bestaat met het domein waaruit de aanvraag afkomstig is. De richting van de vertrouwensrelatie en of de vertrouwensrelatie transitief of niet-transitief is, moet ook worden bepaald voordat de gebruiker wordt geverifieerd voor toegang tot resources in het domein. Het verificatieproces dat plaatsvindt tussen vertrouwde domeinen, verschilt afhankelijk van het verificatieprotocol dat wordt gebruikt. De Kerberos V5- en NTLM-protocollen verwerken verwijzingen voor verificatie naar een domein anders
Kerberos V5-verwijzingsverwerking
Het Kerberos V5-verificatieprotocol is afhankelijk van de Net-aanmeldingsservice op domeincontrollers voor clientverificatie- en autorisatiegegevens. Het Kerberos-protocol maakt verbinding met een online Key Distribution Center (KDC) en het Active Directory-accountarchief voor sessietickets.
Het Kerberos-protocol maakt ook gebruik van vertrouwensrelaties voor cross-realm ticket-granting services (TGS) en voor het valideren van Privilege Attribute Certificates (PAC's) in een beveiligd kanaal. Het Kerberos-protocol voert alleen cross-realm-verificatie uit met niet-Windows-besturingssysteem Kerberos-realms, zoals een MIT Kerberos-realm en hoeft niet te communiceren met de Net Logon-service.
Als de client Kerberos V5 gebruikt voor verificatie, vraagt deze een ticket aan bij de server in het doeldomein van een domeincontroller in het accountdomein. De Kerberos KDC fungeert als een vertrouwde intermediair tussen de client en de server en biedt een sessiesleutel waarmee de twee partijen elkaar kunnen verifiëren. Als het doeldomein verschilt van het huidige domein, volgt de KDC een logisch proces om te bepalen of er naar een verificatieaanvraag kan worden verwezen:
Wordt het huidige domein rechtstreeks vertrouwd door het domein van de server die wordt aangevraagd?
- Zo ja, stuur de client een verwijzing naar het aangevraagde domein.
- Als dat niet het gaat, gaat u naar de volgende stap.
Bestaat er een transitieve vertrouwensrelatie tussen het huidige domein en het volgende domein op het vertrouwenspad?
- Zo ja, stuur de client een verwijzing naar het volgende domein op het vertrouwenspad.
- Als dat niet het is, stuurt u de client een bericht dat is geweigerd.
NTLM-verwijzingsverwerking
Het NTLM-verificatieprotocol is afhankelijk van de Net Logon-service op domeincontrollers voor clientverificatie- en autorisatiegegevens. Dit protocol verifieert clients die geen Kerberos-verificatie gebruiken. NTLM gebruikt vertrouwensrelaties om verificatieaanvragen tussen domeinen door te geven.
Als de client NTLM gebruikt voor verificatie, gaat de eerste aanvraag voor verificatie rechtstreeks van de client naar de resourceserver in het doeldomein. Deze server maakt een uitdaging waarop de client reageert. De server verzendt vervolgens het antwoord van de gebruiker naar een domeincontroller in het computeraccountdomein. Met deze domeincontroller wordt het gebruikersaccount gecontroleerd op de database met beveiligingsaccounts.
Als het account niet bestaat in de database, bepaalt de domeincontroller of passthrough-verificatie moet worden uitgevoerd, de aanvraag moet worden doorgestuurd of de aanvraag moet worden geweigerd met behulp van de volgende logica:
Heeft het huidige domein een directe vertrouwensrelatie met het domein van de gebruiker?
- Zo ja, dan verzendt de domeincontroller de referenties van de client naar een domeincontroller in het domein van de gebruiker voor passthrough-verificatie.
- Als dat niet het gaat, gaat u naar de volgende stap.
Heeft het huidige domein een transitieve vertrouwensrelatie met het domein van de gebruiker?
- Zo ja, geef de verificatieaanvraag door aan het volgende domein in het vertrouwenspad. Deze domeincontroller herhaalt het proces door de referenties van de gebruiker te controleren op de eigen beveiligingsaccountdatabase.
- Als dat niet het is, stuurt u de client een bericht dat is geweigerd.
Op Kerberos gebaseerde verwerking van verificatieaanvragen via forestvertrouwensrelaties
Wanneer twee forests zijn verbonden door een forestvertrouwensrelatie, kunnen verificatieaanvragen die worden gedaan met behulp van de Kerberos V5- of NTLM-protocollen, worden gerouteerd tussen forests om toegang te bieden tot resources in beide forests.
Wanneer een forestvertrouwensrelatie voor het eerst tot stand wordt gebracht, verzamelt elk forest alle vertrouwde naamruimten in het partnerforest en slaat deze op in een vertrouwd domeinobject. Vertrouwde naamruimten omvatten domeinnamen, UPN-achtervoegsels (User Principal Name), SPN-achtervoegsels (Service Principal Name) en BEVEILIGINGS-ID-naamruimten (SID) die in het andere forest worden gebruikt. TDO-objecten worden gerepliceerd naar de globale catalogus.
Notitie
Alternatieve UPN-achtervoegsels op vertrouwensrelaties worden niet ondersteund. Als een on-premises domein hetzelfde UPN-achtervoegsel gebruikt als Domain Services, moet u zich aanmelden met sAMAccountName.
Voordat verificatieprotocollen het forestvertrouwenspad kunnen volgen, moet de SPN (Service Principal Name) van de resourcecomputer worden omgezet naar een locatie in het andere forest. Een SPN kan een van de volgende namen zijn:
- De DNS-naam van een host.
- De DNS-naam van een domein.
- De DN-naam van een serviceverbindingspuntobject.
Wanneer een werkstation in een forest toegang probeert te krijgen tot gegevens op een resourcecomputer in een ander forest, neemt het Kerberos-verificatieproces contact op met de domeincontroller voor een serviceticket naar de SPN van de resourcecomputer. Zodra de domeincontroller de globale catalogus opvraagt en bepaalt dat de SPN zich niet in hetzelfde forest bevindt als de domeincontroller, verzendt de domeincontroller een verwijzing voor het bovenliggende domein terug naar het werkstation. Op dat moment voert het werkstation een query uit op het bovenliggende domein voor het serviceticket en blijft de verwijzingsketen volgen totdat het domein is bereikt waar de resource zich bevindt.
Het volgende diagram en de volgende stappen bevatten een gedetailleerde beschrijving van het Kerberos-verificatieproces dat wordt gebruikt wanneer computers met Windows toegang proberen te krijgen tot resources vanaf een computer die zich in een ander forest bevindt.
Gebruiker1 meldt zich aan bij Workstation1 met referenties uit het europe.tailspintoys.com domein. De gebruiker probeert vervolgens toegang te krijgen tot een gedeelde resource op FileServer1 in het usa.wingtiptoys.com forest.
Workstation1 neemt contact op met de Kerberos KDC op een domeincontroller in het domein, ChildDC1 en vraagt een serviceticket aan voor de FileServer1 SPN.
ChildDC1 vindt de SPN niet in de domeindatabase en voert een query uit op de globale catalogus om te zien of er domeinen in het tailspintoys.com forest deze SPN bevatten. Omdat een globale catalogus beperkt is tot een eigen forest, wordt de SPN niet gevonden.
De globale catalogus controleert vervolgens de database op informatie over forestvertrouwensrelaties die met het forest zijn ingesteld. Indien gevonden, vergelijkt het de naamachtervoegsels die worden vermeld in het forest trust Trusted Domain Object (TDO) met het achtervoegsel van de doel-SPN om een overeenkomst te vinden. Zodra een overeenkomst is gevonden, biedt de globale catalogus een routeringshint terug naar ChildDC1.
Routeringshints helpen verificatieaanvragen om te leiden naar het doelforest. Hints worden alleen gebruikt wanneer alle traditionele verificatiekanalen, zoals lokale domeincontroller en vervolgens globale catalogus, geen SPN vinden.
ChildDC1 verzendt een verwijzing voor het bovenliggende domein terug naar Workstation1.
Workstation1 neemt contact op met een domeincontroller in ForestRootDC1 (het bovenliggende domein) voor een verwijzing naar een domeincontroller (ForestRootDC2) in het foresthoofddomein van het wingtiptoys.com forest.
Workstation1 neemt contact op met ForestRootDC2 in het wingtiptoys.com forest voor een serviceticket naar de aangevraagde service.
ForestRootDC2 neemt contact op met de globale catalogus om de SPN te vinden en de globale catalogus vindt een overeenkomst voor de SPN en stuurt deze terug naar ForestRootDC2.
ForestRootDC2 verzendt vervolgens de verwijzing naar usa.wingtiptoys.com terug naar Workstation1.
Workstation1 neemt contact op met de KDC op ChildDC2 en onderhandelt over het ticket voor Gebruiker1 om toegang te krijgen tot FileServer1.
Zodra Workstation1 een serviceticket heeft, wordt het serviceticket verzonden naar FileServer1, waarmee de beveiligingsreferenties van Gebruiker1 worden gelezen en dienovereenkomstig een toegangstoken wordt samengesteld.
Vertrouwd domeinobject
Elk domein of forestvertrouwen binnen een organisatie wordt vertegenwoordigd door een TDO (Trusted Domain Object) die is opgeslagen in de systeemcontainer binnen het domein.
TDO-inhoud
De informatie in een TDO is afhankelijk van of een TDO is gemaakt door een domeinvertrouwensrelatie of door een forestvertrouwensrelatie.
Wanneer een domeinvertrouwensrelatie wordt gemaakt, worden kenmerken zoals de DNS-domeinnaam, domein-SID, vertrouwenstype, vertrouwensoverdracht en de wederzijdse domeinnaam weergegeven in de TDO. TDO's voor forestvertrouwen slaan aanvullende kenmerken op om alle vertrouwde naamruimten van het partnerforest te identificeren. Deze kenmerken omvatten domeinnamen, UPN-achtervoegsels (User Principal Name), SPN-achtervoegsels (Service Principal Name) en SID-naamruimten (Security ID).
Omdat vertrouwensrelaties worden opgeslagen in Active Directory als TPO's, hebben alle domeinen in een forest kennis van de vertrouwensrelaties die in het hele forest aanwezig zijn. Als twee of meer forests worden samengevoegd via forestvertrouwensrelaties, hebben de foresthoofddomeinen in elk forest kennis van de vertrouwensrelaties die in alle domeinen in vertrouwde forests aanwezig zijn.
TDO-wachtwoordwijzigingen
Beide domeinen in een vertrouwensrelatie delen een wachtwoord, dat is opgeslagen in het TDO-object in Active Directory. Als onderdeel van het accountonderhoudsproces wijzigt de vertrouwde domeincontroller elke 30 dagen het wachtwoord dat is opgeslagen in de TDO. Omdat alle tweerichtingsvertrouwensrelaties eigenlijk twee eenrichtingsvertrouwensrelaties zijn die in tegengestelde richtingen gaan, vindt het proces twee keer plaats voor tweerichtingsvertrouwensrelaties.
Een vertrouwensrelatie heeft een vertrouwende en een vertrouwde kant. Aan de vertrouwde kant kan elke beschrijfbare domeincontroller worden gebruikt voor het proces. Aan de vertrouwenszijde voert de PDC-emulator de wachtwoordwijziging uit.
Als u een wachtwoord wilt wijzigen, voltooien de domeincontrollers het volgende proces:
De primaire domeincontrolleremulator (PDC) in het vertrouwende domein maakt een nieuw wachtwoord. Een domeincontroller in het vertrouwde domein initieert nooit de wachtwoordwijziging. Het wordt altijd gestart door de PDC-emulator van het vertrouwende domein.
De PDC-emulator in het vertrouwende domein stelt het veld OldPassword van het TDO-object in op het huidige veld NewPassword .
De PDC-emulator in het vertrouwende domein stelt het veld NewPassword van het TDO-object in op het nieuwe wachtwoord. Als u een kopie van het vorige wachtwoord bewaart, kunt u terugkeren naar het oude wachtwoord als de domeincontroller in het vertrouwde domein de wijziging niet kan ontvangen of als de wijziging niet wordt gerepliceerd voordat een aanvraag wordt gedaan die gebruikmaakt van het nieuwe vertrouwenswachtwoord.
De PDC-emulator in het vertrouwensdomein roept een externe aanroep uit naar een domeincontroller in het vertrouwde domein waarin wordt gevraagd het wachtwoord voor het vertrouwensaccount in te stellen op het nieuwe wachtwoord.
De domeincontroller in het vertrouwde domein wijzigt het vertrouwenswachtwoord in het nieuwe wachtwoord.
Aan elke kant van de vertrouwensrelatie worden de updates gerepliceerd naar de andere domeincontrollers in het domein. In het vertrouwende domein activeert de wijziging een dringende replicatie van het vertrouwde domeinobject.
Het wachtwoord wordt nu gewijzigd op beide domeincontrollers. Normale replicatie distribueert de TDO-objecten naar de andere domeincontrollers in het domein. Het is echter mogelijk dat de domeincontroller in het vertrouwende domein het wachtwoord wijzigt zonder dat een domeincontroller in het vertrouwde domein is bijgewerkt. Dit scenario kan optreden omdat een beveiligd kanaal, dat vereist is voor het verwerken van de wachtwoordwijziging, niet tot stand kan worden gebracht. Het is ook mogelijk dat de domeincontroller in het vertrouwde domein op een bepaald moment tijdens het proces niet beschikbaar is en het bijgewerkte wachtwoord mogelijk niet ontvangt.
Als u wilt omgaan met situaties waarin de wachtwoordwijziging niet met succes wordt gecommuniceerd, wijzigt de domeincontroller in het vertrouwende domein het nieuwe wachtwoord nooit, tenzij het is geverifieerd (een beveiligd kanaal instellen) met behulp van het nieuwe wachtwoord. Dit gedrag is waarom zowel de oude als de nieuwe wachtwoorden worden bewaard in het TDO-object van het vertrouwende domein.
Een wachtwoordwijziging wordt pas voltooid nadat de verificatie met het wachtwoord is geslaagd. Het oude, opgeslagen wachtwoord kan via het beveiligde kanaal worden gebruikt totdat de domeincontroller in het vertrouwde domein het nieuwe wachtwoord ontvangt, waardoor een ononderbroken service mogelijk is.
Als verificatie met het nieuwe wachtwoord mislukt omdat het wachtwoord ongeldig is, probeert de vertrouwde domeincontroller te verifiëren met het oude wachtwoord. Als het wachtwoord is geverifieerd met het oude wachtwoord, wordt het wachtwoordwijzigingsproces binnen 15 minuten hervat.
Wachtwoordupdates vertrouwen moeten binnen 30 dagen worden gerepliceerd naar de domeincontrollers van beide zijden van de vertrouwensrelatie. Als het vertrouwenswachtwoord na 30 dagen wordt gewijzigd en een domeincontroller alleen het N-2-wachtwoord heeft, kan het niet de vertrouwensrelatie van de vertrouwenszijde gebruiken en kan er geen beveiligd kanaal aan de vertrouwde kant worden gemaakt.
Netwerkpoorten die worden gebruikt door vertrouwensrelaties
Omdat vertrouwensrelaties moeten worden geïmplementeerd binnen verschillende netwerkgrenzen, moeten ze mogelijk een of meer firewalls omvatten. Als dit het geval is, kunt u tunnelvertrouwensverkeer tussen een firewall of specifieke poorten in de firewall openen om toe te staan dat het verkeer wordt doorgegeven.
Belangrijk
Active Directory-domein Services biedt geen ondersteuning voor het beperken van Active Directory RPC-verkeer naar specifieke poorten.
Lees de sectie Windows Server 2008 en latere versies van het Microsoft Ondersteuning Artikel Een firewall configureren voor Active Directory-domeinen en vertrouwensrelaties voor meer informatie over de poorten die nodig zijn voor een forestvertrouwensrelatie.
Ondersteunende services en hulpprogramma's
Ter ondersteuning van vertrouwensrelaties en verificatie worden enkele extra functies en beheerhulpprogramma's gebruikt.
Net-aanmelding
De Net-aanmeldingsservice onderhoudt een beveiligd kanaal van een Windows-computer naar een DC. Deze wordt ook gebruikt in de volgende vertrouwensprocessen:
Vertrouwensinstallatie en -beheer : Net Logon helpt bij het onderhouden van vertrouwenswachtwoorden, verzamelt vertrouwensinformatie en verifieert vertrouwensrelaties door te communiceren met het LSA-proces en de TDO.
Voor Forest-vertrouwensrelaties bevat de vertrouwensinformatie de FTInfo-record (Forest Trust Information), die de set naamruimten bevat die een vertrouwde forestclaims beheert, geannoteerd met een veld dat aangeeft of elke claim wordt vertrouwd door het vertrouwende forest.
Verificatie: levert gebruikersreferenties via een beveiligd kanaal aan een domeincontroller en retourneert de domein-SID's en gebruikersrechten voor de gebruiker.
Locatie van domeincontroller: helpt bij het vinden of vinden van domeincontrollers in een domein of in meerdere domeinen.
Passthrough-validatie: referenties van gebruikers in andere domeinen worden verwerkt door Net-aanmelding. Wanneer een vertrouwend domein de identiteit van een gebruiker moet verifiëren, worden de referenties van de gebruiker via Net-aanmelding doorgegeven aan het vertrouwde domein voor verificatie.
PAC-verificatie (Privilege Attribute Certificate): wanneer een server die gebruikmaakt van het Kerberos-protocol voor verificatie de PAC in een serviceticket moet verifiëren, wordt het PAC via het beveiligde kanaal naar de domeincontroller verzonden voor verificatie.
Lokale certificeringsinstantie
De Local Security Authority (LSA) is een beveiligd subsysteem dat informatie onderhoudt over alle aspecten van lokale beveiliging op een systeem. Gezamenlijk bekend als lokaal beveiligingsbeleid, biedt de LSA verschillende services voor vertaling tussen namen en id's.
Het LSA-beveiligingssubsysteem biedt services in zowel de kernelmodus als de gebruikersmodus voor het valideren van de toegang tot objecten, het controleren van gebruikersbevoegdheden en het genereren van controleberichten. LSA is verantwoordelijk voor het controleren van de geldigheid van alle sessietickets die worden aangeboden door services in vertrouwde of niet-vertrouwde domeinen.
Beheerhulpprogramma's
Beheer istrators kunnen Active Directory-domein s en vertrouwensrelaties, Netdom en Nltest gebruiken om vertrouwensrelaties beschikbaar te maken, te maken, te verwijderen of te wijzigen.
- Active Directory-domein s en vertrouwensrelaties is de MMC (Microsoft Management Console) die wordt gebruikt voor het beheren van domeinvertrouwensrelaties, domein- en forestfunctionaliteitsniveaus en achtervoegsels van de user principal name.
- De opdrachtregelprogramma's Netdom en Nltest kunnen worden gebruikt om vertrouwensrelaties te vinden, weer te geven, te maken en te beheren. Deze hulpprogramma's communiceren rechtstreeks met de LSA-instantie op een domeincontroller.
Volgende stappen
Zie Een beheerd domein maken en configureren om aan de slag te gaan met het maken van een beheerd domein met een forestvertrouwensrelatie. Vervolgens kunt u een uitgaande forestvertrouwensrelatie maken naar een on-premises domein.