Problembehandlung bei Active Directory-Replikationsfehler 5 in Windows Server: Zugriff verweigert

In diesem Artikel werden die Symptome, Ursachen und Auflösung von Situationen beschrieben, in denen die Active Directory-Replikation mit Fehler 5 fehlschlägt: Der Zugriff wird verweigert.

Ursprüngliche KB-Nummer: 3073945

Symptome

Wenn Active Directory-Replikationen mit Fehler 5 fehlschlagen, tritt möglicherweise ein oder mehrere der folgenden Symptome auf.

Symptom 1

Das Dcdiag.exe Befehlszeilentool meldet, dass der Active Directory-Replikationstest mit dem Fehlerstatuscode (5) fehlschlägt. Der Bericht ähnelt dem folgenden Beispiel:

Testing server: <Site_Name>\<Destination_DC_Name>  
Starting test: Replications  
Replications Check  
[Replications Check,<Destination_DC_Name>] A recent replication attempt failed:  
From <Source_DC> to <Destination_DC>  
Naming Context: <Directory_Partition_DN_Path>  
The replication generated an error (5):  
Access is denied.  
The failure occurred at <Date> <Time>.  
The last success occurred at <Date> <Time>.  
<Number> failures have occurred since the last success.

Symptom 2

Das Dcdiag.exe Befehlszeilentool meldet, dass die DsBindWithSpnEx Funktion mit Fehler 5 fehlschlägt, indem sie den DCDIAG /test:CHECKSECURITYERROR Befehl ausführt.

Symptom 3

Das REPADMIN.exe Befehlszeilentool meldet, dass der letzte Replikationsversuch mit Status 5 fehlgeschlagen ist.

Die REPADMIN Befehle, die häufig den Status 5 zitieren, sind jedoch nicht auf die folgenden beschränkt:

• REPADMIN /KCC
• REPADMIN /REPLICATE
• REPADMIN /REPLSUM
• REPADMIN /SHOWREPL
• REPADMIN /SHOWREPS
• REPADMIN /SYNCALL

Die Beispielausgabe des REPADMIN /SHOWREPL Befehls lautet wie folgt. Diese Ausgabe zeigt die eingehende Replikation von DC_2_Name zu DC_1_Name einem Fehler mit dem Fehler "Zugriff verweigert" an.

<Site_Name>\<DC_1_Name>  
DSA Options: IS_GC  
Site Options: (none)  
DSA object GUID: <GUID>  
DSA invocationID: <invocationID>

==== INBOUND NEIGHBORS======================================  
DC= <DomainName>,DC=com  
<Site_Name>\<DC_2_Name> via RPC  
DSA object GUID: <GUID> 
Last attempt @ <Date> <Time> failed, result 5(0x5):  
Access is denied.  
<#> consecutive failure(s).  
Last success @ <Date> <Time>.

Symptom 4

NTDS-KCC-, NTDS-General- oder Microsoft-Windows-ActiveDirectory_DomainService-Ereignisse mit dem Status 5 werden im Verzeichnisdienstprotokoll Ereignisanzeige protokolliert.

In der folgenden Tabelle sind Active Directory-Ereignisse zusammengefasst, die häufig den Status 8524 zitieren, einschließlich, aber nicht beschränkt auf:

Ereignis-ID	`Source`	Ereigniszeichenfolge
1655	NTDS allgemein	Active Directory hat versucht, mit dem folgenden globalen Katalog zu kommunizieren, und die Versuche waren nicht erfolgreich.
1925	NTDS KCC	Beim Versuch, einen Replikationslink für eine beschreibbare Verzeichnispartition herzustellen, ist ein Fehler aufgetreten.
19:26	NTDS KCC	Der Versuch, eine Replikationsverknüpfung mit einer schreibgeschützten Verzeichnispartition herzustellen, bei der die folgenden Parameter fehlgeschlagen sind.

Symptom 5

Wenn Sie mit der rechten Maustaste auf das Verbindungsobjekt von einem Quelldomänencontroller (DC) in Active Directory-Websites und -Diensten klicken und dann "Jetzt replizieren" auswählen, schlägt der Prozess fehl, und Sie erhalten die folgende Fehlermeldung:

Dialogfeldtiteltext: Jetzt replizieren

Text der Dialogfeldnachricht:

Der folgende Fehler ist beim Versuch aufgetreten, den Namenskontext "%<verzeichnispartitionsname>%" vom Domänencontroller-Quell-DC <> mit dem Domänencontroller-Ziel-DC <>zu synchronisieren: Der Zugriff wird verweigert.

Der Vorgang wird nicht fortgesetzt.

Der folgende Screenshot stellt ein Beispiel für den Fehler dar:

Problemumgehung

Verwenden Sie die generischen DCDIAG - und NETDIAG Befehlszeilentools, um mehrere Tests auszuführen. Verwenden Sie das DCDIAG /TEST:CheckSecurityError Befehlszeilentool, um bestimmte Tests durchzuführen. (Diese Tests umfassen eine SPN-Registrierungsüberprüfung.)

Um dieses Problem zu umgehen, führen Sie die folgenden Schritte aus:

1. Führen Sie an einer Eingabeaufforderung auf dem Zieldomänencontroller aus DCDIAG .
2. Führen Sie DCDIAG /TEST:CheckSecurityError und NETDIAG aus.
3. Beheben Sie alle Fehler, die durch DCDIAGidentifiziert wurden.
4. Wiederholen Sie den zuvor fehlgeschlagenen Replikationsvorgang. Wenn Replikationen weiterhin fehlschlagen, lesen Sie die folgenden Ursachen und Lösungen.

Die folgenden Ursachen können zu Fehler 5 führen. Einige davon haben Lösungen.

Ursache 1: Es ist ein ungültiger Sicherheitskanal oder ein Kennwortkonflikt für die Quell- oder Ziel-DC vorhanden.

Überprüfen Sie den Sicherheitskanal, indem Sie einen der folgenden Befehle ausführen:

• nltest /sc_query:<Domain Name>

• netdom verify <DC Name>

Setzen Sie das Kennwort des Zieldomänencontrollers unter Verwendung NETDOM /RESETPWDvon "Bedingung" zurück.

Lösung

1. Deaktivieren Sie den Kerberos Key Distribution Center (KDC)-Dienst auf dem Zieldomänencontroller.

2. Rufen Sie über eine Eingabeaufforderung mit erhöhten Rechten auf dem Zieldomänencontroller das Kerberos-Ticket des Systems ab, indem Sie folgendes ausführen Klist -li 0x3e7 purge.

3. Führen Sie die Ausführung NETDOM RESETPWD aus, um das Kennwort des Remotedomänencontrollers zurückzusetzen:

   c:\>netdom resetpwd /server:<remote_dc_name> /userd: domain_name\administrator /passwordd: administrator_password
   

4. Stellen Sie sicher, dass die potenziellen KDCs und der Quelldomänencontroller (wenn sie sich in derselben Domäne befinden) eingehend das neue Kennwort des Zieldomänencontrollers replizieren.

5. Starten Sie den KDC-Dienst auf dem Zieldomänencontroller, und wiederholen Sie den Replikationsvorgang.

Weitere Informationen finden Sie unter Verwenden von Netdom.exe zum Zurücksetzen von Computerkonto-Kennwörtern eines Domänencontrollers.

Ursache 2: Die Einstellung "CrashOnAuditFail" in der Registrierung des Ziel-DC weist den Wert "2" auf.

Ein CrashOnAuditFail Wert von 2 wird ausgelöst, wenn das Audit: Herunterfahren des Systems sofort ausgelöst wird, wenn die Richtlinieneinstellung für Sicherheitsüberwachungen in der Gruppenrichtlinie aktiviert ist und das lokale Sicherheitsereignisprotokoll voll ist.

Active Directory-Domänencontroller sind besonders anfällig für Sicherheitsprotokolle mit maximaler Kapazität, wenn die Überwachung aktiviert ist und die Größe des Sicherheitsereignisprotokolls durch die Ereignisse "Nicht überschreiben" (manuelles Löschen des Protokolls) und überschreiben Sie nach Bedarf Optionen in Ereignisanzeige oder deren Gruppenrichtlinienäquivalenten.

Lösung

Wichtig

