Welche Active-Directory-Fehlercodes bedeuten was? LDAP-, Kerberos-, Replikations- und Vertrauensstellungsfehler korrekt einordnen

Fehlerquellen und Abhängigkeiten von AD DS: DNS, Zeitdienst, Netzwerk, PKI, Replikation und Namensauflösung

Active Directory Domain Services arbeitet nicht als „ein Dienst“, der isoliert korrekt oder fehlerhaft ist. AD DS ist ein Verbund aus LDAP-Verzeichnis, Kerberos-Key-Distribution, Replikations-Engine, RPC/SMB-Transporten, DNS-Service-Location sowie (je nach Einsatz) Zertifikats- und Smartcard-Ökosystem. Viele Störungen erscheinen zunächst als AD-Fehler, entstehen aber in Abhängigkeiten: Namensauflösung, Zeitbasis, Netzwerkpfade, Zertifikatsvertrauen und Replikationskonsistenz entscheiden direkt darüber, ob Anmeldungen, Gruppenrichtlinien und dienstübergreifende Systeme zuverlässig funktionieren.

Diese Abhängigkeiten erzeugen typische Fehlermuster: Ein DNS-Problem führt zu „DC nicht gefunden“, das sich als Kerberos-Fehler oder LDAP-Bind-Fehler manifestiert. Zeitabweichungen wirken wie falsche Kennwörter. Replikationslücken verursachen scheinbar „fehlende“ Benutzer, Gruppen oder GPOs. PKI-Fehler werden als Authentifizierungs- oder Kanalbindungsprobleme sichtbar. Eine strukturierte Einordnung beginnt daher immer mit den fundamentalen Bausteinen.

DNS als Locator und Namensautorität: SRV-Records, Sites und DC-Findung

AD DS nutzt DNS nicht nur zur Namensauflösung, sondern als Verzeichnis „für das Verzeichnis“. Clients und Server lokalisieren Domänencontroller über SRV-Records (z. B. _ldap._tcp.dc._msdcs.<Domäne>), ermitteln Standortnähe über Sites/Subnetze und leiten daraus die Auswahl von Logon-Servern und Replikationspartnern ab. Fehlende oder veraltete SRV-Records, falsche Client-DNS-Server oder inkonsistente Delegationen führen zu DC-Discovery-Fehlern, die anschließend Kerberos, LDAP und Gruppenrichtlinien gleichzeitig betreffen.

Typische Kaskaden: Wenn ein Client einen DC per DNS nicht korrekt findet, folgt oft The specified domain either does not exist or could not be contacted bzw. ERROR_NO_SUCH_DOMAIN (1355). In der Ereignisanzeige treten parallel Netlogon-/DNS-Registrierungsprobleme auf, etwa Event ID 5781 (dynamische DNS-Registrierung fehlgeschlagen). Auch Event ID 5719 (Netlogon: kein DC verfügbar) ist häufig eine Folge von DNS- oder Netzwerkpfadfehlern, nicht primär von „AD defekt“.

• DNS-Client prüfen: ipconfig /all
Get-DnsClientServerAddress
• SRV-/A-Records verifizieren: nslookup -type=SRV _ldap._tcp.dc._msdcs.<Domäne>
nslookup <dcname>.<Domäne>
• DC-Discovery testen: nltest /dsgetdc:<Domäne>
nltest /dclist:<Domäne>
• DNS-Registrierung durch Netlogon erzwingen: ipconfig /registerdns
net stop netlogon && net start netlogon

Zeitdienst (W32Time) als Kerberos-Voraussetzung: Drift, NTP und sichere Zeitquellen

