Problembehandlung bei der gesamtstrukturübergreifenden sIDHistory-Migration mit ADMTv2

In diesem Artikel wird beschrieben, wie Sie Probleme mit der gesamtstrukturübergreifenden sIDHistory-Migration mit active Directory-Migrationstool, Version 2 (ADMTv2), beheben.

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 322970

Weitere Informationen

Wenn Sie ADMTv2 zum Migrieren von sIDHistory im Rahmen einer Gesamtstruktur- oder Gruppenmigration verwenden, ist eine Konfiguration mit den Grundlegenden Migrationsanforderungen erforderlich.

Standardmäßig bleiben sIDHistory, password und objectGUID bei Migrationen innerhalb der Gesamtstruktur erhalten, was jedoch nicht für das Klonen zwischen Gesamtstrukturen gilt.

Da es keinen integrierten Sicherheitskontext für Vorgänge zwischen Gesamtstrukturen gibt, müssen Sie Maßnahmen ergreifen, um die Sicherheit von Vorgängen über Gesamtstrukturgrenzen hinweg zu schützen.

Konfiguration

Die grundlegenden Anforderungen für Gesamtstrukturmigrationsvorgänge sind:

Assistentenbasierte grundlegende Migration von Benutzer- und Gruppenkonten ohne sIDHistory

  • Die Quelldomäne muss der Zieldomäne vertrauen.
  • Das Benutzerkonto, auf dem ADMTv2 ausgeführt wird, muss über Administratorrechte in der Quelldomäne verfügen.
  • Das ADMT-Benutzerkonto muss über delegierte Berechtigungen verfügen, um Benutzer- oder Gruppenobjekte im Zielcontainer zu erstellen.
  • DNS (Hostname) und NetBIOS-Namensauflösung zwischen den Domänen müssen vorhanden sein.

Die sIDHistory-Migration erfordert die folgenden zusätzlichen Abhängigkeiten

  • Erfolgs- und Fehlerüberwachung der Kontoverwaltung für Quell- und Zieldomänen.
  • Quelldomänen nennen diese Benutzer- und Gruppenverwaltungsüberwachung.
  • Eine leere lokale Gruppe in der Quelldomäne namens {SourceNetBIOSDom}$$$.
  • Der HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportRegistrierungsschlüssel muss für den primären Domänencontroller der Quelldomäne auf 1 festgelegt sein.
  • Sie müssen den primären Domänencontroller der Quelldomäne nach der Registrierungskonfiguration neu starten.
  • Die Windows-Sicherheit erfordert Benutzeranmeldeinformationen mit den delegierten erweiterten MigratesIDHistory-Rechten oder Administratorrechten in der Zieldomäne. Sie fügen diese Anmeldeinformationen im Assistenten hinzu, wenn die sIDHistory-Migration aktiviert ist.

Führen Sie die folgenden Schritte aus, um das erweiterte MigrateSidHistory-Element direkt auf einem Domänencontroller oder auf einem Computer zu delegieren, auf dem das Windows Server Administration Tools Pack installiert ist:

  1. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
  2. Klicken Sie mit der rechten Maustaste auf den Namen der Domäne, von der Sie die "MigrateSidHistory"-Erweiterung direkt delegieren möchten, und klicken Sie dann auf " Stellvertretungssteuerelement ", um das Fenster "Delegierung des Steuerelement-Assistenten" zu öffnen.
  3. Klicken Sie auf "Weiter", klicken Sie auf "Hinzufügen", geben Sie den Namen des Benutzers oder der Gruppe ein, den Sie hinzufügen möchten, im Dialogfeld "Benutzer, Computer oder Gruppen auswählen ", klicken Sie auf "OK", und klicken Sie dann auf "Weiter".
  4. Klicken Sie, um die Option "Benutzerdefinierte Aufgabe zum Delegieren erstellen " auszuwählen, und klicken Sie dann auf "Weiter".
  5. Stellen Sie sicher, dass die Option "Dieser Ordner", die vorhandenen Objekte in diesem Ordner und die Erstellung neuer Objekte in diesem Ordner ausgewählt ist, und klicken Sie dann auf "Weiter".
  6. Stellen Sie sicher, dass die Option "Allgemein" ausgewählt ist, klicken Sie in der Liste "Berechtigungen" auf "SID-Verlauf migrieren", und klicken Sie dann auf "Weiter".
  7. Vergewissern Sie sich, dass die Informationen korrekt sind, und klicken Sie dann auf "Fertig stellen".
    • Es kann keine zu migrierende sID in der Zielgesamtstruktur vorhanden sein, weder als primäre sID noch als sIDHistory-Attribut eines anderen Objekts.

