Behandeln von Active Directory-Replikationsfehler 5 in Windows Server: Zugriff verweigert

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

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

Symptome

Möglicherweise tritt eines oder mehrere der folgenden Symptome auf, wenn Active Directory-Replikationen mit Fehler 5 fehlschlagen.

Symptom 1

Das Dcdiag.exe-Befehlszeilentool meldet, dass der Active Directory-Replikationstest mit dem Fehler status Code (5) fehlschlägt. Der Bericht sieht wie folgt aus:

Testserver: Site_Name\Destination_DC_Name
Test wird gestartet: Replikationen
*Replikationsüberprüfung
[Replikationsprüfung,Destination_DC_Name] Fehler bei einem kürzlich durchgeführten Replikationsversuch:
Von Source_DC bis Destination_DC
Namenskontext: Directory_Partition_DN_Path
Bei der Replikation wurde ein Fehler (5) generiert:
Der Zugriff wurde verweigert.
Der Fehler ist zum Zeitpunkt des Datumsaufgetreten.
Der letzte Erfolg ist zum Zeitpunkt des Datumsaufgetreten.
Anzahl von Fehlern seit dem letzten Erfolg.

Symptom 2

Das Dcdiag.exe-Befehlszeilentool meldet, dass die DsBindWithSpnEx-Funktion mit Fehler 5 fehlschlägt, indem der DCDIAG /test:CHECKSECURITYERROR Befehl ausgeführt wird.

Symptom 3

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

Die REPADMIN-Befehle, die häufig die fünf status zitieren, umfassen, sind jedoch nicht auf Folgendes beschränkt:

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

Es folgt eine Beispielausgabe des REPADMIN /SHOWREPL Befehls. Diese Ausgabe zeigt die eingehende Replikation von DC_2_Name zu DC_1_Name mit dem Fehler "Zugriff verweigert" fehlschlägt.

\ Site_NameDC_1_Name
DSA-Optionen: IS_GC
Websiteoptionen: (keine)
DSA-Objekt-GUID: GUID
DSA invocationID: invocationID

=== EINGEHENDE NACHBARN======================================
DC= DomainName,DC=com
\ Site_NameDC_2_Name über RPC
DSA-Objekt-GUID: GUID
Letzter Versuch @ Datum/Uhrzeit fehlgeschlagen, Ergebnis 5(0x5):
Der Zugriff wurde verweigert.
<Anzahl> aufeinander folgender Fehler.
Letzter Erfolg @ DatumUhrzeit.

Symptom 4

NTDS KCC-, NTDS General- oder Microsoft-Windows-ActiveDirectory_DomainService-Ereignisse mit den fünf status werden im Verzeichnisdienste-Protokoll in Ereignisanzeige protokolliert.

In der folgenden Tabelle sind Active Directory-Ereignisse zusammengefasst, die häufig die 8524-status zitieren.

Symptom 5

Wenn Sie auf einem Quelldomänencontroller in Active Directory-Standorte und -Dienste mit der rechten Maustaste auf das Verbindungsobjekt klicken und dann Jetzt replizieren auswählen, schlägt der Prozess fehl, und Sie erhalten die folgende Fehlermeldung:

Jetzt replizieren

Der folgende Fehler ist beim Versuch aufgetreten, den Namenskontext %Verzeichnispartitionsname% vom Domänencontrollerquell-Domänencontroller mit dem Domänencontroller-Zieldomänencontroller zu synchronisieren: Der Zugriff wurde verweigert.

Der Vorgang wird nicht fortgesetzt.

Der folgende Screenshot zeigt ein Beispiel für den Fehler:

Problemumgehung

Verwenden Sie das generische DCDIAG-Befehlszeilentool, um mehrere Tests auszuführen. Verwenden Sie das Befehlszeilentool DCDIAG /TEST:CheckSecurityErrors, um bestimmte Tests durchzuführen. (Diese Tests umfassen eine SPN-Registrierungsüberprüfung.) Führen Sie die Tests aus, um Probleme bei der Replikation von Active Directory-Vorgängen mit Den Fehlern 5 und 8453 zu beheben. Beachten Sie jedoch, dass dieses Tool nicht als Teil der Standardausführung von DCDIAG ausgeführt wird.

