Behandlung von sIDHistory gesamtstrukturübergreifende Migration mit ADMTv2

Dieser Artikel beschreibt die Behandlung von sIDHistory gesamtstrukturübergreifende Migration mit Active Directory Migration Tool Version 2 (ADMTv2).

Wenn Sie zum Migrieren von sIDHistory als Teil einer gesamtstrukturübergreifende Benutzer oder Gruppe Migration ADMTv2 verwenden, ist die Konfiguration die Basis Migration Anforderungen erforderlich.

In der Standardeinstellung SID-Verlauf, Kennwort und Objekt-GUID bleiben alle bei Migrationen innerhalb einer Gesamtstruktur, aber dies gilt nicht für gesamtstrukturübergreifende klonen.

Da es keine integrierten Sicherheitskontext für gesamtstrukturübergreifende Vorgänge gibt, müssen Sie die Schritte zum Schutz der Sicherheit von Vorgängen über Grenzen hinweg Gesamtstruktur ausführen.

Konfiguration

Die grundlegenden Anforderungen für die gesamtstrukturübergreifende Migration Operationen sind:

Assistenten basierende grundlegenden Benutzer- und Konto Migration ohne sIDHistory

• Die Quelldomäne muss die Zieldomäne vertrauen.
• Die Quelldomäne muss ausgeführt werden Microsoft Windows NT 4.0 Service Pack 4 (SP4) oder höher.
• Die Zieldomäne muss im einheitlichen Modus von Microsoft Windows 2000 oder höher sein.
• Das Benutzerkonto, auf dem ADMTv2 ausgeführt wird, muss über Administratorrechte in der Quelldomäne haben.
• Die ADMT-Benutzerkontos muss Berechtigungen zum Erstellen von Benutzer- oder Gruppenobjekte in den Zielcontainer delegiert haben.
• DNS (Hostname) und NetBIOS-Namensauflösung zwischen den Domänen müssen vorhanden sein.

sIDHistory Migration erfordert die folgenden zusätzlichen Abhängigkeiten

• Erfolgs- und Fehlerüberwachung der Kontenverwaltung für sowohl Quell- und Zieldomänen.
• Windows NT 4.0-Quelldomänen rufen Sie diese Benutzer und Gruppe Management Überwachung.
• Eine leere lokale Gruppe in der Quelldomäne mit der Bezeichnung {SourceNetBIOSDom} $ $ $.
• Der HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport-Registrierungsschlüssel muss auf 1 auf dem primären Domänencontroller der Domäne "Quelle festgelegt werden.
• Sie müssen den primäre Domänencontroller der Domäne "Quelle nach der Registrierungskonfiguration der neu starten.
• Wenn die Zieldomäne eine Windows 2000-Domäne Windows ist die Sicherheit erfordert Anmeldeinformationen von Benutzern mit Administratorrechten in der Zieldomäne. Sie fügen diese Anmeldeinformationen im Assistenten, wenn sIDHistory Migration aktiviert ist.
  
  So delegieren die MigrateSidHistory erweiterte Rechte auf einem Microsoft Windows Server-Domänencontroller oder auf einem Computer, auf dem das Windows Server 2003 Administration Tools Pack installiert ist, gehen Sie folgendermaßen vor:
  1. Klicken Sie auf Start, klicken 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, die den MigrateSidHistory nach rechts aus, die delegiert werden soll, und klicken Sie dann auf Objektverwaltung zuweisen, um das Fenster Des Assistenten zu öffnen.
  3. Klicken Sie auf Weiter, klicken Sie auf Hinzufügen, geben Sie den Namen des Benutzers oder der Gruppe, die Sie verwenden möchten, klicken Sie im Dialogfeld Benutzer, Computer oder Gruppen hinzuzufügen, klicken Sie auf OK, und klicken Sie dann auf Weiter.
  4. Klicken Sie hier, um die Option benutzerdefinierte Tasks zum Delegieren erstellen aktivieren, und klicken Sie dann auf Weiter.
  5. Stellen Sie sicher, dass die diesem Ordner, bestehenden Objekten in diesem Ordner und neuen Objekten in diesem Ordner Option ausgewählt ist, und klicken Sie dann auf Weiter.
  6. Stellen Sie sicher, dass die Allgemeine Option 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.