Kerberos akzeptiert Tickets nur innerhalb enger Zeitfenster. Schon moderate Zeitdrifts zwischen Client und DC führen zu Authentifizierungsfehlern, die wie Kennwort- oder Vertrauensprobleme wirken. Der klassische Status ist KRB_AP_ERR_SKEW bzw. in Windows-Fehlermeldungen The time difference between the client and server is too great. In Domänen topologisiert sich die Zeit automatisch: Mitglieder synchronisieren von DCs, DCs vom PDC-Emulator, der idealerweise eine stabile externe Quelle nutzt. Bricht diese Kette, fällt Kerberos aus; NTLM kann in Teilbereichen scheinbar „noch funktionieren“, was die Diagnose erschwert.

W32Time-Probleme zeigen sich häufig in Event ID 36 (Zeitdienst kann nicht synchronisieren) oder Event ID 47 (Zeitquelle unzuverlässig). In virtualisierten Umgebungen entstehen Abweichungen zusätzlich durch Host-Zeit, Snapshot-Restore oder fehlerhafte Zeitsynchronisationseinstellungen. Zeitfehler wirken sich unmittelbar auf Anmeldung, LDAP-Signing/Sealing-Workflows mit Kerberos, GPO-Verarbeitung sowie Zertifikatsvalidierung (Gültigkeitszeiträume) aus.

• Aktuellen Status prüfen: w32tm /query /status
w32tm /query /source
• Domänenhierarchie und Offset prüfen: w32tm /monitor
w32tm /stripchart /computer:<PDC> /dataonly /samples:5
• W32Time-Konfiguration anzeigen: w32tm /query /configuration

Netzwerkpfade, Ports und MTU: wenn „AD nicht erreichbar“ eigentlich Transport ist

AD DS benötigt mehrere Transportprotokolle: LDAP/LDAPS, Kerberos, RPC Endpoint Mapper und dynamische RPC-Ports, SMB für SYSVOL/NETLOGON, sowie DNS. Störungen sind selten „alles oder nichts“. Ein DC kann pingbar sein, während RPC oder SMB blockiert ist. Dann scheitert GPO-Verarbeitung (SYSVOL-Zugriff), Replikation (RPC) oder der sichere Kanal (Netlogon) selektiv. Häufige Indikatoren sind The RPC server is unavailable (1722), There are currently no logon servers available (1311) oder in Replikationsdiagnosen DsReplicaGetInfo() failed with status 1722.

MTU-/Fragmentierungsprobleme sowie asymmetrisches Routing können Kerberos/LDAP-Traffic punktuell beschädigen. Auch TLS-Inspection oder falsch konfigurierte Firewalls stören LDAPS und certificate-based Authentifizierung, ohne dass klassische „Port zu“-Meldungen entstehen. Eine saubere Port- und Pfadanalyse muss deshalb sowohl IP-Konnektivität als auch Applikationshandshakes prüfen.

• Erreichbarkeit auf Dienstebene testen: Test-NetConnection -ComputerName <DC> -Port 389
Test-NetConnection -ComputerName <DC> -Port 445
Test-NetConnection -ComputerName <DC> -Port 135
• Domänenkanal und DC-Locator differenzieren: nltest /sc_verify:<Domäne>
nltest /dsgetdc:<Domäne>

PKI, Zertifikatsketten und LDAPS: wenn Vertrauen und Kanalbindung brechen

Sobald LDAPS, Smartcard-Anmeldung, Zertifikatszuordnung oder TLS-gesicherte LDAP-Binds im Spiel sind, wird die Zertifikatsinfrastruktur zur AD-Kernabhängigkeit. Ein abgelaufenes DC-Zertifikat, fehlende Zwischenzertifikate, falsche EKU oder ein nicht vertrauenswürdiger Aussteller führen zu TLS-Abbrüchen, die in Anwendungen als LDAP-Bind-Fehler erscheinen. Typische Texte sind The LDAP server is unavailable in Kombination mit Schannel-Ereignissen wie Event ID 36882 oder Event ID 36888 (TLS-Handshake fehlgeschlagen).