Gehen Sie folgendermaßen vor, um dieses Problem zu umgehen:

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

Ursachen und Lösungen

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

Ursache 1: 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 Registrierungswert RestrictRemoteClients auf den Wert 0x2 im 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 dem die Richtlinieneinstellung angewendet wird. Ausnahmen sind nicht zulässig. Wenn Sie diese Option auswählen, kann ein System keine anonymen Remoteanrufe über 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 Registrierungswert RestrictRemoteClients auf 2 beschränkt.

   Hinweis

   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 Registrierungseinstellung RestrictRemoteClients, und starten Sie dann neu.

Weitere Informationen finden Sie unter Einschränkungen für nicht authentifizierte RPC-Clients: Die Gruppenrichtlinie, die Ihre Domäne ins Gesicht schlägt.

Ursache 2: Die Einstellung CrashOnAuditFail in der Registrierung des Zieldomänencontrollers hat den Wert 2.

Der CrashOnAduitFail-Wert 2 wird ausgelöst, wenn die Richtlinieneinstellung Überwachung: System herunterfahren sofort aktiviert ist, wenn die Richtlinieneinstellung Für Sicherheitsüberwachungen in Gruppenrichtlinie nicht protokolliert werden kann 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 Optionen Ereignisse nicht überschreiben (protokoll manuell löschen) und Überschreiben nach Bedarf in Ereignisanzeige oder deren Gruppenrichtlinie Entsprechungen eingeschränkt wird.

Lösung

Ursache 3: Ungültige Vertrauensstellung

Wenn bei der Active Directory-Replikation zwischen Domänencontrollern in verschiedenen Domänen ein Fehler auftritt, sollten Sie die Integrität der Vertrauensstellungen entlang des Vertrauenspfads überprüfen.

Sie können den NetDiag-Vertrauensstellungstest testen, um nach fehlerhaften Vertrauensstellungen zu suchen. Das Hilfsprogramm Netdiag.exe identifiziert fehlerhafte Vertrauensstellungen, indem der folgende Text angezeigt wird:

Vertrauensstellungstest. . . . . . : Fehlgeschlagen
Testen Sie, ob DomainSid der Domäne "Domänenname" richtig ist.
[FATAL] Der sichere Kanal zur Domäne "Domänenname" ist unterbrochen.
[% 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 (B.Contoso.COM), eine Großkinddomäne (C.B.Contoso.COM) und eine Strukturdomäne in derselben Gesamtstruktur (Fabrikam.COM) enthält, und wenn die Replikation zwischen Domänencontrollern in der Großkinddomäne (C.B.Contoso.COM) und der Strukturdomäne (Fabrikam.COM)) fehlschlägt, sollten Sie die Vertrauensstellung zwischen C.B.Contoso.COM und B.Contoso.COMüberprüfen, zwischen B.Contoso.COM und Contoso.COMund schließlich zwischen Contoso.COM und Fabrikam.COM.

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

Führen Sie den folgenden Befehl aus, um aktuelle Kennwortänderungen an der Vertrauensstellung zu überprüfen:

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

Stellen Sie sicher, dass der Zieldomänencontroller transitiv eingehender Datenverkehr die beschreibbare Domänenverzeichnispartition repliziert, bei der Änderungen des Vertrauenskennworts wirksam werden können.

Befehle zum Zurücksetzen von Vertrauensstellungen aus dem PDC der Stammdomäne 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 dem PDC der untergeordneten Domäne lauten wie folgt:

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

Ursache 4: Übermäßige Zeitschiefe

