Problemen met sIDHistory-migratie tussen forests oplossen met ADMTv2

2025-01-15

In dit artikel wordt beschreven hoe u problemen met sIDHistory-migratie tussen forests oplost met Active Directory Migration Tool versie 2 (ADMTv2).

Oorspronkelijk KB-nummer: 322970

Meer informatie

Wanneer u ADMTv2 gebruikt om sIDHistory te migreren als onderdeel van een migratie tussen forests of groepen, is de configuratie vereist met de basismigratievereisten.

Standaard worden sIDHistory, password en objectGUID allemaal bewaard tijdens migraties binnen forests, maar dit geldt niet voor klonen tussen forests.

Omdat er geen ingebouwde beveiligingscontext is voor bewerkingen tussen forests, moet u stappen ondernemen om de beveiliging van bewerkingen over forestgrenzen te beschermen.

Configuratie

De basisvereisten voor migratiebewerkingen tussen forests zijn:

Migratie van basisgebruikers- en groepsaccounts op basis van wizards zonder sIDHistory

Het brondomein moet het doeldomein vertrouwen.
Het gebruikersaccount waarop ADMTv2 wordt uitgevoerd, moet beheerdersrechten hebben in het brondomein.
Het ADMT-gebruikersaccount moet gedelegeerde machtigingen hebben om gebruikers- of groepsobjecten te maken in de doelcontainer.
DNS (hostnaam) en NetBIOS-naamomzetting tussen de domeinen moeten bestaan.

voor sIDHistory-migratie zijn de volgende aanvullende afhankelijkheden vereist

Geslaagde en mislukte controle van accountbeheer voor zowel bron- als doeldomeinen.
Brondomeinen roepen deze controle van gebruikers- en groepsbeheer aan.
Een lege lokale groep in het brondomein met de naam {SourceNetBIOSDom}}..
De HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportregistersleutel moet worden ingesteld op 1 op de primaire domeincontroller van het brondomein.
U moet de primaire domeincontroller van het brondomein opnieuw opstarten na de registerconfiguratie.
Windows-beveiliging vereist gebruikersreferenties met de gedelegeerde MigratesIDHistory uitgebreide rechten of beheerdersrechten in het doeldomein. U voegt deze referenties toe in de wizard wanneer de migratie van sIDHistory is ingeschakeld.

Als u de migrateSidHistory rechtstreeks wilt delegeren op een domeincontroller of op een computer waarop het Windows Server Administration Tools-pakket is geïnstalleerd, voert u de volgende stappen uit:

Klik op Start, klikt u op Systeembeheer, en klik vervolgens op Active Directory: gebruikers en Computers.
Klik met de rechtermuisknop op de naam van het domein waarvan u de migrateSidHistory rechtstreeks wilt delegeren en klik vervolgens op Control delegeren om het venster Van de wizard Beheer delegeren te openen.
Klik op Volgende, klik op Toevoegen, voer de naam in van de gebruiker of groep die u wilt toevoegen in het dialoogvenster Gebruikers, Computers of Groepen selecteren, klik op OK en klik vervolgens op Volgende.
Klik om de optie Een aangepaste taak maken te selecteren die u wilt delegeren en klik vervolgens op Volgende.
Zorg ervoor dat de map Deze map, bestaande objecten in deze map en het maken van nieuwe objecten in deze map is geselecteerd en klik vervolgens op Volgende.
Zorg ervoor dat de optie Algemeen is geselecteerd, klik op SID-geschiedenis migreren in de lijst Machtigingen en klik vervolgens op Volgende.
Controleer of de informatie juist is en klik vervolgens op Voltooien.
- Er kan geen sID worden gemigreerd in het doelforest, hetzij als primaire sID of als een sIDHistory-kenmerk van een ander object.

Aanvullende vereisten voor het migreren van sIDHistory met de opdrachtregel- of scriptinterfaces

Wanneer u een migratie van een gebruiker of groep start met sIDHistory-migratie vanaf de opdrachtregel of vanuit een script, moet de opdracht of het script worden uitgevoerd op de domeincontroller in het doeldomein.
Het gebruikersaccount waarop de migratie wordt uitgevoerd, moet beheerdersrechten hebben in zowel de bron- als de doeldomeinen.

Speciale vereisten voor groepstoewijzing en wizard samenvoegen

Als sIDHistory moet worden gemigreerd tijdens het toewijzen en samenvoegen van groepen, moet het bereik van de brongroepen overeenkomen met het bereik van de doelgroep.

Probleemoplossing

De meest eenvoudige stap die u kunt gebruiken om problemen met migratie tussen forests op te lossen, is door de wizard Gebruikersaccountmigratie of de wizard Migratie van groepsaccounts te gebruiken om een migratie in de testmodus uit te voeren.

Tijdens de testmodusmigratie valideert ADMTv2 de volgende afhankelijkheden:

De lokale groep {SourceNetBIOSDom}} wordt gemaakt.
TcpipClientSupport op de primaire brondomeincontroller of primaire domeincontrolleremulator is ingeschakeld.
Controle in beide domeinen is ingeschakeld.

ADMT kan eventueel een van deze afhankelijkheden herstellen die niet zijn ingesteld. Als u deze instellingen wilt herstellen of configureren, moet het account dat wordt gebruikt om ADMT uit te voeren, voldoende machtigingen hebben in elk domein om de taken uit te voeren.