Zusätzlich beeinflussen Hardening-Einstellungen die Interoperabilität: LDAP-Signing, Channel Binding und die Deaktivierung unsicherer TLS-Versionen machen Fehlkonfigurationen sichtbar, die zuvor latent waren. Besonders kritisch wird dies bei Systemen, die AD über LDAPS anbinden (z. B. Identity-Lösungen, Linux-SSSD, Appliances) oder bei Diensten, die Zertifikatsvorlagen und Autoenrollment aus AD beziehen. Bricht das Vertrauen, entstehen Kettenreaktionen von Authentifizierungsfehlern bis hin zu Ausfällen beim Zertifikatserhalt.

• Zertifikats- und TLS-Fehler korrelieren: Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Schannel']]]"
• Zertifikatsstatus am DC prüfen: certutil -store my
certutil -verify -urlfetch <Zertifikat.cer>

Replikation und Namensauflösung im Verbund: Konsistenz als Voraussetzung für „Wahrheit“

AD-Replikation stellt nicht nur Verfügbarkeit her, sondern Konsistenz. Ohne zeitnahe Replikation existieren Objektzustände nur „lokal“: Kennwortänderungen, Gruppenmitgliedschaften, SPNs, Zertifikatszuordnungen oder GPO-Änderungen kommen nicht überall an. Das äußert sich in scheinbar widersprüchlichem Verhalten: Anmeldung klappt an einem DC, scheitert an einem anderen; ein Dienstaccount „hat“ den SPN, aber Kerberos meldet dennoch KDC_ERR_S_PRINCIPAL_UNKNOWN oder KRB_ERR_RESPONSE_TOO_BIG wechselt plötzlich zu NTLM, weil ein DC einen anderen Stand hat.

Replikationsstörungen haben wiederum Abhängigkeiten: DNS-SRV-Records müssen korrekt sein, RPC muss passieren, Zeit muss stimmen, und die Site-Topologie muss zu den Subnetzen passen. Häufige Replikationsindikatoren sind Event ID 1311 (KCC kann keine Replikationstopologie bilden), Event ID 1566 (DSA-Operationen scheitern, oft DNS/Locator) oder im Diagnosewerkzeug die Fehler Repadmin /replsummary mit Last error: 1722, Last error: 1256 oder Last error: 8453. Solche Meldungen sind selten isoliert zu behandeln, weil sie auf Transport, Namensauflösung oder Authentifizierung zurückverweisen.

• Replikationsgesundheit komprimiert prüfen: repadmin /replsummary
repadmin /showrepl *
• AD- und DNS-Diagnosen bündeln: dcdiag /test:DNS /v
dcdiag /test:replications /v
• SYSVOL/DFSR-Status ergänzen: dfsrdiag replicationstate
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:<Quelle> /rmem:<Ziel>

Authentifizierungs- und Verzeichniszugriffsfehler verstehen: LDAP-Resultcodes, Kerberos- und NTLM-Statuswerte, typische Originalmeldungen

Authentifizierung und Verzeichniszugriff werden in Active Directory Domain Services (AD DS) über mehrere Protokolle und Subsysteme abgewickelt. Das erklärt, warum Fehlerbilder oft „uneinheitlich“ wirken: Ein und dieselbe Ursache kann als LDAP-Resultcode im Client, als Kerberos-Fehler im Security-Log, als NTSTATUS im SMB-Stack oder als Win32-Fehler in der Anwendung erscheinen. Präzise Einordnung gelingt nur, wenn Code, Originaltext und die Stelle im Ablauf (Bind, Ticket-Anforderung, Zugriff auf ein Objekt, Gruppenmitgliedschaftsauflösung) zusammen betrachtet werden.

Im Kern gilt: LDAP liefert Resultcodes für Verzeichnisoperationen (Bind, Search, Modify). Kerberos bewertet die Identität und stellt Tickets bereit (AS-REQ/TGS-REQ). NTLM ist ein Fallback-Mechanismus, der vor allem bei Legacy-Kompatibilität oder bestimmten Netzwerkpfaden sichtbar wird. Viele „Logon failed“-Meldungen sind daher nicht primär AD-Fehler, sondern Ausdruck eines fehlgeschlagenen Zusammenspiels aus Namensauflösung, Zeitkonsistenz, SPN-Zuordnung, Kanalbindung oder Richtlinien (z. B. „LDAP signing“, „Channel Binding“, „Kerberos armoring“).

