Freigeben über

Problembehandlung bei der Inter-Forest sIDHistory-Migration mit ADMTv2

In diesem Artikel wird beschrieben, wie Sie probleme mit der SIDHistory-Migration zwischen Gesamtstrukturen mit Active Directory Migration Tool Version 2 (ADMTv2) beheben.

Ursprüngliche KB-Nummer: 322970

Weitere Informationen

Wenn Sie ADMTv2 zum Migrieren von sIDHistory als Teil einer Gesamtstrukturbenutzer- oder Gruppenmigration verwenden, ist die Konfiguration mit den Basismigrationsanforderungen erforderlich.

Standardmäßig werden sIDHistory, password und objectGUID während der Migrationen innerhalb der Gesamtstruktur beibehalten, dies gilt jedoch nicht für das Klonen zwischen Gesamtstrukturen.

Da es keinen integrierten Sicherheitskontext für Gesamtstrukturvorgänge 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 Benutzer- und Gruppenkontomigration ohne sIDHistory

  • Die Quelldomäne muss der Zieldomäne vertrauen.
  • Das Benutzerkonto, das ADMTv2 ausführt, muss über Administratorrechte in der Quelldomäne verfügen.
  • Das ADMT-Benutzerkonto muss über delegierte Berechtigungen zum Erstellen von Benutzer- oder Gruppenobjekten im Zielcontainer verfügen.
  • 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 rufen diese Benutzer- und Gruppenverwaltungsüberwachung auf.
  • Eine leere lokale Gruppe in der Quelldomäne, die den Namen {SourceNetBIOSDom}$$$ hat.
  • Der HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportRegistrierungsschlüssel muss auf 1 auf dem primären Quelldomänendomänencontroller festgelegt werden.
  • Sie müssen den primären Domänencontroller der Quelldomäne nach der Registrierungskonfiguration neu starten.
  • Windows-Sicherheit erfordert Benutzeranmeldeinformationen mit den delegierten MigratesIDHistory erweiterten 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 MigrateSidHistory-Paket auf einem Domänencontroller oder auf einem Computer zu delegieren, auf dem das Windows Server-Verwaltungstools-Paket installiert ist:

  1. Klicken Sie auf Start, zeigen Sie auf Verwaltung, und klicken Sie dann auf Active Directory-Benutzer und -Computer.
  2. Klicken Sie mit der rechten Maustaste auf den Namen der Domäne, von der Sie die MigrateSidHistory delegieren möchten, und klicken Sie dann auf "Stellvertretungs-Steuerelement" , um das Fenster "Stellvertretung 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 im Dialogfeld "Benutzer, Computer oder Gruppen auswählen" hinzufügen möchten, klicken Sie auf "OK", und klicken Sie dann auf "Weiter".
  4. Klicken Sie, um die Option "Benutzerdefinierte Aufgabe zum Delegieren " auszuwählen, und klicken Sie dann auf "Weiter".
  5. Stellen Sie sicher, dass der Ordner "Dieser Ordner", vorhandene Objekte in diesem Ordner und das Erstellen neuer Objekte in dieser Ordneroption 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. Stellen Sie sicher, dass die Informationen korrekt sind, und klicken Sie dann auf "Fertig stellen".
    • In der Zielstruktur kann keine sID migriert werden, entweder als primäre sID oder als sIDHistory-Attribut eines anderen Objekts.

Zusätzliche Anforderungen für die Migration von sIDHistory mit den Befehlszeilen- oder Skriptschnittstellen

  • Wenn Sie eine Benutzer- oder Gruppenmigration mit der sIDHistory-Migration über die Befehlszeile oder von einem Skript 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 über Administratorrechte sowohl in der Quelle als auch in den Zieldomänen verfügen.

Spezielle Anforderungen für die Gruppenzuordnung und das Zusammenführen des Assistenten

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

Problembehandlung

Der grundlegendste Schritt, mit dem Sie die Migration zwischen gesamtstrukturübergreifender SIDHistory-Migration behandeln können, besteht darin, den Assistenten für die Migration von Benutzerkonten oder den Gruppenkontomigrations-Assistenten zum Ausführen einer Testmodusmigration zu verwenden.

Während der Testmodusmigration überprüft ADMTv2 die folgenden Abhängigkeiten:

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

Optional kann ADMT jede dieser Abhängigkeiten reparieren, die nicht festgelegt sind. Um diese Einstellungen zu reparieren oder zu konfigurieren, muss das Konto, das zum Ausführen von ADMT verwendet wird, über ausreichende Berechtigungen in jeder jeweiligen Domäne verfügen, um die Aufgaben auszuführen.

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

Häufige Fehlermeldungen mit der sIDHistory-Migration in der Gesamtstruktur

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

Dieser Fehler gibt ein RPC-Problem an, bei dem das Migrationstool nicht an einen RPC-Endpunkt auf dem primären Quelldomänencontroller gebunden werden kann. Mögliche Ursachen sind:

  • TcpipClientSupport für den primären Quelldomänencontroller oder den primären Domänencontroller-Emulator wurde nicht aktiviert.
  • Der primäre Domänencontroller oder der primäre Domänencontroller-Emulator 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 Sids können 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 Sids können nicht migriert werden. Zugriff verweigert.

Dieser Fehler weist in der Regel darauf hin, dass das Benutzerkonto, das zum Ausführen von ADMT verwendet wird, nicht über ausreichende Berechtigungen zum Ausführen der Migration in einer oder beiden Domänen verfügt. Fehler beim Nachschlagen des Domänennamens, 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 Vertrauensmigration aus, um die Vertrauensstellungen in der Quelldomäne zuzuordnen und dann die Beziehungen in der Zieldomäne zu replizieren.

Zusätzliche sIDHistory-Informationen

Die sIDHistory ist ein mehrwertiges Attribut von Sicherheitsprinzipalen in Active Directory, das bis zu 850 Werte enthalten kann. Zur Bereitstellung der Abwärtskompatibilität mit Domänencontrollern, die frühere Versionen von Windows ausführen, ist das sIDHistory-Attribut nur in Domänen verfügbar, die auf der Funktionalen Ebene von Windows ausgeführt werden.

Einige Drittanbieterprodukte 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, ihre Active Directory-Bereitstellung in einen nicht unterstützten Zustand zu versetzen.

Bei Migrationen innerhalb der Gesamtstruktur ist LDAP_Rename für das Verschieben von Objekten verantwortlich. Aus diesem Gründen behalten migrierte Objekte wichtige Identifikationsdaten bei, einschließlich objectGUID und Kennwort. Dies ist nicht der Fall 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 werden, während dieser Art der Migration geht die ObjectGUID jedoch immer verloren.

In beiden Fällen werden migrierte Objekte 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 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 Microsoft-internen Tools zu löschen.

Beachten Sie, dass die sIDHistory ein Übergangstool ist und nicht unbegrenzt an Sicherheitsprinzipale angefügt werden soll. Obwohl die Migration der sIDHistory den Domänenmigrationsprozess erheblich vereinfachen und vereinfachen kann, gibt es wichtige Sicherheitsausdrücke, 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 fehlerhafter oder nicht vorhandener 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.