Die 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 Wiederholungsangriffe zu verhindern. In einigen Dokumentationen wird angegeben, dass die Systemzeit des Clients und die des Kerberos-Ziels innerhalb von fünf Minuten betragen müssen. Eine andere Dokumentation besagt, dass im Kontext der Kerberos-Authentifizierung die Zeit, die wichtig ist, das Delta zwischen dem vom Aufrufer verwendeten KDC und der Zeit auf dem Kerberos-Ziel ist. Außerdem ist Es bei Kerberos egal, ob die Systemzeit auf den relevanten Domänencontrollern mit der aktuellen Zeit übereinstimmt. Es ist nur wichtig, dass der relative Zeitunterschied zwischen dem KDC und dem Zieldomänencontroller innerhalb der maximalen Zeitabweichung liegt, die die Kerberos-Richtlinie zulässt. (Die Standardzeit beträgt maximal fünf Minuten.)

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, auf dem derzeit der KDC-Dienst ausgeführt wird, ist ein potenzieller KDC. Daher müssen Sie die Zeitgenauigkeit auf allen anderen Domänencontrollern gegenüber dem 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 von DCDIAG /TEST:CheckSecurityError finden Sie im Abschnitt "Weitere Informationen". Dieses Beispiel zeigt eine übermäßige Zeitabweichung auf Windows Server 2003- und Windows Server 2008 R2-basierten Domänencontrollern.

Suchen Sie zum Zeitpunkt der fehlerhaften Replikationsanforderung nach LSASRV 40960-Ereignissen auf dem Zieldomänencontroller. Suchen Sie nach Ereignissen, die eine GUID im CNAME-Eintrag des Quelldomänencontrollers mit erweitertem Fehler 0xc000133. Suchen Sie nach Ereignissen, die den folgenden ähneln:

Die Zeit auf dem primären Domänencontroller unterscheidet sich von der Zeit auf dem Sicherungsdomänencontroller oder Mitgliedsserver um einen zu großen Betrag.

Netzwerkablaufverfolgungen, die den Zielcomputer erfassen, der eine Verbindung mit einem freigegebenen Ordner auf dem Quelldomänencontroller herstellt (und auch andere Vorgänge), zeigen möglicherweise den Fehler "Ein erweiterter Fehler ist aufgetreten" auf dem Bildschirm an, aber eine Netzwerkablaufverfolgung zeigt Folgendes an:

–> KerberosV5 KerberosV5:TGS-Anforderungsbereich: <– TGS-Anforderung vom Quelldomänencontroller
<– Kerberosvs Kerberosvs:KRB_ERROR – KRB_AP_ERR_TKE_NVV (33) <– TGS-Antwort, bei der "KRB_AP_ERR_TKE_NYV
<- wird "Ticket noch nicht gültig" <zugeordnet: "Ticket noch nicht gültig"

Die TKE_NYV Antwort gibt an, dass der Datumsbereich auf dem TGS-Ticket neuer ist als die Zeit auf dem Ziel. Dies deutet auf eine übermäßige Zeitschiefe hin.

Weitere Informationen finden Sie unter Festlegen der Zeitsynchronisierungstoleranz zum Verhindern von Replay-Angriffen.

Ursache 5: Es liegt ein ungültiger Sicherheitskanal oder Kennwortkonflikt auf dem Quell- oder Zieldomänencontroller vor.

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

• nltest /sc:query
• netdom verify

Setzen Sie unter der Bedingung das Kennwort des Zieldomänencontrollers mithilfe von NETDOM /RESETPWD zurück.

Lösung

1. Deaktivieren Sie den Kerberos-KDC-Dienst (Key Distribution Center) auf dem Domänencontroller, der neu gestartet wird.

2. Führen Sie NETDOM RESETPWD in der Konsole des Zieldomänencontrollers wie folgt aus, um das Kennwort für den Zieldomänencontroller zurückzusetzen:

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

3. Stellen Sie sicher, dass wahrscheinliche KDCs und der Quelldomänencontroller (sofern diese sich in derselben Domäne befinden) eingehende Informationen über das neue Kennwort des Zieldomänencontrollers replizieren.