LDAP-Resultcodes und typische AD-Originalmeldungen

LDAP-Fehlercodes erscheinen in Anwendungen, in AD-Verwaltungstools und in Protokollen von Diensten, die gegen AD binden (z. B. Exchange, ADFS, Drittprodukte). AD DS verwendet LDAPv3-Resultcodes (numerisch) und ergänzt sie häufig um „data“-Untercodes, insbesondere beim Bind. Diese Untercodes stammen aus der Windows-Implementierung und sind entscheidend, um z. B. „falsches Kennwort“ von „Konto gesperrt“ zu trennen.

Bei LDAP-Bind-Problemen ist die Kombination aus 49 plus „data“-Untercode die verlässlichste Differenzierung. Ein häufiges Missverständnis: 52e wirkt wie „AD ist kaputt“, ist aber in der Regel schlicht ein nicht passendes Kennwort oder ein Credential-Cache-Problem. Dagegen deuten 530/531 eher auf Anmelderestriktionen (Workstation-/Zeitfenster), und 775 auf Lockout-Policies oder auffällige Fehlversuche aus anderen Systemen.

• LDAP invalidCredentials mit Untercode: Häufige Originalform AcceptSecurityContext error, data 52e, v2580; „data“ ist die entscheidende Präzisierung innerhalb des 49-Resultcodes.
• UnwillingToPerform bei Hardening: Typische Ursache sind Vorgaben wie „LDAP signing required“ oder Channel-Binding-Anforderungen; sichtbar in Verbindungsfehlern von Clients, die weiterhin „simple bind“ oder unsignierte SASL-Binds nutzen.
• InsufficientAccessRights bei Service-Konten: Schreibversuche auf sensitive Attribute wie servicePrincipalName oder msDS-KeyCredentialLink scheitern ohne passende Rechte; Folge sind oft indirekte Kerberos-/PKINIT-Probleme in nachgelagerten Systemen.

Kerberos-Fehler: KDC-Codes, Security-Eventtexte und ihre Ursachen

Kerberos-Fehler werden auf Clients, Mitgliedsservern und Domain Controllern protokolliert und sind häufig der „ehrlichere“ Indikator als eine generische Anmeldefehlermeldung. Typisch sind Fehler beim Anfordern eines Ticket Granting Ticket (TGT) oder eines Service-Tickets (TGS). Sichtbar wird das u. a. in Windows-Security-Events auf dem Client (z. B. Event ID 4771 für Pre-Authentication failed) oder auf dem DC, wenn der KDC die Anfrage ablehnt. Relevante Ursachen sind falsche Zeit, gesperrte/abgelaufene Konten, fehlende oder doppelte SPNs, falsche Verschlüsselungstypen sowie Kennwort-/Schlüsselinkonsistenzen nach Rollbacks oder fehlerhaften Wiederherstellungen.

Kerberos-Fehler wirken selten isoliert. Ein fehlender SPN führt nicht nur zu Ticket-Problemen, sondern kippt häufig in NTLM-Fallback (sofern erlaubt) oder erzeugt in HTTP/SQL/SMB-Stacks sekundäre Fehler („Access denied“, „The target principal name is incorrect“). Bei KRB_AP_ERR_MODIFIED liegt der Schwerpunkt fast immer auf SPN-Duplikaten oder einem Kontowechsel des Dienstes; reine „Netzwerkprobleme“ sind hier die Ausnahme.

• SPN-Prüfung bei KDC_ERR_S_PRINCIPAL_UNKNOWN oder KRB_AP_ERR_MODIFIED: setspn -Q HTTP/fqdn.example.tld
setspn -X
• Ticket- und Cache-Sicht auf dem Client: klist
klist purge
• Kerberos/Logon-Signale in Security-Logs: Event ID 4768 (TGT), Event ID 4769 (TGS), Event ID 4771 (Pre-Auth-Fehler) liefern Statuscodes, Kontonamen und den angefragten SPN als Korrelation zu DNS- und Dienstkonfiguration.