Dieser Abschnitt, diese Methode bzw. diese Aufgabe enthält eine Beschreibung der Schritte zum Bearbeiten der Registrierung. Durch die falsche Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Daher müssen Sie sicherstellen, dass Sie diese Schritte sorgfältig ausführen. Erstellen Sie eine Sicherungskopie der Registrierung, bevor Sie Änderungen vornehmen, damit Sie die Registrierung wiederherstellen können, falls ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter: Sichern und Wiederherstellen der Registrierung Windows.

1. Löschen Sie das Sicherheitsereignisprotokoll, und speichern Sie es bei Bedarf an einem anderen Speicherort.

2. Bewerten Sie alle Größeneinschränkungen für das Sicherheitsereignisprotokoll neu. Dazu gehören richtlinienbasierte Einstellungen.

3. Löschen Sie einen Registrierungseintrag und erstellen Sie dann wie folgt erneut CrashOnAuditFail :

   Registrierungsunterschlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
   Wertname: CrashOnAuditFail
   Werttyp: REG_DWORD
   Wertdaten: 1

4. Starten Sie den Zieldomänencontroller neu.

Wenn Sie einen CrashOnAuditFail Wert von 0 oder 1sehen, haben einige CSS-Techniker Fehler "Zugriff verweigert" behoben, indem Sie das Sicherheitsereignisprotokoll erneut löschen, den CrashOnAuditFail Registrierungswert löschen und den Zieldomänencontroller neu starten.

Weitere Informationen finden Sie unter Verwalten der Überwachung und des Sicherheitsprotokolls.

Ursache 3: Ungültige Vertrauensstellung (der sichere Kanal auf der Quell- oder Ziel-DC ist ungültig, oder Vertrauensstellungen in der Vertrauenskette sind unterbrochen oder ungültig)

Wenn die Active Directory-Replikation zwischen Domänencontrollern in verschiedenen Domänen fehlschlägt, sollten Sie den Status von Vertrauensstellungen entlang des Vertrauenspfads überprüfen.

Sie können den NetDiag Trust Relationship-Test testen, um auf fehlerhafte Vertrauensstellungen zu überprüfen. Das Hilfsprogramm Netdiag.exe identifiziert fehlerhafte Vertrauensstellungen, indem der folgende Text angezeigt wird:

Trust relationship test. . . . . . : Failed  
Test to ensure DomainSid of domain '<domainname>' is correct.  
[FATAL] Secure channel to domain '<domainname>' is broken.  
[% <variable status code> %]

Wenn Sie beispielsweise über eine Gesamtstruktur mit mehreren Domänen verfügen, die eine Stammdomäne (Contoso.COM), eine untergeordnete Domäne (), eine Untergeordnete Domäne (B.Contoso.COM), eine Enkeldomäne (C.B.Contoso.COM) und eine Strukturdomäne in derselben Gesamtstruktur (Fabrikam.COM) enthält und die Replikation zwischen Domänencontrollern in der Großdomäne (C.B.Contoso.COM) und der Strukturdomäne fehlschlägt (Fabrikam.COM), sollten Sie die Vertrauensintegrität zwischen C.B.Contoso.COM und B.Contoso.COM, zwischen B.Contoso.COM und und und dann schließlich zwischen Contoso.COM und Contoso.COM.Fabrikam.COM

Wenn zwischen den Zieldomänen eine Verknüpfungsvertrauensstellung vorhanden ist, müssen Sie die Vertrauenspfadkette nicht überprüfen. Stattdessen sollten Sie die Verknüpfungsvertrauensstellung zwischen Ziel- und Quelldomäne überprüfen.

Überprüfen Sie, ob zuletzt verwendete Kennwortänderungen an der Vertrauensstellung vorgenommen werden, indem Sie den folgenden Befehl ausführen:

Repadmin /showobjmeta * <DN path for TDO in question>

Stellen Sie sicher, dass der Zieldomänencontroller transitiv eingehende Replikation der schreibbaren Domänenverzeichnispartition erfolgt, bei der Kennwortänderungen für vertrauenswürdige Kennwörter wirksam werden können.

Befehle zum Zurücksetzen von Vertrauensstellungen aus der Stammdomäne PDC lauten wie folgt:

netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay

Befehle zum Zurücksetzen von Vertrauensstellungen aus der untergeordneten Domäne PDC lauten wie folgt:

netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child /PasswordO:* /Reset /TwoWay

Ursache 4: Übermäßige Zeitverknifung