4. Starten Sie den Zieldomänencontroller neu, um Kerberos-Tickets zu aktualisieren, und wiederholen Sie den Replikationsvorgang.

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

Ursache 6: Das Benutzerrecht "Auf diesen Computer über das Netzwerk zugreifen" wird einem Benutzer, der die Replikation auslöst, nicht gewährt.

In einer Standardinstallation von Windows ist die Standarddomänencontrollerrichtlinie mit der organization Unit (OU) des Domänencontrollers verknüpft. Die Organisationseinheit gewährt den folgenden Sicherheitsgruppen die Berechtigung Auf diesen Computer über Netzwerkbenutzer zugreifen:

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

• Sicherheitsgruppen in der Tabelle wird in der Standardrichtlinie des Domänencontrollers die Berechtigung Zugriff auf diesen Computer vom Netzwerkbenutzer gewährt.
• Domänencontrollercomputerkonten befinden sich in der Organisationseinheit des Domänencontrollers.
• Die Standarddomänencontrollerrichtlinie ist mit der Organisationseinheit des Domänencontrollers oder mit alternativen Organisationseinheiten verknüpft, die Computerkonten hosten.
• Gruppenrichtlinie wird auf den Zieldomänencontroller angewendet, der derzeit Fehler 5 protokolliert.
• Das Recht Zugriff auf diesen Computer über Netzwerkbenutzer verweigern ist aktiviert oder verweist nicht auf direkte oder transitive Gruppen, deren Sicherheitskontext vom Domänencontroller oder Benutzerkonto verwendet wird, der die Replikation auslöst.
• Richtlinienrangfolge, blockierte Vererbung, WMI-Filterung (Microsoft Windows Management Instrumentation) oder ähnliches verhindern nicht, dass die Richtlinieneinstellung auf Computer mit Domänencontrollerrolle angewendet wird.

Ursache 7: Es besteht ein SMB-Signaturkonflikt zwischen den Quell- und Zieldomänencontrollern.

Sie sollten sich auf SMB-Signaturkonflikte zwischen ziel- und Quelldomänencontrollern konzentrieren. Die klassischen Fälle umfassen eine Einstellung, die auf der einen Seite aktiviert oder erforderlich ist, auf der anderen Seite deaktiviert ist.

Ursache 8: UDP-formatierte Kerberos-Paketfragmentierung

Netzwerkrouter und Switches können große UDP-formatierte Netzwerkpakete fragmentieren oder vollständig löschen, die von Kerberos und Erweiterungsmechanismen für DNS (EDNS0) verwendet werden. Computer mit Windows 2000 Server- oder Windows Server 2003-Betriebssystemfamilien sind besonders anfällig für UDP-Fragmentierung auf Computern, auf denen Windows Server 2008 oder Windows Server 2008 R2 ausgeführt wird.

Lösung

1. Pingen Sie in der Konsole des Zieldomänencontrollers den Quelldomänencontroller anhand seines vollqualifizierten Computernamens, um das größte Paket zu identifizieren, das von der Netzwerkroute unterstützt wird. Führen Sie dazu 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 Byte ist, probieren Sie eine der folgenden Methoden (in der bevorzugten Reihenfolge) aus:

   • Ändern Sie die Netzwerkinfrastruktur, um große UDP-Frames entsprechend zu unterstützen. Dies kann ein Firmwareupgrade oder eine Konfigurationsänderung auf Routern, Switches oder Firewalls erfordern.
   • Legen Sie maxpacketsize (auf dem Zieldomänencontroller) auf das größte Paket fest, das durch den Befehl PING -f -l identifiziert wird, weniger als 8 Bytes, 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 den Wert 1 fest. Dadurch wird die Kerberos-Authentifizierung für die Verwendung von 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: Bei Netzwerkadaptern ist das Feature "Große Sendeauslagerung" aktiviert.

Lösung