NTLM- und Logon-Statuswerte: NTSTATUS, Win32, typische Texte

NTLM-Fehler werden häufig als NTSTATUS-Codes (0xC000…) sichtbar, z. B. in Security-Events (Event ID 4625: „An account failed to log on“) oder in Applikationslogs, wenn ein Dienst NTLM nutzt oder Kerberos nicht zustande kommt. Diese Codes sind nicht „NTLM-exklusiv“; sie beschreiben den Status des Logon-Vorgangs in der LSA/Netlogon-Kette und treten auch bei Kerberos-gestützten Logons als Endzustand auf, wenn die Anmeldung insgesamt scheitert.

Bei NTLM/Logon-Fehlern entscheidet der Kontext: Tritt der Status bei Zugriff auf \\server\share oder HTTP auf, kann ein Kerberos-Problem (SPN/DNS) im Hintergrund stehen, das in NTLM-Fallback kippt und dort an Richtlinien scheitert (z. B. NTLM eingeschränkt, „Restrict NTLM“). Tritt der Status dagegen direkt am interaktiven Logon auf, dominieren Konto-/Kennwortzustände, Gerätekonto-Probleme oder sichere Kanalbeziehungen. Die saubere Trennung gelingt über gleichzeitige Sicht auf Event ID 4625 (Status/Substatus), Kerberos-Events (4768/4769/4771) und LDAP-Bind-Fehler der beteiligten Anwendung.

• Logon-Failure-Korrelation: Event ID 4625 liefert Status und Sub Status (NTSTATUS) sowie Logon Type; zusammen mit Workstation Name und Source Network Address entsteht die belastbare Zuordnung zu einem Clientpfad.
• Gezielte Prüfung des verwendeten Authentifizierungsmechanismus: In vielen Serverrollen zeigt Event ID 4769 den angefragten SPN; fehlt ein passender 4769-Eintrag bei gleichzeitigem Fehlschlag, ist NTLM-Fallback oder ein früher Abbruch (DNS/Reachability) wahrscheinlich.
• Häufiger Originaltext bei Kerberos→NTLM-Kaskaden: Anwendungen protokollieren statt eines Kerberos-Codes oft nur The target principal name is incorrect oder Cannot generate SSPI context; die Ursache liegt dann typischerweise bei SPN/DNS/Zeit und nicht bei „Rechten“ auf dem Zielobjekt.

Domänencontroller-Betrieb und Gesamtstrukturfehler einordnen: Replikationsmeldungen, FSMO-Probleme, Schema/Konfiguration, Berechtigungen, Trusts und Erreichbarkeit

Fehlerbilder im Domänencontroller-Betrieb entstehen selten „nur“ im Active Directory. Replikation, FSMO-Rollen, Schema und Konfiguration sind eng mit DNS-Namensauflösung, RPC-Endpunkten, Zeitquelle, Netzwerkpfaden und konsistenten Sicherheitsdeskriptoren verknüpft. Die Folge: Ein einzelner Ausfall kann als Replikationsstörung, als Trust-Fehler, als „Zugriff verweigert“-Meldung oder als scheinbar banale Ereignis-ID in unterschiedlichen Logs erscheinen. Für eine belastbare Einordnung hilft es, Fehlertexte und Codes strikt nach Funktionsbereich zuzuordnen und anschließend die zugrunde liegenden Mechanismen (KCC, USN/InvocationID, RPC/SMB, LDAP, Kerberos) gegenzuprüfen.

Replikationsmeldungen: KCC, RPC, USN und Namensauflösung

