Fehler 1500 (Win32Err=5) bei Computer- & Profilmigration mit externer Domänenvertrauensstellung
Wenn CopyRight2 Computer & Profile Migration einen Client auf die Migration vorbereitet, kann das Clientprotokoll mit CopyRight2-Fehler 1500, Zugriff verweigert und Win32Err=5 abbrechen. Obwohl die Meldung wie ein Berechtigungsproblem aussieht, tritt dieses Verhalten in der standardmäßigen vertrauensstellungsbasierten Migrationskonfiguration auf, nachdem RC4 durch die Windows-Updates vom April 2026 deaktiviert wurde. Windows leitet dabei die hostbasierte Kerberos-Anforderung an den Ziel-Domänencontroller nicht an den richtigen Realm weiter.
Warum „Zugriff verweigert“ irreführend sein kann
In der Standardkonfiguration vertraut die Zieldomäne der Quelldomäne. Mit dieser Vertrauensrichtung kann CopyRight2 die Migration ohne separates Konto für den Domänenbeitritt durchführen: Dem Computerkonto der Quelle werden auf dem Zielcomputerobjekt die für den Domänenbeitritt erforderlichen Berechtigungen erteilt. Der CopyRight2-Client gehört weiterhin zur Quelldomäne und kontaktiert einen Ziel-Domänencontroller über die externe Domänenvertrauensstellung.
Der Agent von CopyRight2 Computer & Profile Migration wird als LocalSystem ausgeführt. Windows greift deshalb mit dem Computerkonto der Quelldomäne auf den Ziel-Domänencontroller zu, nicht mit dem interaktiven Konto des aktuell angemeldeten Benutzers. Während der Vorbereitung ruft CopyRight2 Informationen zur Zieldomäne ab, darunter deren Domänen-SID. Kann Kerberos die Anforderung nicht korrekt weiterleiten, schlägt diese Abfrage fehl und das Clientprotokoll meldet Fehler 1500 sowie Win32-Fehler 5. Die Meldung Zugriff verweigert ist daher irreführend, obwohl die erforderlichen Berechtigungen für den Domänenbeitritt korrekt zugewiesen wurden.
Die Vertrauensstellung selbst kann weiterhin funktionieren. In einer als LocalSystem ausgeführten Eingabeaufforderung kann Windows erfolgreich das domänenübergreifende Ticket-Granting-Ticket abrufen:
klist get krbtgt/TARGET.COM
Anschließend kann Windows jedoch die hostbasierte Dienstanforderung für den Ziel-Domänencontroller nicht an den Realm TARGET.COM weiterleiten:
klist get cifs/dstdc.target.com
Das domänenübergreifende TGT ist somit erfolgreich, während die Anforderung des CIFS-Diensttickets fehlschlägt. Mit einer Gesamtstrukturvertrauensstellung funktioniert dieselbe Abfrage. Dieser Artikel behandelt die oben beschriebene externe Domänenvertrauensstellung und den standardmäßigen CopyRight2-Ablauf. Andere Fälle von CopyRight2-Fehler 1500 können andere Ursachen haben.
Problem als LocalSystem diagnostizieren
Sie können die relevanten Prüfungen reproduzieren, ohne die vollständige Migration auszuführen. Öffnen Sie mit Microsoft Sysinternals PsExec eine Eingabeaufforderung als LocalSystem:
psexec.exe -accepteula -i -s cmd.exe
Prüfen Sie im neuen Fenster den Sicherheitskontext und testen Sie beide Ticketanforderungen:
whoami
klist get krbtgt/TARGET.COM
klist get cifs/dstdc.target.com
whoami sollte nt authority\system zurückgeben. Ist die TGT-Anforderung erfolgreich, aber die CIFS-Anforderung für den Ziel-Domänencontroller schlägt fehl, weil Windows den falschen Realm auswählt, richten Sie eine Kerberos-Host-to-Realm-Zuordnung ein.
Lösung: Ziel-Domänencontroller seinem Realm zuordnen
Führen Sie diese Befehle in der LocalSystem-Eingabeaufforderung aus:
ksetup /addhosttorealmmap dstdc.target.com TARGET.COM
klist purge
klist get cifs/dstdc.target.com
Verwenden Sie den exakten vollqualifizierten Domänennamen des Ziel-Domänencontrollers, den CopyRight2 kontaktiert. Der Befehl ksetup addhosttorealmmap ordnet diesen Hostnamen dem Kerberos-Realm der Zieldomäne zu. Durch das Leeren des LocalSystem-Ticketcaches verwendet die nächste Anforderung die neue Zuordnung.
Nachdem das CIFS-Dienstticket erfolgreich ausgestellt wurde, wird die Abfrage der Zieldomäne abgeschlossen, CopyRight2 ruft die Domänen-SID ab und die Vorbereitung von Computer & Profile Migration wird fortgesetzt.
Eine Host-to-Realm-Zuordnung korrigiert ausschließlich die Kerberos-Weiterleitung. Sie behebt weder eine fehlerhafte Vertrauensstellung noch Probleme mit DNS-Auflösung, blockiertem Firewall-Datenverkehr, selektiver Authentifizierung oder tatsächlich fehlenden Berechtigungen. Prüfen Sie diese Bedingungen separat, wenn bereits die TGT-Anforderung fehlschlägt oder die zugeordnete Dienstanforderung weiterhin einen Fehler zurückgibt.
Die Vertrauensrichtung ist umgekehrt zu der üblicherweise für SID-History verwendeten Richtung. Im Artikel zur Kerberos-Fehlerbehebung für SID-History vertraut die Quelldomäne der Zieldomäne, damit ein migrierter Benutzer der Zieldomäne auf Ressourcen in der Quelldomäne zugreifen kann. In der hier beschriebenen Standardkonfiguration von CopyRight2 Computer & Profile Migration vertraut dagegen die Zieldomäne der Quelldomäne, und ein zur Quelle gehörendes Computerkonto greift auf den Ziel-Domänencontroller zu.