• Wenn die Zieldomäne eine Windows Server 2003-Domäne ist, erfordert Windows-Sicherheit Benutzeranmeldeinformationen mit delegierten MigratesIDHistory rechts oder über Administratorrechte in der Zieldomäne erweitert.
• Keine sID migriert werden kann in der Zielgesamtstruktur, entweder als eine primäre sID oder als Attribut sIDHistory eines anderen Objekts vorhanden sein.

Zusätzliche Anforderungen für das Migrieren von sIDHistory mit der Befehlszeile oder Skripterstellung Schnittstellen

• Wenn Sie einen Benutzer oder Gruppe Migration mit sIDHistory Migration aus der Command line oder ein Skript starten, muss der Befehl oder das Skript auf dem Domänencontroller in der Zieldomäne ausgeführt werden.
• Das Benutzerkonto, das die Migration ausgeführt wird, muss über Administratorrechte in der Quell- und Zieldomänen verfügen.

Besondere Anforderungen für Gruppe zuordnen und Zusammenführen von Assistenten

• Wenn SID-Verlauf migriert werden, während der Gruppe zuordnen und zusammenführen, muss der Gültigkeitsbereich der Quellgruppen den Bereich der Zielgruppe entsprechen.

Problembehandlung

Die grundlegendste Schritt, die Sie verwenden können, um die gesamtstrukturübergreifende sIDHistory Migration Problembehandlung besteht darin, den Assistenten zum Migrieren von Benutzerkonten oder die Assistenten verwenden, um ein test-mode-Migration auszuführen.

Während der Migration test-mode überprüft ADMTv2 die folgenden Abhängigkeiten:

• Die {SourceNetBIOSDom} $ $ $ lokale Gruppe wird erstellt.
• "TcpipClientSupport" auf dem primären Quelldomänencontroller oder Emulator primary Domain Controller ist aktiviert.
• In beiden Domänen Überwachung ist aktiviert.

ADMT kann optional alle diese Abhängigkeiten reparieren, die nicht festgelegt werden. Reparieren oder diese Einstellungen konfigurieren, muss das Konto, mit dem ADMT ausgeführt, genügend Berechtigungen in jeder jeweiligen Domäne zum Durchführen der Aufgaben verfügen.

Beachten Sie, dass nur der Assistent führt diese Überprüfungen und Korrekturen. Die Befehlszeile und scripting Schnittstellen diese Überprüfungen nicht ausführen, und funktionieren nicht, ohne eine korrekte Konfiguration.

Häufige Fehlermeldungen mit sIDHistory gesamtstrukturübergreifende Migration

Dieser Fehler weist darauf hin, ein RPC-Problem, in dem das Tool Migration an einen RPC-Endpunkt auf dem primären Quelldomänencontroller binden kann. Mögliche Ursachen sind:

• "TcpipClientSupport" auf dem primären Quelldomänencontroller oder Emulator primary Domain Controller wurde nicht aktiviert.
• Der primäre Domänencontroller oder der Emulator primary Domain Controller wurde nicht neu gestartet, nachdem "TcpipClientSupport" konfiguriert wurde.
• DNS- oder NetBIOS-Namensauflösung funktioniert nicht.

Dieser Fehler weist normalerweise darauf hin, dass ein Benutzer oder eine globale oder universelle Gruppe mit Namen $ $ $ {SourceNetBIOSDom} bereits vorhanden ist. ADMT erstellt in der Regel die lokale Gruppe mit dem Namen, aber es kann nicht dazu Wenn ein Sicherheitsprinzipal mit dem Namen bereits vorhanden ist. Dieser Fehler weist normalerweise darauf hin, dass das Benutzerkonto, das zum Ausführen von ADMT ist nicht genügend Berechtigungen zum Durchführen der Migration in eine oder beide der Domänen verfügt. Dieser Fehler in der Datei "Migration.log" nach einer Migration mit dem Attribut sIDHistory ist in der Regel ein Hinweis darauf, dass die Quelldomäne Vertrauensstellungen konfiguriert hat, die nicht auf der Zieldomäne vorhanden sind. Um dieses Problem zu beheben, führen Sie den Assistenten zum Migrieren der Vertrauensstellung, die Vertrauensstellungen in der Quelldomäne zuzuordnen, und replizieren Sie die Beziehungen in der Zieldomäne zu.