Es gibt einen Zeitunterschied zwischen dem vom Ziel-DC und dem Quell-DC verwendeten KDC. Die Zeitdifferenz überschreitet die maximale Zeitabweichung, die von Kerberos zulässig ist, die in der Standarddomänenrichtlinie definiert ist.

Kerberos-Richtlinieneinstellungen in der Standarddomänenrichtlinie ermöglichen einen fünfminütigen Unterschied in der Systemzeit (dies ist der Standardwert) zwischen KDC-Domänencontrollern und Kerberos-Zielservern, um Replay-Angriffe zu verhindern. In einigen Dokumentationen wird angegeben, dass die Systemzeit des Clients und die des Kerberos-Ziels innerhalb von fünf Minuten voneinander betragen müssen. Andere Dokumentation gibt an, dass im Kontext der Kerberos-Authentifizierung die Zeit, die wichtig ist, das Delta zwischen dem vom Aufrufer verwendeten KDC und der Zeit für das Kerberos-Ziel ist. Außerdem kümmert sich Kerberos nicht darum, ob die Systemzeit auf den relevanten Domänencontrollern mit der aktuellen Uhrzeit übereinstimmt. Es kümmert sich nur darum, dass der relative Zeitunterschied zwischen dem KDC und dem Zieldomänencontroller innerhalb der maximalen Zeitverschiebung liegt, die die Kerberos-Richtlinie zulässt. (Die Standardzeit beträgt fünf Minuten oder weniger.)

Im Kontext von Active Directory-Vorgängen ist der Zielserver der Quelldomänencontroller, der vom Zieldomänencontroller kontaktiert wird. Jeder Domänencontroller in einer Active Directory-Gesamtstruktur, die derzeit den KDC-Dienst ausführt, ist ein potenzieller KDC. Daher müssen Sie die Zeitgenauigkeit auf allen anderen Domänencontrollern für den Quelldomänencontroller berücksichtigen. Dies schließt die Zeit auf dem Zieldomänencontroller selbst ein.

Sie können die folgenden beiden Befehle verwenden, um die Zeitgenauigkeit zu überprüfen:

• DCDIAG /TEST:CheckSecurityError
• W32TM /MONITOR

Die Beispielausgabe DCDIAG /TEST:CheckSecurityError finden Sie im Abschnitt "Weitere Informationen". In diesem Beispiel wird eine übermäßige Zeitverknifung auf Domänencontrollern gezeigt.

Suchen Sie nach LSASRV 40960-Ereignissen auf dem Zieldomänencontroller, wenn die Replikationsanforderung fehlschlägt. Suchen Sie nach Ereignissen, die eine GUID im CNAME-Eintrag des Quelldomänencontrollers mit dem erweiterten Fehler 0xc000133 zitieren. Suchen Sie nach Ereignissen, die der folgenden ähneln:

0xc000133: Die Uhrzeit des primären Domänencontrollers unterscheidet sich von der Zeit auf dem Sicherungsdomänencontroller oder Mitgliedsserver mit zu großer Menge.

Netzwerkablaufverfolgungen, die den Zielcomputer erfassen, der eine Verbindung mit einem freigegebenen Ordner auf dem Quelldomänencontroller (und anderen Vorgängen) herstellt, kann den Fehler "Ein erweiterter Fehler ist aufgetreten" auf dem Bildschirm anzeigen, aber eine Netzwerkablaufverfolgung zeigt die folgenden Informationen an:

-> KerberosV5 KerberosV5:TGS Request Realm: <- TGS-Anforderung von Quell-DC
<- Kerberosvs Kerberosvs:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) <- TGS-Antwort, wobei "KRB_AP_ERR_TKE_NYV
<- Karten zu "Ticket noch nicht gültig" <- Karten zu "Ticket noch nicht gültig"

Die TKE_NYV Antwort gibt an, dass der Datumsbereich auf dem TGS-Ticket neuer als die Uhrzeit des Ziels ist. Dies zeigt eine übermäßige Zeitverknifung an.

Notiz