1. Öffnen Sie auf dem Zieldomänencontroller die Eigenschaften des Netzwerkadapters.
2. Klicken Sie auf die Schaltfläche Konfigurieren .
3. Wählen Sie die Registerkarte Erweitert aus.
4. Deaktivieren Sie die Eigenschaft "IPv4 Large Send Offload ".
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 Registrierungseintrag KDCNames enthält fälschlicherweise den lokalen Active Directory-Domänennamen.
• Der PolAcDmN-Registrierungsschlüssel und der PolPrDmN-Registrierungsschlüssel stimmen nicht überein.

Lösungen

Lösung für den falschen KDCNames-Registrierungseintrag

1. Führen Sie auf dem Zieldomänencontroller REGEDIT aus.

2. Suchen Sie den folgenden Unterschlüssel in der Registrierung: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains

3. Überprüfen Sie für jede <Fully_Qualified_Domain> unter dem Unterschlüssel, ob der Wert für den Registrierungseintrag KdcNames auf einen gültigen externen Kerberos-Bereich verweist und nicht auf die lokale Domäne oder eine andere Domäne in derselben Active Directory-Gesamtstruktur.

Lösung für nicht übereinstimmende PolAcDmN- und PolPrDmN-Registrierungsschlüssel

1. Starten Sie den Registrierungs-Editor.

2. Erweitern Sie im Navigationsbereich die Option Sicherheit.

3. Klicken Sie im Menü Sicherheit auf Berechtigungen , um der lokalen Gruppe Administratoren vollständige Kontrolle über die SECURITY-Struktur und die zugehörigen untergeordneten Container und Objekte zu gewähren.

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

5. Klicken Sie im rechten Bereich der Registrierungs-Editor einmal auf den Registrierungseintrag Kein Name: REG_NONE Registrierungseintrag.

6. Klicken Sie im Menü Ansicht auf Binärdaten anzeigen.

7. Klicken Sie im Abschnitt Format des Dialogfelds auf Byte.

   Der Domänenname wird als Zeichenfolge auf der rechten Seite des Dialogfelds Binäre Daten 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 der Registrierungs-Editor auf den Eintrag No Name: REG_NONE.

10. Fügen Sie im Dialogfeld Binary Editor den Wert aus dem Registrierungsunterschlüssel PolPrDmN 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, lesen Sie andere Methoden.

Ursache 11: Es besteht ein Konflikt zwischen den Quell- und Zieldomänencontrollern mit der LAN-Manager-Kompatibilität (LM-Kompatibilität).

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

Ursache 13: Antivirensoftware verwendet einen Mini-Firewall-Netzwerkadapter-Filtertreiber auf dem Quell- oder Zieldomänencontroller

Status

Microsoft hat bestätigt, dass es sich hierbei um ein Problem bei den in diesem Artikel genannten Microsoft-Produkten handelt.

Weitere Informationen

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

Der Replikationszugriff wurde verweigert.

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

• Der Namenskontextkopf (NC) ist mit der Berechtigung Replizieren von Verzeichnisänderungen nicht zulässig.
• Der Sicherheitsprinzipal, der die Replikation startet, ist kein Mitglied einer Gruppe, der die Berechtigung Replizieren von Verzeichnisänderungen gewährt wird.
• Flags fehlen im UserAccountControl-Attribut. Dazu gehören das SERVER_TRUST_ACCOUNT-Flag und das TRUSTED_FOR_DELEGATION-Flag.
• Der schreibgeschützte Domänencontroller (RODC) ist in die Domäne eingebunden, ohne dass zuerst der ADPREP /RODCPREP Befehl ausgeführt wird.

Beispielausgabe von DCDIAG /TEST:CheckSecurityError

Es folgt eine DCDIAG /test:CHECKSECURITYERROR-Beispielausgabe von einem Windows Server 2008 R2-Domänencontroller. Diese Ausgabe wird durch übermäßige Zeitschiefe verursacht.