Zusätzliche sIDHistory-Informationen

Die SID-Verlauf ist ein mehrwertiges Attribut der Sicherheitsprinzipale in Active Directory, die bis zu 850 Werte enthalten kann. Abwärtskompatibilität mit Domänencontrollern bereitstellen, auf denen frühere Versionen von Windows ausgeführt wird, steht das Attribut sIDHistory nur in Domänen, die auf der Funktionsebene von Windows 2000 pur-Modus oder höher ausgeführt werden.

Einige Fremdanbieter-Produkte ermöglichen das sIDHistory in Domänen im gemischten Modus zu aktivieren. Diese Ansprüche repräsentieren nicht die zulässige Verwendung von öffentlichen APIs. Domänenadministratoren, die solche Tools verwenden, riskieren Ihre Active Directory Bereitstellung in einem nicht unterstützten Zustand versetzen.

Bei Migrationen innerhalb einer Gesamtstruktur ist LDAP_Rename für das Verschieben von Objekten verantwortlich. Aus diesem Grund behalten die migrierten Objekte wichtig Kennung Daten, einschließlich der Objekt-GUID und das Kennwort. Dies ist nicht der Fall für gesamtstrukturübergreifende Migrationen, die DSAddSidHistory zum Auffüllen des Attributs in der Zieldomäne aufrufen. Kennwort Migration kann für gesamtstrukturübergreifende Klonen aktiviert werden, aber der Objekt-GUID ist bei dieser Art von Migration immer verloren gehen.

In beiden Fällen werden die migrierten Objekte durch die Zieldomäne eine neue sID zugewiesen. Die ursprüngliche sID wird das Attribut sIDHistory des migrierten-Objekts in der neuen Domäne hinzugefügt. Nach dem in diesem Fall das Attribut sIDHistory möglicherweise nicht geändert oder mithilfe der Active Directory-Verwaltungsprogrammen gelöscht. Dies ist nicht zulässig, da das Attribut sIDHistory der SICHERHEITSKONTENVERWALTUNG gehört. Es ist möglich, die SID-Verlauf löschen, indem Sie ein Skript oder ein interner nicht öffentlichen Microsoft-Tool.

Beachten Sie, dass die SID-Verlauf ein Übergangs Tool ist und ist nicht vorhanden ist vorgesehen, Sicherheitsprinzipale auf unbestimmte Zeit zugeordnet. Obwohl die SID-Verlauf migrieren kann erheblich vereinfachen und die Domäne Migration vereinfachen, sind wichtige Sicherheitsverzweigungen, die berücksichtigt werden müssen, bevor Sie die SID-Verlauf in einer Organisation Produktion implementieren.

Ein Windows 2000-Sicherheitstoken kann maximal 1.023 enthalten sIDs, einschließlich der SID-Verlauf und sIDs gruppieren. Kerberos ist auch eingeschränkt, da Windows 2000 Kerberos einen Puffer 73-sID hat. Nachdem Sie Windows 2000 Service Pack 2 (SP2) installiert haben, kann diese Größe durch eine Registrierungsänderung unternehmensweite verdoppelt. Diese Grenzwerte überschreiten die MaxTokenSize-Einschränkung verletzt und kann zu unvorhersehbaren Ergebnissen, einschließlich Fehlschlagen der Kerberos-Authentifizierung und fehlerhaft oder nicht vorhandene Anwendung von Richtlinien führen. Um diese Probleme zu verhindern, verwenden Sie Sicherheitskonvertierungs anstelle von sIDHistory als langfristige Lösung für die Aufrechterhaltung der Zugriff auf Ressourcen nach einer Domäne Migration.