Zusätzliche Anforderungen für die Migration von sIDHistory mit der Befehlszeile oder Skriptschnittstellen

  • Wenn Sie eine Benutzer- oder Gruppenmigration mit der sIDHistory-Migration von der Befehlszeile oder von einem Skript aus starten, muss der Befehl oder das Skript auf dem Domänencontroller in der Zieldomäne ausgeführt werden.
  • Das Benutzerkonto, das die Migration ausführt, muss sowohl in der Quell- als auch in der Zieldomäne über Administratorrechte verfügen.

Besondere Anforderungen für den Assistenten für die Gruppenzuordnung und -zusammenführung

  • Wenn sIDHistory während der Gruppenzuordnung und -zusammenführung migriert werden soll, muss der Bereich der Quellgruppen mit dem Bereich der Zielgruppe übereinstimmen.

Problembehandlung

Der einfachste Schritt, den Sie für die Problembehandlung bei der gesamtstrukturübergreifenden sIDHistory-Migration verwenden können, ist die Verwendung des Assistenten für die Benutzerkontenmigration oder des Assistenten für die Gruppenkontomigration, um eine Migration im Testmodus auszuführen.

Während der Migration des Testmodus überprüft ADMTv2 die folgenden Abhängigkeiten:

  • Die lokale Gruppe {SourceNetBIOSDom}$$$ wird erstellt.
  • TcpipClientSupport für den primären Quelldomänencontroller oder den Emulator für den primären Domänencontroller ist aktiviert.
  • Die Überwachung in beiden Domänen ist aktiviert.

Optional kann ADMT alle diese nicht festgelegten Abhängigkeiten reparieren. Um diese Einstellungen zu reparieren oder zu konfigurieren, muss das Konto, das zum Ausführen von ADMT verwendet wird, über genügend Berechtigungen in jeder entsprechenden Domäne verfügen, um die Aufgaben ausführen zu können.

Nur der Assistent führt diese Prüfungen und Korrekturen aus. Die Befehlszeilen- und Skriptschnittstellen führen diese Prüfungen nicht aus und funktionieren nicht ohne die richtige Konfiguration.

Allgemeine Fehlermeldungen bei der gesamtstrukturübergreifenden sIDHistory-Migration

"Das Handle ist ungültig (Fehlercode = 6)."

Dieser Fehler weist auf ein RPC-Problem hin, bei dem das Migrationstool keine Bindung an einen RPC-Endpunkt auf dem primären Quelldomänencontroller herstellen kann. Zu den möglichen Ursachen gehören:

  • TcpipClientSupport für den primären Quelldomänencontroller oder den Emulator für den primären Domänencontroller wurde nicht aktiviert.
  • Der primäre Domänencontroller oder der Emulator für den primären Domänencontroller wurde nach der Konfiguration von TcpipClientSupport nicht neu gestartet.
  • DIE DNS- oder NetBIOS-Namensauflösung funktioniert nicht.

Überwachung und TcpipClientSupport für Domänen konnten nicht überprüft werden. Die Sid kann nicht migriert werden. Die angegebene lokale Gruppe ist nicht vorhanden.

Dieser Fehler weist in der Regel darauf hin, dass ein Benutzer oder eine globale oder universelle Gruppe mit dem Namen {SourceNetBIOSDom}$$$$ bereits vorhanden ist. ADMT erstellt in der Regel die lokale Gruppe dieses Namens, kann dies jedoch nicht tun, wenn bereits ein Sicherheitsprinzipal mit dem Namen vorhanden ist.

Überwachung und TcpipClientSupport für Domänen konnten nicht überprüft werden. Die Sid kann nicht migriert werden. Der Zugriff wurde verweigert.