• W32TM /MONITOR überprüft die Zeit nur auf Domänencontrollern in der Domäne der Testcomputer, sodass Sie dies in jeder Domäne ausführen und die Zeit zwischen den Domänen vergleichen müssen.
• Wenn die Systemzeit als ungenau erkannt wurde, versuchen Sie herauszufinden, warum und was getan werden kann, um ungenaue Zeit in der Zukunft zu verhindern. Wurde der Gesamtstrukturstamm-PDC mit einer externen Zeitquelle konfiguriert? Sind Referenzzeitquellen online und im Netzwerk verfügbar? Wurde der Zeitdienst ausgeführt? Sind DC-Rollencomputer für die Verwendung der NT5DS-Hierarchie für die Quellzeit konfiguriert?
• Wenn der Zeitunterschied auf Zieldomänencontrollern zu groß ist, wird der Befehl "Jetzt replizieren" in DSSITE ausgeführt. MSC schlägt mit dem Fehler "Es gibt einen Zeit- und/oder Datumsunterschied zwischen dem Client und dem Server" auf dem Bildschirm fehl. Diese Fehlerzeichenfolge ordnet fehler 1398 (dezimal) oder 0x576 (hexadezimal) mit dem ERROR_TIME_SKEW symbolischen Fehlernamen zu.

Weitere Informationen finden Sie unter Festlegen der Toleranz für die Uhrsynchronisierung zum Verhindern von Replay-Angriffen.

Ursache 5: Die Einstellung "RestrictRemoteClients" in der Registrierung hat den Wert "2"

Wenn die Richtlinieneinstellung "Einschränkungen für nicht authentifizierte RPC-Clients" aktiviert und ohne Ausnahmen auf "Authentifiziert" festgelegt ist, wird der RestrictRemoteClients Registrierungswert auf einen Wert im 0x2 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC Registrierungsunterschlüssel festgelegt.

Diese Richtlinieneinstellung ermöglicht nur authentifizierten RPC-Clients (Remote Procedure Call), eine Verbindung mit RPC-Servern herzustellen, die auf dem Computer ausgeführt werden, auf den die Richtlinieneinstellung angewendet wird. Ausnahmen sind nicht zulässig. Wenn Sie diese Option auswählen, kann das System keine anonymen Remoteanrufe mithilfe von RPC empfangen. Diese Einstellung sollte niemals auf einen Domänencontroller angewendet werden.

Lösung

1. Deaktivieren Sie die Richtlinieneinstellung "Einschränkungen für nicht authentifizierte RPC-Clients ", die den RestrictRemoteClients Registrierungswert auf 2einschränkt.

   Notiz

   Die Richtlinieneinstellung befindet sich im folgenden Pfad:

   Computerkonfiguration\Administrative Vorlagen\System\Remoteprozeduraufruf\Einschränkungen für nicht authentifizierte RPC-Clients.

2. Löschen Sie die RestrictRemoteClients Registrierungseinstellung, und starten Sie sie dann neu.

Weitere Informationen finden Sie unter Einschränkungen für nicht authentifizierte RPC-Clients: Die Gruppenrichtlinie, die Ihre Domäne im Gesicht drückt und der Registrierungsschlüssel RestrictRemoteClients aktiviert ist.

Ursache 6: Dem Benutzerrecht "Zugriff auf diesen Computer aus dem Netzwerk" wird der Gruppe "Unternehmensdomänencontroller" oder einem Benutzer, der die Replikation ausgelöst hat, nicht gewährt.

Bei einer Standardinstallation von Windows ist die Standard-Domänencontrollerrichtlinie mit der Organisationseinheit (OU) des Domänencontrollers verknüpft. Die OU gewährt dem Netzwerkbenutzer zugriff auf diesen Computer rechte an die folgenden Sicherheitsgruppen:

Lokale Richtlinie	Standard-Domänencontrollerrichtlinie
Administratoren	Administratoren
Authentifizierte Benutzer	Authentifizierte Benutzer
Jeder	Jeder
Domänencontroller des Unternehmens	Domänencontroller des Unternehmens
[Pre-Windows 2000 compatible Access]	Pre-Windows 2000-kompatibler Access

Wenn Active Directory-Vorgänge mit Fehler 5 fehlschlagen, sollten Sie die folgenden Punkte überprüfen:

• Sicherheitsgruppen in der Tabelle werden dem Zugriff auf diesen Computer vom Netzwerkbenutzer direkt in der Richtlinie des Standarddomänencontrollers gewährt.

• Domänencontrollercomputerkonten befinden sich in der OU des Domänencontrollers.