Ausführen primärer Tests Testserver: <Site_Name>\<Destination_DC_Name> Wird gestartet: CheckSecurityError
Der Quell-DC-Quelldomänencontroller <> weist einen möglichen Sicherheitsfehler auf (1398).
Diagnose...
Zeitschiefe zwischen Client und 1 DCs! ERROR_ACCESS_DENIED
oder heruntergefahrener Computer empfangen von:
<Fehler beim Quell-DC> [<Quell-DC>] DsBindWithSpnEx() mit Fehler 1398.
Es gibt eine Zeit- und/oder Datumsdifferenz zwischen Client und Server.
Ignorieren des DC-Quell-DC <> im Konvergenztest des Objekts
CN=<Destination_DC,OU>=Domänencontroller,DC=<DomainName,DC>=com, weil wir
Kann nicht verbunden werden!
<.........................> Destination_DC fehlgeschlagener CheckSecurityError-Test

Es folgt eine DCDIAG /CHECKSECURITYERROR-Beispielausgabe eines Windows Server 2003-basierten Domänencontrollers. Dies wird durch übermäßige Zeitschiefe verursacht.

Durchführen primärer Tests
Testserver: <Site_Name>\<Destination_DC_Name>
Test wird gestartet: CheckSecurityError
Der Quell-DC-Quelldomänencontroller <>weist einen möglichen Sicherheitsfehler auf (5). Diagnose...
Zeitschiefe zwischen Client und 1 DCs! ERROR_ACCESS_DENIED oder ausgefallener Computer empfangen von: <Quell-DC>
Quell-DC-Quell-DC<>_has möglicher Sicherheitsfehler (5). Diagnose...
Zeitschiefefehler: 7205 Sekunden unterscheiden sich zwischen:.
<Quell-DC>
<Destination_DC>
[<Quell-DC>] Fehler bei DsBindWithSpnEx() mit Fehler 5,
Der Zugriff wird verweigert.
Ignorieren des DC-Quell-DC <>im Konvergenztest des Objekts CN=<Destination_DC,OU>=Domänencontroller,DC=<DomainName,DC>=com, da keine Verbindung hergestellt werden kann!
<.........................>Destination_DC fehlgeschlagener CheckSecurityError-Test

Es folgt eine DCDIAG /CHECKSECURITYERROR-Beispielausgabe. Fehlende SPN-Namen werden angezeigt. (Die Ausgabe kann von Umgebung zu Umgebung variieren.)

Durchführen primärer Tests
Testserver: <Standortname>\<DC-Name>
Test wird von Benutzeranforderung ausgelassen: Werbung
Test wird gestartet: CheckSecurityError
* Dr Auth: Beginnt bei der Überprüfung von Sicherheitsfehlern"
KDC KDC DC> für Domänen-DNS-Name <der AD-Domäne> im Standortnamen <gefunden <>
Überprüfen des Computerkontos auf DC-Dc-Name <> auf DC-Name <>
* Fehlender SPN :LDAP/<hostname>.<DNS-Domänenname>/<DNS-Domänenname>
* Fehlender SPN :LDAP/<hostname>.<DNS-Domänenname>
* Fehlender SPN :LDAP/<hostname>
* Fehlender SPN :LDAP/<hostname>.<DNS-Domänenname>/<NetBIOS-Domänenname>
* Fehlender SPN :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<DN der Stammdomäne der Gesamtstruktur>
* SPN gefunden:E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest root domain DNS name>
* Fehlender SPN :HOST/<hostname>.<DNS-Domänenname>/<DNS-Domänenname>
* SPN gefunden:HOST/<hostname>.<DNS-Domänenname>
* SPN gefunden:HOST/<hostname>
* Fehlender SPN :HOST/<hostname>.<DNS-Domänenname>/<NetBIOS-Domänenname>
* Fehlender SPN :GC/<hostname>.<DNS-Domänenname>/<DNS-Domänenname> Das Computerkonto (<DN-Pfad für dc-Computerkonto>) für <DC-Name> auf dc <name> kann nicht überprüft werden.

Datensammlung

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