Dieser Fehler weist in der Regel darauf hin, dass das Benutzerkonto, das zum Ausführen von ADMT verwendet wird, nicht über ausreichende Berechtigungen verfügt, um die Migration in einer oder beiden Domänen durchzuführen. Fehler bei der Domänennamensuche, rc=1332. Es wurde keine Zuordnung zwischen Kontonamen und Sicherheits-IDs durchgeführt. Dieser Fehler in der Datei "Migration.log" nach einer Migration mit "sIDHistory" weist in der Regel darauf hin, dass die Quelldomäne Vertrauensstellungen konfiguriert hat, die in der Zieldomäne nicht vorhanden sind. Um dieses Problem zu beheben, führen Sie den Assistenten für die Vertrauensstellungsmigration aus, um die Vertrauensstellungen in der Quelldomäne zuzuordnen, und replizieren Sie dann die Beziehungen in der Zieldomäne.

Zusätzliche sIDHistory-Informationen

Die sIDHistory ist ein mehrwertiges Attribut von Sicherheitsprinzipalen im Active Directory, das bis zu 850 Werte enthalten kann. Um Abwärtskompatibilität mit Domänencontrollern zu gewährleisten, auf denen frühere Versionen von Windows ausgeführt werden, ist das sIDHistory-Attribut nur in Domänen verfügbar, die auf der Funktionsebene von Windows ausgeführt werden.

Einige Produkte von Drittanbietern ermöglichen es, sIDHistory in Domänen mit gemischten Modus zu aktivieren. Diese Ansprüche stellen nicht die legitime Verwendung öffentlicher APIs dar. Domänenadministratoren, die solche Tools verwenden, riskieren, dass ihre Active Directory-Bereitstellung in einen nicht unterstützten Zustand versetzt wird.

Bei Migrationen innerhalb der Gesamtstruktur ist LDAP_Rename für das Verschieben von Objekten verantwortlich. Aus diesem Grund behalten migrierte Objekte wichtige Identifikationsdaten, einschließlich objectGUID und Kennwort, bei. Dies gilt nicht für Gesamtstrukturmigrationen, die DSAddSidHistory aufrufen, um das Attribut in der Zieldomäne aufzufüllen. Die Kennwortmigration kann für das Klonen zwischen Gesamtstrukturen aktiviert sein, aber die objectGUID geht bei dieser Art der Migration immer verloren.

In beiden Fällen wird migrierten Objekten von der Zieldomäne eine neue sID zugewiesen. Die ursprüngliche sID wird dem sIDHistory-Attribut des migrierten Objekts in der neuen Domäne hinzugefügt. Danach kann das sIDHistory-Attribut nicht mehr mithilfe der standardmäßigen Active Directory-Verwaltungstools geändert oder gelöscht werden. Dies ist nicht zulässig, da das sIDHistory-Attribut dem SAM gehört. Es ist möglich, die sIDHistory mithilfe eines Skripts oder eines nicht öffentlichen internen Microsoft-Tools zu löschen.

Beachten Sie, dass es sich bei der sIDHistory um ein Übergangstool handelt, das nicht unbegrenzt an Sicherheitsprinzipale angefügt sein soll. Obwohl die Migration der sIDHistory den Domänenmigrationsprozess erheblich vereinfachen und vereinfachen kann, gibt es wichtige Sicherheitsverzweigungen, die berücksichtigt werden müssen, bevor Sie die sIDHistory in einem Produktionsunternehmen implementieren.

Ein Windows-Sicherheitstoken kann maximal 1.023 sIDs enthalten, einschließlich sIDHistory und Gruppen-SIDs. Kerberos ist auch eingeschränkt, da Windows Kerberos über einen 73-sID-Puffer verfügt. Diese Größe kann durch eine unternehmensweite Registrierungsänderung verdoppelt werden. Das Überschreiten dieser Grenzwerte verstößt gegen die MaxTokenSize-Einschränkung und kann zu unvorhersehbaren Ergebnissen führen, einschließlich eines Ausfalls der Kerberos-Authentifizierung und einer fehlerhaften oder nicht vorhandenen Anwendung von Richtlinien. Um diese Probleme zu vermeiden, verwenden Sie die Sicherheitsübersetzung anstelle von sIDHistory als langfristige Lösung, um den Ressourcenzugriff nach einer Domänenmigration aufrechtzuerhalten.