• Die Richtlinie des Standarddomänencontrollers ist mit der OU des Domänencontrollers oder mit alternativen OUs verknüpft, die die Domänencontrollercomputerkonten hosten.

• Die Gruppenrichtlinie wird auf den Zieldomänencontroller angewendet, der derzeit Fehler 5 protokolliert.

• Der Zugriff auf diesen Computer über das Netzwerkbenutzerrecht ist aktiviert oder verweist nicht auf direkte oder transitive Gruppen, die vom Domänencontroller oder Benutzerkonto verwendet werden, um die Replikation auszulösen.

• Richtlinienrangfolge, blockierte Vererbung, WMI-Filterung (Microsoft Windows Management Instrumentation) oder ähnliches verhindert nicht, dass die Richtlinieneinstellung auf Domänencontrollerrollencomputer angewendet wird.

Notiz

• Richtlinieneinstellungen können mit RSOP überprüft werden. MSC, ist aber GPRESULT das bevorzugte Tool, da es genauer ist, z. B GPRESULT /H c:\temp\GPOResult.html . oder GPRESULT /Z.
• Lokale Richtlinie hat Vorrang vor Richtlinien, die in Websites, Domänen und OUs definiert sind.
• Es war üblich, dass Administratoren die Unternehmensdomänencontroller und alle Gruppen aus dem Zugriff auf diesen Computer aus der Netzwerkrichtlinieneinstellung in der Richtlinie des Standarddomänencontrollers entfernen. Das Entfernen beider Gruppen ist jedoch tödlich. Es gibt keinen Grund, Unternehmensdomänencontroller aus dieser Richtlinieneinstellung zu entfernen, da nur Domänencontroller Mitglieder dieser Gruppe sind.

Ursache 7: Es gibt eine SMB-Signaturkonflikt zwischen den Quell- und Ziel-DCs.

Die beste Kompatibilitätsmatrix für die SMB-Signatur wird durch vier Richtlinieneinstellungen und deren registrierungsbasierte Entsprechungen definiert:

Richtlinieneinstellung	Registrierungspfad
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
Microsoft-Netzwerkserver: Kommunikation digital signieren (wenn der Server zustimmt)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature

Sie sollten sich auf SMB-Signierungskonflikten zwischen ziel- und Quelldomänencontrollern konzentrieren. Bei den klassischen Fällen handelt es sich um eine Einstellung, die auf einer Seite aktiviert oder erforderlich ist, aber auf der anderen Seite deaktiviert ist.

Notiz

Interne Tests zeigten SMB-Signaturkonflikten, wodurch die Replikation mit Fehler 1722 fehlschlug: "Der RPC-Server ist nicht verfügbar.".

Ursache 8: UDP-formatierte Kerberos-Paketfragmentierung

Netzwerkrouter und -switches können große Udp-(User Datagram Protocol)-formatierte Netzwerkpakete fragmentieren oder vollständig ablegen, die von Kerberos- und Erweiterungsmechanismen für DNS (EDNS0) verwendet werden.

Lösung

1. Pingen Sie den Quelldomänencontroller über die Konsole des Zieldomänencontrollers anhand des vollqualifizierten Computernamens, um das größte Paket zu identifizieren, das von der Netzwerkroute unterstützt wird. Führen Sie zu diesem Zweck den folgenden Befehl aus:

   c:\>Ping <Source_DC_hostname>.<Fully_Qualified_Computer_Name> -f -l 1472
   

2. Wenn das größte nicht fragmentierte Paket kleiner als 1.472 Bytes ist, probieren Sie eine der folgenden Methoden aus (in der Reihenfolge der Voreinstellung):

   • Ändern Sie die Netzwerkinfrastruktur so, dass große UDP-Frames entsprechend unterstützt werden. Dies erfordert möglicherweise ein Firmwareupgrade oder eine Konfigurationsänderung auf Routern, Switches oder Firewalls.
   • Legen Sie "maxpacketsize" (auf dem Zieldomänencontroller) auf das größte Paket fest, das vom PING -f -l Befehl mit weniger 8 Bytes identifiziert wird, um den TCP-Header zu berücksichtigen, und starten Sie dann den geänderten Domänencontroller neu.
   • Legen Sie "maxpacketsize" (auf dem Zieldomänencontroller) auf einen Wert von 1. Dadurch wird die Kerberos-Authentifizierung für die Verwendung eines TCP ausgelöst. Starten Sie den geänderten Domänencontroller neu, damit die Änderung wirksam wird.