Alleen de wizard voert deze controles en correcties uit. De opdrachtregel- en scriptinterfaces voeren deze controles niet uit en werken niet zonder de juiste configuratie.

Veelvoorkomende foutberichten met sIDHistory-migratie tussen forests

"De ingang is ongeldig (foutcode = 6)."

Deze fout geeft een RPC-probleem aan waarbij het migratieprogramma geen verbinding kan maken met een RPC-eindpunt op de primaire brondomeincontroller. Tot de mogelijke oorzaken behoren:

TcpipClientSupport op de primaire brondomeincontroller of primaire domeincontrolleremulator is niet ingeschakeld.
De primaire domeincontroller of primaire domeincontrolleremulator is niet opnieuw opgestart nadat TcpipClientSupport is geconfigureerd.
DNS- of NetBIOS-naamomzetting werkt niet.

Controle en TcpipClientSupport op domeinen kunnen niet worden geverifieerd. Kan sid's niet migreren. De opgegeven lokale groep bestaat niet.

Deze fout geeft meestal aan dat een gebruiker of een globale of universele groep met de naam {SourceNetBIOSDom}} al bestaat. ADMT maakt doorgaans de lokale groep van die naam, maar kan dit niet doen als er al een beveiligingsprincipaal met de naam bestaat.

Controle en TcpipClientSupport op domeinen kunnen niet worden geverifieerd. Kan sid's niet migreren. De toegang is geweigerd.

Deze fout geeft meestal aan dat het gebruikersaccount dat wordt gebruikt voor het uitvoeren van ADMT niet voldoende machtigingen heeft om de migratie uit te voeren in een of beide domeinen. Opzoeken van domeinnaam is mislukt, rc=1332. Er is geen toewijzing tussen accountnamen en beveiligings-ID's uitgevoerd. Deze fout in het Migration.log-bestand na een migratie met sIDHistory geeft meestal aan dat het brondomein vertrouwensrelaties heeft geconfigureerd die niet aanwezig zijn in het doeldomein. U kunt dit probleem oplossen door de wizard Vertrouwensmigratie uit te voeren om de vertrouwensrelaties in het brondomein toe te wijzen en vervolgens de relaties in het doeldomein te repliceren.

Aanvullende sIDHistory-informatie

De sIDHistory is een kenmerk met meerdere waarden van beveiligingsprinciplen in Active Directory dat maximaal 850 waarden kan bevatten. Om achterwaartse compatibiliteit te bieden met domeincontrollers waarop eerdere versies van Windows worden uitgevoerd, is het kenmerk sIDHistory alleen beschikbaar in domeinen die werken op het functionele niveau van Windows.

Sommige producten van leveranciers van derden maken het mogelijk om sIDHistory in te schakelen in domeinen in de gemengde modus. Deze claims vertegenwoordigen niet het legitieme gebruik van openbare API's. Domeinbeheerders die dergelijke hulpprogramma's gebruiken, riskeren hun Active Directory-implementatie in een niet-ondersteunde status te plaatsen.

Tijdens migraties binnen forests is LDAP_Rename verantwoordelijk voor het verplaatsen van objecten. Daarom behouden gemigreerde objecten belangrijke identificatiegegevens, waaronder de objectGUID en het wachtwoord. Dit is niet het geval voor migraties tussen forests, die DSAddSidHistory aanroepen om het kenmerk in het doeldomein te vullen. Wachtwoordmigratie kan zijn ingeschakeld voor klonen tussen forests, maar de objectGUID gaat altijd verloren tijdens dit type migratie.

In beide gevallen krijgen gemigreerde objecten een nieuwe sID toegewezen door het doeldomein. De oorspronkelijke sID wordt toegevoegd aan het kenmerk sIDHistory van het gemigreerde object in het nieuwe domein. Nadat dit is gebeurd, kan het kenmerk sIDHistory niet worden gewijzigd of verwijderd met behulp van de standaardhulpprogramma's voor Active Directory-beheer. Dit is niet toegestaan omdat het kenmerk sIDHistory eigendom is van de SAM. Het is mogelijk om de sIDHistory te wissen met behulp van een script of een niet-openbaar intern Microsoft-hulpprogramma.

De sIDHistory is een overgangsprogramma en is niet bedoeld om voor onbepaalde tijd te bestaan aan beveiligingsprinciplen. Hoewel het migreren van de sIDHistory het migratieproces van het domein aanzienlijk kan vereenvoudigen, zijn er belangrijke beveiligingsproblemen die moeten worden overwogen voordat u de sIDHistory in een productiebedrijf implementeert.

Een Windows-beveiligingstoken kan maximaal 1023 SID's bevatten, waaronder sIDHistory en groeps-ID's. Kerberos is ook beperkt omdat Windows Kerberos een buffer van 73 sID heeft. Deze grootte kan worden verdubbeld door een wijziging in het hele register voor het hele bedrijf. Het overschrijden van deze limieten schendt de maxTokenSize-beperking en kan leiden tot onvoorspelbare resultaten, waaronder het mislukken van Kerberos-verificatie en onregelmatige of niet-bestaande toepassing van beleid. Als u deze problemen wilt voorkomen, gebruikt u Beveiligingsomzetting in plaats van sIDHistory als de langetermijnoplossing voor het onderhouden van resourcetoegang na een domeinmigratie.