Die AD-Replikation nutzt Standorte/Standortlinks, den Knowledge Consistency Checker (KCC) und RPC über dynamische Ports; zusätzlich werden Partitionsdaten (Domäne, Konfiguration, Schema, ggf. Anwendungsverzeichnisse) getrennt behandelt. DNS spielt dabei eine Schlüsselrolle, weil Replikationspartner über SRV-Records (z. B. _ldap._tcp.dc._msdcs) und die Auflösung der Partnernamen gefunden werden. Fehler im Netzwerkpfad, in der RPC-Endpunktzuordnung oder in der Namensauflösung schlagen deshalb häufig als Replikationsfehler durch, obwohl die Ursache außerhalb von NTDS liegt.

USN-Rollback- und Metadatenprobleme sind besonders gefährlich, weil sie nicht nur „Replikation langsam“ bedeuten, sondern die Änderungsverfolgung brechen. Hinweise liefern repadmin /showrepl, repadmin /replsummary und im Ernstfall die Kombination aus Ereignissen in Directory Service und replizierten Attribut-Metadaten. Ein häufiges Abgrenzungsmerkmal: DNS-/RPC-Probleme erzeugen Verbindungsfehler (z. B. 1722/1753), während USN-/Metadatenbrüche eher als „inkonsistente“ oder „zu alt“ klassifiziert werden (z. B. 2042).

FSMO-Rollen und Rolleninhaber: wenn „Single Master“ zum Single Point wird

FSMO-Rollen wirken punktuell, aber mit harter Wirkungskante: RID Master (SID/RID-Vergabe), PDC Emulator (Zeit, Kennwortänderungen, Kontosperren, viele Kompatibilitätsfunktionen), Infrastructure Master (Referenzobjekte), sowie Schema- und Domain Naming Master (Gesamtstruktur-Änderungen). In Störungslagen treten FSMO-Probleme selten als „FSMO defekt“ auf, sondern als Folgefehler: neue Benutzer/Computer lassen sich nicht erstellen (RID), Kennwortänderungen replizieren nicht (PDC), Domänenbeitritte scheitern, oder Schemaänderungen werden verweigert.

• Rollenstatus prüfen: netdom query fsmo
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
• Typische Rollenfehlertexte: The RPC server is unavailable. beim Rolleninhaberzugriff (Netz/RPC/DNS), Access is denied. bei fehlenden Rechten, sowie allgemeine LDAP/RPC-Status wie 0x000020AF (LDAP_UNWILLING_TO_PERFORM) bei Operationen, die vom Rolleninhaber abhängig sind.
• Rollenübernahme als Störfallmaßnahme: Move-ADDirectoryServerOperationMasterRole -Identity <DC> -OperationMasterRole PDCEmulator,RIDMaster für kontrollierte Transfers; ntdsutil wird in der Praxis vor allem für Seize-Szenarien genutzt und setzt saubere Metadatenbereinigung sowie die dauerhafte Nichtrückkehr des alten Rolleninhabers voraus.

Viele „FSMO-Probleme“ sind in Wahrheit Zeit- oder Replikationsprobleme: Der PDC Emulator muss als zuverlässige Zeitquelle und als Kerberos-Referenz stabil erreichbar sein; ist er es nicht, zeigen sich Dominoeffekte bei Anmeldungen, bei Gruppenrichtlinienverarbeitung und bei Kennwortvalidierung über Standorte hinweg. Daher sollten FSMO-Störungen stets parallel als Erreichbarkeits- und Replikationsproblem betrachtet werden.

Schema- und Konfigurationsprobleme: wenn Forest-weite Metadaten brechen

Schema und Konfiguration replizieren forestweit. Fehler in diesen Partitionen wirken deshalb nicht lokal, sondern in der gesamten Gesamtstruktur: Setup-Routinen (Exchange, ADFS, AD CS-Erweiterungen), neue Funktionsobjekte oder Attribute werden unterschiedlich gesehen, und DCs verhalten sich widersprüchlich. Typische Symptome sind LDAP-Fehler beim Anlegen/Ändern von Objekten, nicht auflösbare Klassen/Attribute oder widersprüchliche Objektreferenzen in der Konfigurationspartition.