3. Wiederholen Sie den fehlgeschlagenen Active Directory-Vorgang.

Ursache 9: Netzwerkadapter haben das Feature "Großes Ausladen senden" aktiviert

Lösung

1. Öffnen Sie auf dem Zieldomänencontroller die Netzwerkadaptereigenschaften.
2. Wählen Sie die Schaltfläche Konfigurieren.
3. Wählen Sie die Registerkarte Erweitert.
4. Deaktivieren Sie die IPv4 Large Send Offload-Eigenschaft .
5. Starten Sie den Domänencontroller neu.

Ursache 10: Ungültiger Kerberos-Bereich

Der Kerberos-Bereich ist ungültig, wenn mindestens eine der folgenden Bedingungen zutrifft:

• Der KDCNames Registrierungseintrag enthält fälschlicherweise den lokalen Active Directory-Domänennamen.
• Der PolAcDmN Registrierungsschlüssel und der PolPrDmN Registrierungsschlüssel stimmen nicht überein.

Lösungen

Wichtig

Dieser Abschnitt, diese Methode bzw. diese Aufgabe enthält eine Beschreibung der Schritte zum Bearbeiten der Registrierung. Durch die falsche Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Daher müssen Sie sicherstellen, dass Sie diese Schritte sorgfältig ausführen. Erstellen Sie eine Sicherungskopie der Registrierung, bevor Sie Änderungen vornehmen, damit Sie die Registrierung wiederherstellen können, falls ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter: Sichern und Wiederherstellen der Registrierung Windows.

Lösung für den falschen Registrierungseintrag "KDCNames"

1. Führen Sie auf dem Zieldomänencontroller aus REGEDIT.
2. Suchen Sie den folgenden Unterschlüssel in der Registrierung: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains
3. Vergewissern Sie sich für jede <Fully_Qualified_Domain> unter dem Unterschlüssel, dass sich der Wert des KdcNames Registrierungseintrags auf einen gültigen externen Kerberos-Bereich und nicht auf die lokale Domäne oder eine andere Domäne in derselben Active Directory-Gesamtstruktur bezieht.

Lösung für die nicht übereinstimmenden Registrierungsschlüssel "PolAcDmN" und "PolPrDmN"

1. Starten Sie den Registrierungs-Editor.

2. Erweitern Sie im Navigationsbereich " Sicherheit".

3. Wählen Sie im Menü "Sicherheit " die Option "Berechtigungen" aus, um den Administratoren die vollständige Kontrolle über die SECURITY Struktur und die untergeordneten Container und Objekte zu gewähren.

4. Suchen Sie den folgenden Unterschlüssel in der Registrierung:
   HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN

5. Wählen Sie im rechten Bereich des Registrierungs-Editors den Eintrag "Nein" aus: REG_NONE Registrierungseintrag einmal.

6. Wählen Sie im Menü "Ansicht " die Option "Binärdaten anzeigen" aus.

7. Wählen Sie im Abschnitt "Format" des Dialogfelds "Byte" aus.

   Der Domänenname wird als Zeichenfolge auf der rechten Seite des Dialogfelds "Binärdaten " angezeigt. Der Domänenname entspricht dem Kerberos-Bereich.

8. Suchen Sie den folgenden Unterschlüssel in der Registrierung:
   HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN

9. Doppelklicken Sie im rechten Bereich des Registrierungs-Editors auf den Eintrag "Kein Name": REG_NONE Eintrag.

10. Fügen Sie im Dialogfeld "Binär-Editor " den Wert aus dem PolPrDmN Registrierungsunterschlüssel ein. (Der Wert aus dem PolPrDmN Registrierungsunterschlüssel ist der NetBIOS-Domänenname).

11. Starten Sie den Domänencontroller neu. Wenn der Domänencontroller nicht ordnungsgemäß funktioniert, finden Sie weitere Methoden.

Ursache 11: Es besteht ein LAN-Manager-Kompatibilitätskonflikt (LM-Kompatibilität) zwischen Quell- und Ziel-DCs.

Ursache 12: Dienstprinzipalnamen sind entweder aufgrund einer einfachen Replikationslatenz oder eines Replikationsfehlers nicht registriert oder nicht vorhanden.

Ursache 13: Antivirensoftware verwendet einen Netzwerkadapter-Filtertreiber für die Minifirewall auf der Quelle oder dem Ziel-DC

Weitere Informationen

Active Directory-Fehler und -Ereignisse wie die im Abschnitt "Symptome" beschriebenen Fehler können auch mit Fehler 8453 zusammen mit der Fehlerzeichenfolge auftreten, die der folgenden ähnelt:

Replikationszugriff wurde verweigert.

Die folgenden Situationen können dazu führen, dass Active Directory-Vorgänge mit Fehler 8453 fehlschlagen. Diese Situationen verursachen jedoch keine Fehler mit Fehler 5.

• Der Namenskontextkopf (NC) ist mit der Berechtigung "Verzeichnisänderungen replizieren" nicht zulässig.
• Die Sicherheitsprinzipal-Startreplikation ist kein Mitglied einer Gruppe, der die Berechtigung "Verzeichnisänderungen replizieren" gewährt wird.
• Flags fehlen im UserAccountControl Attribut. Diese Kennzeichnungen enthalten SERVER_TRUST_ACCOUNT und TRUSTED_FOR_DELEGATION.
• Der schreibgeschützte Domänencontroller (RODC) ist der Domäne beigetreten, ohne zuerst den ADPREP /RODCPREP Befehl auszuführen.

Beispielausgabe von "DCDIAG /TEST:CheckSecurityError"

Die Beispielausgabe DCDIAG /CHECKSECURITYERROR für einen Domänencontroller lautet wie folgt. Dies wird durch übermäßige Zeitverknifung verursacht.

Doing primary tests  
Testing server: <Site_Name>\<Destination_DC_Name>  
Starting test: CheckSecurityError  
Source DC <Source DC> has possible security error (5). Diagnosing...  
Time skew error between client and 1 DCs! ERROR_ACCESS_DENIED or down machine recieved by:
<Source DC>  
Source DC <Source DC>_has possible security error (5). Diagnosing...  
Time skew error: 7205 seconds different between:.  
<Source DC>  
<Destination_DC>  
[<Source DC>] DsBindWithSpnEx() failed with error 5,  
Access is denied..  
Ignoring DC <Source DC> in the convergence test of object CN=<Destination_DC>,OU=Domain  Controllers,DC=<DomainName>,DC=com, because we cannot connect!  
......................... <Destination_DC> failed test CheckSecurityError  

Beispielausgabe ist DCDIAG /CHECKSECURITYERROR wie folgt. Es werden die fehlenden SPN-Namen angezeigt. (Die Ausgabe kann von Umgebung zu Umgebung variieren.)

Doing primary tests  
Testing server: <site name>\<dc name>  
Test omitted by user request: Advertising  
Starting test: CheckSecurityError  
* Dr Auth: Beginning security errors check'  
Found KDC <KDC DC> for domain <DNS Name of AD domain> in site <site name>  
Checking machine account for DC <DC name> on DC <DC Name>  
* Missing SPN :LDAP/<hostname>.<DNS domain name>/<DNS domain name>  
* Missing SPN :LDAP/<hostname>.<DNS domain name>  
* Missing SPN :LDAP/<hostname>  
* Missing SPN :LDAP/<hostname>.<DNS domain name>/<NetBIOS domain name>  
* Missing SPN :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<forest root domain DN>  
* SPN found :E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest root domain DNS name>  
* Missing SPN :HOST/<hostname>.<DNS domain name>/<DNS domain name>  
* SPN found :HOST/<hostname>.<DNS domain name>  
* SPN found :HOST/<hostname>  
* Missing SPN :HOST/<hostname>.<DNS domain name>/<NetBIOS domain name>  
* Missing SPN :GC/<hostname>.<DNS domain name>/<DNS domain name>
Unable to verify the machine account (<DN path for Dc machine account>) for <DC Name> on <DC name>.

Datensammlung

Wenn Sie Unterstützung vom Microsoft-Support benötigen, empfehlen wir, die Informationen zu sammeln, indem Sie die unter " Sammeln von Informationen" genannten Schritte ausführen, indem Sie TSS für Active Directory-Replikationsprobleme verwenden.