Ein häufiger Stolperstein sind „phantomartige“ Fehler nach partiellen Rollbacks von Snapshots oder unsauberen Wiederherstellungen: AD DS toleriert keine Zeitreise auf DCs, weil USNs und InvocationIDs die Änderungsverfolgung absichern. Schema-/Konfigurationsauffälligkeiten sollten daher stets gegen Replikationsgesundheit und gegen die Historie von Virtualisierung/Restore-Prozessen geprüft werden.

Berechtigungen und Delegation: „Access Denied“ richtig lokalisieren

Berechtigungsfehler in AD DS werden in der Praxis oft mit „Authentifizierung“ verwechselt. Häufig liegt die Anmeldung korrekt vor, aber der Security Descriptor des Zielobjekts, vererbte ACLs, geschützte Adminobjekte (AdminSDHolder) oder fehlende Extended Rights verhindern die Operation. Relevant ist außerdem, auf welchem DC die Operation landet: Schreiboperationen laufen gegen beschreibbare DCs; bei RODCs greifen zusätzliche Einschränkungen.

• Häufiger LDAP-Status bei Delegationsfehlern: 0x00002098 (LDAP_INSUFFICIENT_ACCESS_RIGHTS) – die Identität ist authentifiziert, aber nicht autorisiert; Abgrenzung zu „Server nicht erreichbar“ gelingt über parallele Erreichbarkeitsprüfungen und durch Auswertung des Security-Logs.
• Typische Windows-Fehlertexte: Access is denied. und The requested operation was not performed because the user has not been authenticated. (zweiteres oft Folge von Bind-/Sign/Seal-Anforderungen oder Kanalbindungs-/LDAP-Signing-Konflikten, je nach Umgebungskonfiguration).
• Rechte-/Objektprüfung: dsacls "CN=<Objekt>,<DN>"
Get-ACL "AD:CN=<Objekt>,<DN>" (AD-Drive aus RSAT/AD-Modul) zur Sicht auf effektive ACLs; AdminSDHolder-Einflüsse prüfen über CN=AdminSDHolder,CN=System,<DN>.

Delegationsfehler wirken unmittelbar auf Folge-Systeme: fehlende Rechte auf Service-Accounts stören SPN-Registrierungen, Kerberos-Delegation und damit auch Anwendungen, die auf Kerberos constrained delegation angewiesen sind. In Exchange- oder Zertifikatsdienst-Szenarien führt das typischerweise zu Kaskaden aus Authentifizierungsfehlern, obwohl der Root Cause eine ACL- oder Extended-Right-Differenz im Verzeichnis ist.

Trusts und Erreichbarkeit: wenn Domänen sich „sehen“, aber nicht vertrauen

Vertrauensstellungen hängen von DNS, korrekter Zeit (Kerberos), funktionierendem Secure Channel und erreichbaren DCs in beiden Domänen ab. Fehler werden oft als Netlogon- oder LSA-Probleme sichtbar, obwohl die Ursache ein falscher SRV-Record, ein abgelaufener Kennwortschlüssel der Trust-Beziehung oder ein Routingproblem zwischen Standorten ist. Zusätzlich verschärfen strenge Kerberos-/PAC-Validierung und unvollständige Replikation die Lage, weil Tickets zwar ausgestellt, aber nicht mehr sauber verifiziert werden.

Die Einordnung von Erreichbarkeitsproblemen beginnt konsequent mit Namensauflösung und Pfadprüfung, bevor AD-spezifische Hypothesen dominieren. Für DC-zu-DC- und Client-zu-DC-Pfade sind SRV-Auflösung, TCP/UDP-Erreichbarkeit und konsistente Zeit die Grundbedingungen, damit LDAP, Kerberos und RPC überhaupt sinnvoll diagnostiziert werden können. Erst wenn diese Basis stabil ist, lassen sich Replikations-, Rollen- und Berechtigungsfehler belastbar voneinander trennen.