# 8.2 Active Directory, Gruppenrichtlinien und Kerberos analysieren Active Directory Domain Services bilden in vielen Windows-Netzwerken die Grundlage für: - Benutzer- und Computeranmeldung, - zentrale Authentifizierung, - Gruppen und Berechtigungen, - Gruppenrichtlinien, - DNS-basierte Diensterkennung, - Kerberos-Tickets, - Vertrauensstellungen, - Zertifikatdienste, - Datei-, Druck- und Anwendungszugriffe. Eine scheinbar einfache Meldung wie „Anmeldung nicht möglich“, „Zugriff verweigert“ oder „Gruppenrichtlinie wird nicht angewendet“ kann deshalb unterschiedliche Ursachen haben: - falsche DNS-Konfiguration, - nicht erreichbarer Domänencontroller, - fehlerhafte Zeitsynchronisation, - gestörter Secure Channel, - Replikationsfehler, - falsche Gruppenmitgliedschaft, - fehlerhafte GPO-Verknüpfung, - Sicherheitsfilterung, - WMI-Filter, - Kerberos- oder SPN-Fehler, - nicht repliziertes Kennwort, - gesperrtes oder deaktiviertes Konto, - beschädigtes Computer- oder Benutzerprofil, - fehlende Netzwerkports, - fehlerhafte Vertrauensstellung. Die Komponenten müssen gemeinsam und in einer festen Reihenfolge untersucht werden. --- **1. Lernziele** Nach dieser Seite kannst du: - Active-Directory-Fehler systematisch eingrenzen, - Client-, Server- und Domänencontrollerprobleme unterscheiden, - den verwendeten Domänencontroller bestimmen, - DNS- und SRV-Einträge prüfen, - Zeitsynchronisation untersuchen, - den Secure Channel eines Clients bewerten, - AD-Replikationsfehler erkennen, - Gruppenrichtlinienergebnisse auswerten, - Kerberos-Tickets und SPNs prüfen, - typische Ereignisprotokolle zuordnen, - zwischen Symptom, Ursache und Nebenbefund unterscheiden, - Änderungen kontrolliert und mit Rückweg durchführen. --- **2. Vereinfachte Abhängigkeitskette** ```text Benutzer oder Computer ↓ IP-Konnektivität ↓ DNS-Auflösung und SRV-Einträge ↓ Erreichbarer Domänencontroller ↓ Zeitsynchronisation ↓ Secure Channel und Computerkonto ↓ Kerberos oder NTLM ↓ Active-Directory-Replikation ↓ Gruppenmitgliedschaften und Berechtigungen ↓ Gruppenrichtlinien und Anwendungszugriff ``` Ein Fehler weiter oben kann zahlreiche Folgefehler auslösen. Beispiele: - Falsches DNS kann verhindern, dass ein Domänencontroller gefunden wird. - Eine zu große Zeitabweichung kann Kerberos-Authentifizierung verhindern. - Eine fehlerhafte AD-Replikation kann dazu führen, dass ein neues Kennwort nur an einem Domänencontroller bekannt ist. - Eine fehlerhafte SYSVOL-Replikation kann dazu führen, dass eine GPO zwar im Verzeichnis vorhanden ist, ihre Dateien aber nicht überall verfügbar sind. - Ein doppelter SPN kann verhindern, dass für einen Dienst ein gültiges Kerberos-Ticket ausgestellt wird. --- **3. Sicherheits- und Betriebsregeln** Vor Änderungen müssen mindestens folgende Informationen gesichert werden: - genauer Fehlertext, - Fehlercode, - Zeitpunkt und Zeitzone, - betroffener Benutzer, - betroffener Computer, - verwendeter Domänencontroller, - betroffener Dienst oder Server, - letzte Änderungen, - aktuelle DNS-Konfiguration, - Zeitquelle und Zeitabweichung, - Gruppenrichtlinienergebnis, - Replikationsstatus, - relevante Ereignisse. Nicht als erste Maßnahme durchführen: - Computer aus der Domäne entfernen und wieder aufnehmen, - Computerkonto löschen, - Benutzerkonto neu erstellen, - GPO löschen oder vollständig deaktivieren, - AD-Replikation ungeprüft erzwingen, - Kerberos-Konfiguration in der Registry ändern, - Domänencontroller neu starten, - DNS-Einträge wahllos löschen, - SPNs ohne vorherige Prüfung verändern, - große Berechtigungsgruppen hinzufügen, - alle Gruppenrichtlinien gleichzeitig zurücksetzen. Solche Maßnahmen verändern oder vernichten den Zustand, der für die Ursachenanalyse benötigt wird. --- **4. Fehlerbild exakt erfassen** Wichtige Fragen: - Scheitert die lokale oder die Domänenanmeldung? - Ist nur ein Benutzer betroffen? - Ist nur ein Computer betroffen? - Sind mehrere Computer einer OU oder eines Standorts betroffen? - Funktioniert der Zugriff über IP-Adresse, aber nicht über Namen? - Funktioniert die Anmeldung mit zwischengespeicherten Anmeldedaten? - Tritt der Fehler nur bei einem bestimmten Domänencontroller auf? - Betrifft das Problem Benutzer- oder Computerrichtlinien? - Ist nur ein bestimmter Dienst betroffen? - Funktioniert NTLM, während Kerberos scheitert? - Trat der Fehler nach Kennwortänderung, Wiederherstellung, Snapshot, Migration oder GPO-Änderung auf? - Ist der Fehler dauerhaft oder nur zeitweise vorhanden? - Funktioniert ein vergleichbarer Benutzer oder Computer? Ein Client, ein Benutzer und eine konkrete Zielressource sollten als kontrollierter Testfall verwendet werden. --- **5. Grundinformationen auf dem Client erfassen** Identität: ```cmd whoami ``` Benutzer-Domäne: ```cmd echo %USERDOMAIN% ``` Anmeldeserver: ```cmd echo %LOGONSERVER% ``` Vollständige Benutzerinformationen: ```cmd whoami /all ``` Computername: ```cmd hostname ``` Domänenzugehörigkeit: ```powershell Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain, UserName ``` IP-Konfiguration: ```cmd ipconfig /all ``` Dabei sind besonders zu prüfen: - IPv4- und IPv6-Adresse, - Subnetzmaske beziehungsweise Präfix, - Standardgateway, - DNS-Server, - DNS-Suffix, - DHCP-Status, - Verbindungssuffix, - mehrere aktive Netzwerkadapter, - VPN-, virtuelle oder alte Adapter. Domänenmitglieder sollten grundsätzlich die für die AD-Domäne zuständigen internen DNS-Server verwenden. Ein öffentlicher DNS-Server kennt die internen AD-SRV-Einträge normalerweise nicht. --- **6. Verwendeten Domänencontroller bestimmen** Anmeldeserver: ```cmd echo %LOGONSERVER% ``` Domänencontroller für die Domäne suchen: ```cmd nltest /dsgetdc: ``` Beispiel: ```cmd nltest /dsgetdc:ad.example.local ``` Domänencontroller auflisten: ```cmd nltest /dclist: ``` Aktuellen DC über PowerShell bestimmen: ```powershell Get-ADDomainController -Discover ``` Alle bekannten Domänencontroller: ```powershell Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, IsGlobalCatalog, OperationMasterRoles ``` Die PowerShell-Befehle des Active-Directory-Moduls erfordern die entsprechenden RSAT-Komponenten oder die Ausführung auf einem geeigneten Verwaltungsserver. Zu dokumentieren sind: - Name des verwendeten Domänencontrollers, - Standort beziehungsweise AD-Site, - IP-Adresse, - Global-Catalog-Status, - Erreichbarkeit, - Zeitpunkt des Tests. --- **7. DNS als erste technische Abhängigkeit prüfen** Hostauflösung: ```cmd nslookup ``` Vollqualifizierten Namen prüfen: ```cmd nslookup . ``` Domänencontroller über LDAP-SRV-Einträge suchen: ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs. ``` Kerberos-Dienste suchen: ```cmd nslookup -type=SRV _kerberos._tcp. ``` Global Catalog suchen: ```cmd nslookup -type=SRV _gc._tcp. ``` Standortspezifische Domänencontroller: ```cmd nslookup -type=SRV _ldap._tcp.._sites.dc._msdcs. ``` PowerShell: ```powershell Resolve-DnsName -Type SRV ` _ldap._tcp.dc._msdcs. ``` Zu prüfen sind: - existieren die erwarteten SRV-Einträge, - zeigen die Einträge auf vorhandene Domänencontroller, - lassen sich deren Hostnamen auflösen, - stimmen die IP-Adressen, - antwortet der vorgesehene interne DNS-Server, - werden alte oder stillgelegte Domänencontroller zurückgegeben, - liefert ein anderer DNS-Server abweichende Ergebnisse, - ist das DNS-Suffix korrekt, - bestehen doppelte A- oder AAAA-Einträge. Ein erfolgreicher Ping auf eine IP-Adresse beweist keine funktionierende AD-DNS-Struktur. --- **8. Erreichbarkeit benötigter Dienste prüfen** Grundlegende Verbindung: ```powershell Test-NetConnection ``` DNS: ```powershell Test-NetConnection -Port 53 ``` Kerberos: ```powershell Test-NetConnection -Port 88 ``` LDAP: ```powershell Test-NetConnection -Port 389 ``` SMB für SYSVOL und NETLOGON: ```powershell Test-NetConnection -Port 445 ``` RPC Endpoint Mapper: ```powershell Test-NetConnection -Port 135 ``` Global Catalog: ```powershell Test-NetConnection -Port 3268 ``` LDAPS, sofern verwendet: ```powershell Test-NetConnection -Port 636 ``` Global Catalog über TLS, sofern verwendet: ```powershell Test-NetConnection -Port 3269 ``` Wichtige Dienste und Ports können unter anderem sein: | Funktion | Typischer Port | |---|---:| | DNS | TCP/UDP 53 | | Kerberos | TCP/UDP 88 | | RPC Endpoint Mapper | TCP 135 | | LDAP | TCP/UDP 389 | | SMB | TCP 445 | | Kerberos-Kennwortänderung | TCP/UDP 464 | | LDAPS | TCP 636 | | Global Catalog | TCP 3268 | | Global Catalog über TLS | TCP 3269 | | dynamisches RPC | konfigurationsabhängiger TCP-Portbereich | Ein erfolgreich getesteter TCP-Port beweist nur, dass eine Verbindung zu diesem Port hergestellt werden konnte. Er beweist nicht, dass Authentifizierung, LDAP-Abfrage, Replikation oder Gruppenrichtlinienverarbeitung funktionieren. --- **9. SYSVOL und NETLOGON prüfen** Freigaben des Domänencontrollers: ```cmd net view \\ ``` SYSVOL öffnen: ```cmd dir \\\SYSVOL ``` NETLOGON öffnen: ```cmd dir \\\NETLOGON ``` Direkter Domänenpfad: ```cmd dir \\\SYSVOL ``` Zu prüfen sind: - Freigaben vorhanden, - Namensauflösung funktioniert, - Zugriff unter dem vorgesehenen Benutzer möglich, - benötigte GPO-Verzeichnisse vorhanden, - Skripte und Vorlagen erreichbar, - unterschiedliche Domänencontroller liefern denselben erwarteten Inhalt. Eine GPO besteht aus zwei zusammengehörigen Teilen: | Bestandteil | Speicherort | |---|---| | Group Policy Container | Active Directory | | Group Policy Template | SYSVOL | Sind die beiden Teile oder ihre Versionsstände nicht konsistent, kann die Gruppenrichtlinienverarbeitung fehlschlagen. --- **10. Zeitsynchronisation prüfen** Aktueller Status: ```cmd w32tm /query /status ``` Zeitquelle: ```cmd w32tm /query /source ``` Konfiguration: ```cmd w32tm /query /configuration ``` Domänenhierarchie überwachen: ```cmd w32tm /monitor ``` Vergleich mit einem bestimmten Domänencontroller: ```cmd w32tm /stripchart /computer: /samples:10 /dataonly ``` Windows-Zeitdienst: ```powershell Get-Service W32Time ``` Zu prüfen sind: - aktuelle Zeit, - Zeitzone, - Zeitquelle, - Zeitabweichung, - Dienststatus, - Domänenhierarchie, - Erreichbarkeit der Zeitquelle, - Virtualisierung und Host-Zeitsynchronisation, - PDC-Emulator als maßgebliche Domänenzeitquelle. Kerberos reagiert empfindlich auf Zeitabweichungen. Der konkrete Fehler muss jedoch anhand von Ereignissen, Ticketstatus und Zeitmessung nachgewiesen werden. Eine manuelle Änderung der Uhrzeit beseitigt nicht automatisch die Ursache einer falschen Zeitquelle. --- **11. Secure Channel des Computers prüfen** Der Secure Channel ist die geschützte Beziehung zwischen einem Domänenmitglied und der Domäne. Prüfung mit PowerShell: ```powershell Test-ComputerSecureChannel -Verbose ``` Prüfung mit NLTEST: ```cmd nltest /sc_verify: ``` Verwendeten sicheren Kanal anzeigen: ```cmd nltest /sc_query: ``` Mögliche Symptome eines gestörten Secure Channels: - „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne ist fehlgeschlagen“, - Anmeldung funktioniert nur mit zwischengespeicherten Daten, - Gruppenrichtlinien schlagen fehl, - Zugriff auf Domänenressourcen scheitert, - Computerkonto-Kennwort stimmt zwischen Client und AD nicht überein. Mögliche Ursachen: - Rücksetzen auf einen alten VM-Snapshot, - geklontes System mit fehlerhafter Identität, - wiederhergestelltes Computerkonto, - Replikationsfehler, - doppelt verwendeter Computername, - beschädigtes Computerkonto, - lange getrenntes oder falsch wiederhergestelltes System. Eine Reparatur des Secure Channels ist eine Änderung und darf erst nach Sicherung der Diagnoseergebnisse erfolgen. Mögliche kontrollierte Reparatur auf einem Domänenmitglied: ```powershell Test-ComputerSecureChannel -Repair ` -Credential \ ``` Vorher müssen geprüft werden: - DNS funktioniert, - Domänencontroller ist erreichbar, - Zeit stimmt, - Computerkonto ist vorhanden und eindeutig, - keine Replikationsstörung liegt vor, - Berechtigung zur Reparatur ist vorhanden, - Rückweg und Wartungsfenster sind festgelegt. `Test-ComputerSecureChannel` ist vor allem für Domänenmitglieder vorgesehen. Bei Domänencontrollern müssen DC-spezifische Diagnose- und Reparaturverfahren verwendet werden. --- **12. Benutzer- und Computerkonto prüfen** Benutzerkonto: ```powershell Get-ADUser -Identity -Properties * | Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, LastBadPasswordAttempt, BadLogonCount, AccountExpirationDate ``` Computerkonto: ```powershell Get-ADComputer -Identity -Properties * | Select-Object Name, Enabled, DNSHostName, PasswordLastSet, LastLogonDate, DistinguishedName ``` Gruppenmitgliedschaften: ```powershell Get-ADPrincipalGroupMembership | Select-Object Name, GroupScope, GroupCategory ``` Aktuelles Benutzer-Token: ```cmd whoami /groups ``` Zu unterscheiden sind: - im Active Directory gespeicherte Gruppenmitgliedschaften, - Gruppen im aktuellen Anmeldetoken, - verschachtelte Gruppen, - lokale Gruppen, - universelle, globale und domänenlokale Gruppen, - Änderungen nach der letzten Anmeldung. Eine neu hinzugefügte Gruppenmitgliedschaft ist nicht automatisch im bereits bestehenden Benutzer-Token enthalten. Ab- und erneute Anmeldung kann erforderlich sein. Bei bestimmten Dienstkonten kann ein Dienstneustart notwendig sein. --- **13. Kontosperrung untersuchen** Zu prüfen sind: - ist das Konto tatsächlich gesperrt, - auf welchem Domänencontroller wurde die Sperrung registriert, - welcher Client oder Dienst sendet falsche Anmeldedaten, - existieren gespeicherte Anmeldedaten, - läuft ein Dienst oder eine geplante Aufgabe mit altem Kennwort, - verwendet ein Smartphone, VPN oder Netzlaufwerk alte Zugangsdaten, - tritt die Sperrung unmittelbar nach dem Entsperren erneut auf. Benutzerstatus: ```powershell Get-ADUser ` -Properties LockedOut, LastBadPasswordAttempt, BadLogonCount, PasswordLastSet ``` Gesperrte Konten suchen: ```powershell Search-ADAccount -LockedOut -UsersOnly ``` Relevante Sicherheitsereignisse können unter anderem betreffen: - fehlgeschlagene Anmeldung, - Kontosperrung, - Kerberos-Vorauthentifizierungsfehler, - Ticketanforderungen, - Anmeldungen mit expliziten Anmeldedaten. Ein Konto lediglich wiederholt zu entsperren beseitigt die Quelle der falschen Anmeldedaten nicht. --- **14. Domänencontroller grundsätzlich prüfen** Ausführliche Diagnose: ```cmd dcdiag /v ``` Ausgabe in Datei: ```cmd dcdiag /v /c /d /e > C:\Temp\dcdiag.txt ``` DNS-Test: ```cmd dcdiag /test:dns /v ``` Replikationstest: ```cmd dcdiag /test:replications /v ``` SYSVOL-Test: ```cmd dcdiag /test:sysvolcheck /v ``` Werbungsstatus des Domänencontrollers: ```cmd dcdiag /test:advertising /v ``` NETLOGON-Freigabe: ```cmd dcdiag /test:netlogons /v ``` Zu prüfen sind: - welcher Test fehlschlägt, - welcher Domänencontroller betroffen ist, - genauer Fehlercode, - Zeitpunkt, - DNS-Abhängigkeit, - Replikationspartner, - Verzeichnispartition, - Warnung oder tatsächlicher Fehler. Nicht jede Warnung in einer umfangreichen `dcdiag`-Ausgabe erklärt das untersuchte Symptom. Der Befund muss zeitlich und technisch zum Fehler passen. --- **15. AD-Replikation prüfen** Gesamtübersicht: ```cmd repadmin /replsummary ``` Eingehende Replikation eines DCs: ```cmd repadmin /showrepl ``` Gesamtstrukturweite Anzeige: ```cmd repadmin /showrepl * /csv ``` PowerShell-Auswertung: ```powershell repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView ``` Replikationsfehler über PowerShell: ```powershell Get-ADReplicationFailure ` -Target * ` -Scope Forest ``` Status der Replikationspartner: ```powershell Get-ADReplicationPartnerMetadata ` -Target * ` -Scope Forest | Select-Object Server, Partner, Partition, LastReplicationAttempt, LastReplicationSuccess, LastReplicationResult ``` Replikationswarteschlange: ```cmd repadmin /queue ``` Zu dokumentieren sind: - Quell- und Ziel-DC, - Verzeichnispartition, - letzte erfolgreiche Replikation, - letzter Replikationsversuch, - Anzahl aufeinanderfolgender Fehler, - Fehlercode, - Fehlertext, - betroffene Standorte, - Richtung des Fehlers. --- **16. Replikationsfehler richtig bewerten** AD-Replikation hängt unter anderem ab von: - DNS, - Netzwerkverbindungen, - RPC, - Authentifizierung, - Autorisierung, - Zeit, - Replikationstopologie, - Verzeichnisdatenbank, - Zustand der Domänencontroller. | Befund | Mögliche Ursache | |---|---| | Fehler 1722 | RPC-Server nicht verfügbar, DNS, Firewall oder Dienstproblem | | Fehler 5 | Zugriff verweigert, Authentifizierung oder Berechtigung | | Zielprinzipalname ist falsch | Kerberos-, SPN- oder Computerkonto-Problem | | letzter Erfolg lange her | dauerhafte oder standortbezogene Störung | | nur eine Partition betroffen | partitions- oder DNS-bezogenes Problem | | nur ein Partner betroffen | Verbindung, DNS oder Zustand dieses Partners | | Änderungen fehlen nur auf einem DC | eingehende Replikation dieses DCs prüfen | | verschiedene Kennwörter funktionieren je nach DC | Kennwortreplikation oder allgemeine Replikation prüfen | | GPO fehlt nur auf einem DC | AD- und SYSVOL-Replikation gemeinsam prüfen | Eine erzwungene Synchronisation ist keine erste Diagnosemaßnahme. Sie kann zusätzliche Last erzeugen und verdeckt möglicherweise die Richtung oder den ursprünglichen Zustand des Fehlers. --- **17. FSMO-Rollen prüfen** ```cmd netdom query fsmo ``` PowerShell: ```powershell Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster ``` Die Rollen sind: | Rolle | Ebene | Wichtige Funktion | |---|---|---| | Schema-Master | Gesamtstruktur | Schemaänderungen | | Domänennamen-Master | Gesamtstruktur | Domänen und Partitionen | | RID-Master | Domäne | RID-Pools für Sicherheitskennungen | | PDC-Emulator | Domäne | Zeit, Kennwortpriorität und weitere Funktionen | | Infrastruktur-Master | Domäne | domänenübergreifende Objektbezüge | Der Ausfall eines FSMO-Rolleninhabers erklärt nicht automatisch jede Anmeldestörung. Die betroffene Funktion und die Ausfalldauer müssen berücksichtigt werden. --- **18. Gruppenrichtlinien-Grundlagen** Die normale Verarbeitungsreihenfolge lautet: ```text Lokal → Site → Domäne → OU → untergeordnete OU ``` Diese Reihenfolge wird häufig mit `LSDOU` bezeichnet. Grundsätzlich gilt: - Gruppenrichtlinien werden kumulativ verarbeitet. - Näher am Benutzer- oder Computerobjekt verknüpfte Einstellungen können frühere Einstellungen überschreiben. - Die genaue Wirkung hängt von Verknüpfungsreihenfolge, Vererbung, Erzwingen, Sicherheitsfilterung und Richtlinientyp ab. - Computer- und Benutzerkonfiguration werden getrennt verarbeitet. - Nicht jede Erweiterung wird bei jeder Hintergrundaktualisierung vollständig verarbeitet. - Loopbackverarbeitung kann die Benutzerkonfiguration abhängig vom Computerstandort verändern. Mögliche Ursachen für eine nicht angewendete GPO: - GPO nicht an der richtigen Site, Domäne oder OU verknüpft, - Link deaktiviert, - GPO vollständig oder teilweise deaktiviert, - Objekt befindet sich in der falschen OU, - Sicherheitsfilterung schließt Benutzer oder Computer aus, - fehlende Leseberechtigung, - WMI-Filter liefert `False`, - Vererbung blockiert, - andere GPO besitzt höhere Priorität, - Einstellung gilt nur für Benutzer oder nur für Computer, - langsame Netzwerkverbindung, - erforderliche synchrone Verarbeitung noch nicht erfolgt, - Neustart oder erneute Anmeldung fehlt, - SYSVOL nicht erreichbar, - AD- oder SYSVOL-Replikation gestört, - Client Side Extension schlägt fehl. --- **19. Gruppenrichtlinienergebnis erfassen** Kurzübersicht: ```cmd gpresult /r ``` Computerrichtlinien mit erhöhten Rechten: ```cmd gpresult /scope computer /r ``` Benutzerrichtlinien: ```cmd gpresult /scope user /r ``` Ausführlicher HTML-Bericht: ```cmd gpresult /h C:\Temp\gpresult.html ``` Bericht für einen bestimmten Benutzer: ```cmd gpresult /user \ /h C:\Temp\gpresult-benutzer.html ``` Ausführliche Textausgabe: ```cmd gpresult /z ``` Resultant Set of Policy: ```cmd rsop.msc ``` Im Bericht sind besonders zu prüfen: - angewendete GPOs, - abgelehnte GPOs, - Ablehnungsgrund, - Sicherheitsgruppen, - verwendeter Domänencontroller, - WMI-Filter, - Benutzer- und Computerbereich, - Loopbackmodus, - langsame Verbindung, - Verarbeitungszeit, - Fehler einzelner Erweiterungen. `gpresult` muss im passenden Benutzer- und Berechtigungskontext ausgeführt werden. Ein Bericht aus einem anderen Konto kann ein anderes Ergebnis zeigen. --- **20. Gruppenrichtlinien kontrolliert aktualisieren** Standardaktualisierung: ```cmd gpupdate ``` Erneute Verarbeitung aller Einstellungen: ```cmd gpupdate /force ``` Nur Computerrichtlinien: ```cmd gpupdate /target:computer /force ``` Nur Benutzerrichtlinien: ```cmd gpupdate /target:user /force ``` Eine erzwungene Aktualisierung kann: - zusätzliche Netz- und Serverlast verursachen, - erneut alle Richtlinienerweiterungen anstoßen, - Ab- oder Anmeldung verlangen, - einen Neustart verlangen, - laufende Benutzersitzungen beeinflussen. `gpupdate /force` ist ein Test beziehungsweise Auslöser, aber noch keine Ursachenanalyse. Danach müssen Ergebnisbericht und Ereignisprotokolle geprüft werden. --- **21. Gruppenrichtlinien-Ereignisse prüfen** Wichtiger Protokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational ``` PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-GroupPolicy/Operational' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich prüfen: - Systemprotokoll, - Anwendungsprotokoll, - DNS Client Events, - NETLOGON, - Kerberos, - Benutzerprofildienst, - einzelne Client Side Extensions. Nicht nur die Event-ID verwenden. Provider, vollständiger Text, Zeitpunkt, Benutzer, Computer und Verarbeitungsschritt müssen gemeinsam bewertet werden. --- **22. GPO-Verknüpfung und Filterung prüfen** In der Gruppenrichtlinienverwaltung sind zu kontrollieren: - richtige GPO, - richtige Verknüpfung, - richtige OU, - Link aktiviert, - GPO-Status, - Verknüpfungsreihenfolge, - Vererbung, - erzwungene Links, - Sicherheitsfilterung, - Delegierung, - WMI-Filter, - Benutzer- oder Computerteil, - GPO-Version, - Replikationsstatus. Sicherheitsfilterung benötigt grundsätzlich die passenden Berechtigungen zum Lesen und Anwenden der Gruppenrichtlinie. Typische Fehlinterpretation: > Ein Benutzer ist Mitglied einer Gruppe, die „Gruppenrichtlinie übernehmen“ besitzt. Im aktuellen Anmeldetoken fehlt diese neue Gruppenmitgliedschaft jedoch noch. Deshalb müssen AD-Mitgliedschaft und aktuelles Token getrennt geprüft werden. --- **23. Loopbackverarbeitung verstehen** Loopbackverarbeitung wird für Computer verwendet, bei denen die Benutzerumgebung vom verwendeten Computer abhängen soll, beispielsweise: - Schulungsräume, - Kiosksysteme, - Terminalserver, - gemeinsam verwendete Arbeitsplätze. Modi: | Modus | Wirkung | |---|---| | Zusammenführen | Benutzerrichtlinien des Benutzerobjekts werden verarbeitet, danach kommen die für den Computer ermittelten Benutzerrichtlinien hinzu | | Ersetzen | Benutzerrichtlinien des Benutzerobjekts werden durch die für den Computer ermittelten Benutzerrichtlinien ersetzt | Wenn Benutzereinstellungen nur auf bestimmten Computern unerwartet sind, muss Loopback geprüft werden. --- **24. Kerberos-Grundprinzip** Vereinfacht: ```text Benutzeranmeldung ↓ Authentication Service Request ↓ Ticket Granting Ticket ↓ Ticket Granting Service Request ↓ Dienstticket für einen SPN ↓ Zugriff auf den Zieldienst ``` Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | KDC | Key Distribution Center auf einem Domänencontroller | | TGT | Ticket Granting Ticket | | Dienstticket | Ticket für einen konkreten Dienst | | SPN | eindeutiger Dienstbezeichner eines Kontos | | Realm | Kerberos-Sicherheitsbereich, in AD meist zur Domäne zugeordnet | | PAC | enthält unter anderem Autorisierungsinformationen | | Delegierung | Weitergabe von Anmeldeinformationen unter definierten Bedingungen | Kerberos benötigt insbesondere: - funktionierende DNS-Auflösung, - erreichbaren KDC, - korrekte Zeit, - gültige Konten, - korrekte Kennwörter, - eindeutige SPNs, - einen zum Zielnamen passenden Dienstprinzipal. --- **25. Kerberos-Tickets prüfen** Tickets des aktuellen Anmeldekontexts: ```cmd klist ``` TGT anzeigen: ```cmd klist tgt ``` Zwischengespeicherte Tickets auflisten: ```cmd klist tickets ``` KDCs anzeigen: ```cmd klist query_bind ``` Zu prüfen sind: - Clientname, - Servername beziehungsweise SPN, - Kerberos-Realm, - Tickettyp, - Start- und Ablaufzeit, - Erneuerungszeit, - Verschlüsselungstyp, - Flags, - verwendeter KDC. Das Löschen des Ticketcaches verändert den Diagnosezustand: ```cmd klist purge ``` `klist purge` sollte erst eingesetzt werden, wenn: - vorhandene Tickets dokumentiert wurden, - klar ist, welcher Sicherheitskontext betroffen ist, - erneute Authentifizierung möglich ist, - keine kritische Sitzung unterbrochen wird, - der Test gezielt ein neues Ticket anfordern soll. Nach dem Löschen kann ein erneuter Zugriff auf die Zielressource ein neues Ticket auslösen. --- **26. Service Principal Names prüfen** SPNs eines Kontos anzeigen: ```cmd setspn -L ``` Bestimmten SPN suchen: ```cmd setspn -Q / ``` Beispiel: ```cmd setspn -Q HTTP\webserver.ad.example.local ``` Doppelte SPNs domänen- beziehungsweise gesamtstrukturweit suchen: ```cmd setspn -X ``` Mögliche SPN-Probleme: - SPN fehlt, - SPN ist dem falschen Konto zugeordnet, - SPN ist doppelt vorhanden, - Client verwendet Alias statt registriertem Hostnamen, - Dienstkonto wurde geändert, - Server wurde umbenannt, - Dienst läuft unter anderem Konto als erwartet, - alter SPN blieb nach Migration erhalten. SPNs dürfen nicht ohne vorherige Suche, Dokumentation und Prüfung verändert werden. Ein falsches Entfernen kann andere Dienste oder Benutzer beeinträchtigen. --- **27. Kerberos und NTLM unterscheiden** Anmeldesitzungen: ```cmd klist sessions ``` Tickets: ```cmd klist ``` Für bestimmte Verbindungen können zusätzlich Ereignisprotokolle, Dienstprotokolle oder geeignete Netzwerkaufzeichnungen erforderlich sein. Mögliche Hinweise auf NTLM statt Kerberos: - kein passendes Dienstticket vorhanden, - Zugriff erfolgt über IP-Adresse, - SPN für den verwendeten Namen fehlt, - Ziel befindet sich außerhalb der Kerberos-Vertrauensbeziehung, - Anwendung fordert ausdrücklich NTLM, - DNS- oder Namensproblem, - Kerberos-Anforderung schlägt fehl und ein Fallback ist möglich. Ein funktionierender Zugriff beweist deshalb nicht automatisch, dass Kerberos verwendet wurde. --- **28. Zugriff über IP-Adresse und Hostname vergleichen** Beispiel: ```text \\192.0.2.10\Freigabe \\server01\Freigabe \\server01.ad.example.local\Freigabe ``` Unterschiedliche Ergebnisse können auf Folgendes hinweisen: - DNS-Problem, - Alias-Problem, - SPN-Problem, - Kerberos funktioniert nur für einen bestimmten Namen, - Zertifikat passt nicht zum verwendeten Namen, - Anwendung verwendet unterschiedliche Sicherheitszonen, - IPv4 und IPv6 führen zu unterschiedlichen Zielen. Der Zugriff per IP-Adresse ist kein allgemeiner Ersatz für korrekte Namensauflösung. Bei Kerberos ist der verwendete Zielname für die SPN-Zuordnung entscheidend. --- **29. Kerberos-Ereignisse untersuchen** Relevante Protokolle können sein: - Sicherheitsprotokoll auf Client, Server und DC, - Systemprotokoll, - Kerberos-Key-Distribution-Center-Protokoll, - NETLOGON-Protokoll, - dienstspezifische Protokolle. PowerShell-Beispiel für aktuelle Sicherheitsereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Security' StartTime = (Get-Date).AddHours(-2) } | Where-Object { $_.Id -in 4768, 4769, 4771, 4776 } | Select-Object TimeCreated, Id, Message ``` Typische Ereigniskategorien: | Kategorie | Mögliche Bedeutung | |---|---| | TGT wurde angefordert | Benutzer- oder Computerauthentifizierung | | Dienstticket wurde angefordert | Zugriff auf einen bestimmten SPN | | Kerberos-Vorauthentifizierung fehlgeschlagen | Kennwort, Zeit, Kontostatus oder anderer Authentifizierungsfehler | | Anmeldeinformationen wurden validiert | häufig NTLM-bezogene Prüfung | | Kontosperrung | wiederholte fehlerhafte Authentifizierung | Event-IDs müssen mit dem vollständigen Ereignistext und dem jeweiligen System ausgewertet werden. --- **30. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Domäne kann nicht gefunden werden | DNS oder DC-Erreichbarkeit | `ipconfig /all`, SRV-Abfrage, `nltest /dsgetdc` | | Anmeldung funktioniert offline, aber nicht im Firmennetz | DC-, DNS-, Zeit- oder Secure-Channel-Problem | DC-Suche, Zeit und Secure Channel | | Vertrauensstellung fehlgeschlagen | Computerkennwort oder Computerkonto inkonsistent | `Test-ComputerSecureChannel`, Replikation | | neues Kennwort funktioniert nur manchmal | unterschiedliche DC-Daten | verwendeten DC und Replikation prüfen | | Benutzer bleibt trotz Entsperrung gesperrt | gespeicherte alte Anmeldedaten | Sperrquelle und Sicherheitsereignisse | | GPO wird nicht angezeigt | falsche OU, Filterung oder Link | `gpresult`, GPMC | | GPO wird angezeigt, Einstellung fehlt | Überschreibung oder Erweiterungsfehler | Detailbericht und GroupPolicy-Protokoll | | Computerrichtlinie fehlt | Computerobjekt, Neustart oder Computerbereich | `gpresult /scope computer` | | Benutzerrichtlinie fehlt | Benutzerobjekt, Token oder Benutzerbereich | `gpresult /scope user` | | GPO funktioniert nur an einem Standort nicht | Site, DC, Replikation oder Netzwerk | DC-Zuordnung und Replikation | | SYSVOL nicht erreichbar | DNS, SMB, DC oder DFSR | Port 445, Freigabe und DC-Protokolle | | Kerberos-Ticket fehlt | SPN, DNS, KDC oder Anwendung | `klist`, `setspn -Q` | | Kerberos scheitert nur über Alias | fehlender SPN für Alias | verwendeten Namen und SPN prüfen | | Zugriff funktioniert per IP, nicht per Name | DNS, SPN oder Zertifikat | Namen einzeln prüfen | | Zugriff funktioniert per Name, nicht per IP | Kerberos- oder Anwendungsanforderung | Ticket und Zielkonfiguration | | Dienst funktioniert nur mit NTLM | SPN oder Delegierung | Dienstkonto und SPNs | | Replikation meldet RPC-Fehler | DNS, Firewall, RPC oder Partner offline | Namensauflösung und Ports | | Benutzer hat neue Gruppe, aber keinen Zugriff | altes Anmeldetoken | `whoami /groups`, erneute Anmeldung | | Fehler nur auf einem Client | lokaler DNS-, Cache-, Konto- oder Profilfehler | Vergleichsclient und lokale Konfiguration | | Fehler auf vielen Clients | zentrale AD-, DNS-, GPO- oder Netzwerkstörung | DCs, Replikation und Änderungen | | Fehler nach VM-Snapshot | Secure Channel oder Zeit zurückgesetzt | Zeit, Computerkonto und Secure Channel | --- **31. Vorgehensweise bei einer nicht angewendeten GPO** 1. Betroffenen Benutzer und Computer bestimmen. 2. Prüfen, ob Benutzer- und Computerobjekt in den erwarteten OUs liegen. 3. Verwendeten Domänencontroller dokumentieren. 4. DNS- und DC-Erreichbarkeit prüfen. 5. SYSVOL-Zugriff prüfen. 6. `gpresult` als HTML-Bericht erstellen. 7. angewendete und abgelehnte GPOs prüfen. 8. Sicherheitsfilterung und WMI-Filter prüfen. 9. Verknüpfung, Reihenfolge und Vererbung prüfen. 10. Loopbackverarbeitung berücksichtigen. 11. GroupPolicy-Operational-Protokoll auswerten. 12. AD- und SYSVOL-Replikation prüfen. 13. genau eine kontrollierte Korrektur durchführen. 14. Richtlinien erneut verarbeiten. 15. Ergebnisbericht und Benutzerfunktion erneut prüfen. --- **32. Vorgehensweise bei einer fehlgeschlagenen Anmeldung** 1. Exakte Meldung und Zeitpunkt erfassen. 2. Lokale und Domänenanmeldung unterscheiden. 3. Netzwerkverbindung prüfen. 4. DNS-Server und DNS-Suffix prüfen. 5. Domänencontroller über SRV-Einträge suchen. 6. verwendeten DC bestimmen. 7. Zeit und Zeitquelle prüfen. 8. Benutzerkonto auf Sperre, Ablauf und Deaktivierung prüfen. 9. Secure Channel des Clients prüfen. 10. Replikationsstatus der DCs prüfen. 11. Sicherheits- und Kerberos-Ereignisse auswerten. 12. gespeicherte Anmeldedaten, Dienste und Aufgaben berücksichtigen. 13. genau eine Maßnahme durchführen. 14. Anmeldung und Ressourcenabruf erneut testen. --- **33. Vorgehensweise bei Kerberos-Problemen** 1. verwendeten Zielnamen dokumentieren. 2. DNS-Auflösung dieses Namens prüfen. 3. Zeit von Client, Server und DC vergleichen. 4. KDC beziehungsweise DC-Erreichbarkeit prüfen. 5. vorhandene Tickets mit `klist` dokumentieren. 6. nach passendem Dienstticket suchen. 7. erwarteten SPN bestimmen. 8. SPN mit `setspn -Q` suchen. 9. Dienstkonto und tatsächlichen Dienstprozess vergleichen. 10. doppelte SPNs prüfen. 11. Sicherheits- und Kerberos-Ereignisse korrelieren. 12. Vertrauensstellung und Delegierung berücksichtigen. 13. Ticketcache nur kontrolliert leeren. 14. Zugriff erneut auslösen. 15. neues Ticket und Funktion prüfen. --- **34. Maßnahmen und Rückwege** **Ursache: falscher DNS-Server am Client** Nachweis: - Client verwendet einen nicht zuständigen DNS-Server, - AD-SRV-Einträge werden nicht korrekt aufgelöst, - interner DNS-Server liefert die erwarteten Einträge. Maßnahme: - DNS-Konfiguration kontrolliert auf die vorgesehenen internen DNS-Server korrigieren. Rollback: - ursprüngliche Adapter- oder DHCP-Konfiguration dokumentiert wiederherstellen. Verifikation: - SRV-Abfrage, - DC-Suche, - Anmeldung, - GPO-Verarbeitung, - Anwendungszugriff. --- **Ursache: fehlerhafter Secure Channel** Nachweis: - Secure-Channel-Prüfung schlägt fehl, - Computerkonto ist vorhanden, - DNS, Zeit und DC-Erreichbarkeit funktionieren, - Replikation ist ausreichend gesund. Maßnahme: - Secure Channel mit berechtigtem Konto kontrolliert reparieren. Rollback: - vorab dokumentierte Computer- und Domänenkonfiguration verwenden; - bei Fehlschlag nach freigegebenem Wiederherstellungsverfahren vorgehen. Verifikation: - Secure Channel erneut prüfen, - Neustart oder Anmeldung testen, - Gruppenrichtlinien und Ressourcen testen. --- **Ursache: GPO durch Sicherheitsfilterung ausgeschlossen** Nachweis: - `gpresult` nennt die GPO als abgelehnt, - Benutzer oder Computer besitzt nicht die erforderlichen Berechtigungen. Maßnahme: - Sicherheitsfilterung nach dem Minimalprinzip korrigieren. Rollback: - ursprüngliche ACL beziehungsweise Gruppenmitgliedschaft wiederherstellen. Verifikation: - neues Token berücksichtigen, - GPO aktualisieren, - `gpresult` erneut erzeugen, - konkrete Einstellung prüfen. --- **Ursache: doppelter SPN** Nachweis: - `setspn -Q` oder `setspn -X` zeigt den SPN mehrfach, - Kerberos-Ereignisse passen zum Fehler, - Dienstkonto und Zielname wurden bestätigt. Maßnahme: - falsche SPN-Zuordnung nach Freigabe entfernen und korrekte eindeutige Zuordnung sicherstellen. Rollback: - vorherige SPN-Zuordnungen vollständig dokumentieren. Verifikation: - neue Tickets anfordern, - Dienstticket prüfen, - Zugriff mit vorgesehenem Namen testen. --- **Ursache: AD-Replikationsfehler** Nachweis: - `repadmin` oder PowerShell zeigt konkrete Fehler, - betroffene Objekte oder Kennwörter unterscheiden sich zwischen DCs, - Fehlercode und Abhängigkeit wurden bestimmt. Maßnahme: - zugrunde liegendes DNS-, Netzwerk-, RPC-, Zeit-, Authentifizierungs- oder DC-Problem beheben. Rollback: - abhängig von der konkreten Änderung; - keine erzwungene Replikations- oder Metadatenbereinigung ohne Wiederherstellungsplan. Verifikation: - `repadmin /replsummary`, - `repadmin /showrepl`, - Objektvergleich, - Anmeldung und GPO-Verarbeitung. --- **35. Nachkontrolle** Nach jeder Maßnahme sind mindestens folgende Punkte erneut zu prüfen: - Client verwendet die vorgesehenen DNS-Server. - AD-SRV-Einträge werden korrekt aufgelöst. - vorgesehene Domänencontroller sind erreichbar. - Zeit und Zeitquelle sind plausibel. - Secure Channel funktioniert. - Benutzer- und Computerkonto sind aktiv. - Replikation zeigt keine zum Fehler gehörenden Störungen. - SYSVOL und NETLOGON sind erreichbar. - benötigte Gruppenmitgliedschaften sind im aktuellen Token enthalten. - erwartete GPOs werden angewendet. - abgelehnte GPOs sind fachlich erklärbar. - Gruppenrichtlinienprotokoll zeigt keine neuen relevanten Fehler. - erforderliches Kerberos-Ticket wird ausgestellt. - SPN ist eindeutig und dem richtigen Konto zugeordnet. - Benutzerfunktion wurde praktisch getestet. - keine unnötigen Berechtigungen wurden vergeben. - temporäre Diagnose- oder Protokollierungsfunktionen wurden beendet. - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **36. Dokumentationsbeispiel** ```text Symptom: Die Laufwerkszuordnung aus der Gruppenrichtlinie wurde auf einem Client nicht erstellt. Zeitpunkt: 02.08.2026, 10:18 Uhr MESZ Betroffener Benutzer: max.mustermann Betroffener Computer: CLIENT-17 Verwendeter Domänencontroller: DC02.ad.example.local Nachweis: DNS-Auflösung, Zeit und SYSVOL-Zugriff waren erfolgreich. Der gpresult-Bericht zeigte die GPO als abgelehnt. Als Ablehnungsgrund wurde die Sicherheitsfilterung angegeben. Die erforderliche Benutzergruppe war im Active Directory eingetragen, fehlte aber im aktuellen Anmeldetoken. Ursache: Die Gruppenmitgliedschaft wurde erst nach Beginn der bestehenden Benutzersitzung hinzugefügt. Maßnahme: Der Benutzer meldete sich kontrolliert ab und erneut an. An der GPO und ihren Berechtigungen wurde nichts verändert. Rollback: Nicht erforderlich, da keine Konfiguration geändert wurde. Verifikation: whoami /groups zeigt die vorgesehene Gruppe. gpresult zeigt die angewendete GPO. Das Laufwerk wurde verbunden. Keine neuen Fehler im GroupPolicy-Protokoll. Prävention: Bei Änderungen an Gruppenmitgliedschaften wird künftig berücksichtigt, dass bestehende Anmeldetoken nicht automatisch vollständig erneuert werden. ``` --- **37. Entscheidungsbaum** ```text Domänenanmeldung, GPO oder Ressourcenzugriff gestört ↓ Stimmen IP-Konfiguration und interne DNS-Server? ├── Nein │ ↓ │ Netzwerk- und DNS-Konfiguration korrigieren │ └── Ja ↓ Werden AD-SRV-Einträge und DCs gefunden? ├── Nein │ ↓ │ DNS-Zone, SRV-Einträge und DC-Dienste prüfen │ └── Ja ↓ Sind DC und benötigte Ports erreichbar? ├── Nein │ ↓ │ Routing, Firewall, Standort und Dienste prüfen │ └── Ja ↓ Stimmen Zeit und Secure Channel? ├── Nein │ ↓ │ Zeitquelle oder Vertrauensbeziehung untersuchen │ └── Ja ↓ Ist die AD-Replikation fehlerfrei? ├── Nein │ ↓ │ Replikationsfehler nach Code und Richtung analysieren │ └── Ja ↓ Betrifft der Fehler Gruppenrichtlinien? ├── Ja │ ↓ │ gpresult, SYSVOL, Filter, OU und Ereignisse prüfen │ └── Nein ↓ Betrifft der Fehler Kerberos oder einen Dienst? ├── Ja │ ↓ │ Tickets, SPNs, Zielname und Dienstkonto prüfen │ └── Nein ↓ Konto, Gruppen, Berechtigungen und Anwendung untersuchen ``` --- **38. Typische Prüfungsfragen** **Warum ist DNS für Active Directory besonders wichtig?**
Antwort anzeigen Active Directory verwendet DNS und insbesondere SRV-Einträge, damit Clients Domänencontroller, Kerberos-Dienste und Global Catalogs finden. Eine reine Auflösung externer Internetnamen reicht für eine funktionierende Domänenumgebung nicht aus.
**Warum kann ein neues Kennwort an einem Client funktionieren und an einem anderen nicht?**
Antwort anzeigen Die Clients können unterschiedliche Domänencontroller verwenden. Bei einer Replikationsstörung ist das neue Kennwort möglicherweise noch nicht auf allen benötigten Domänencontrollern verfügbar.
**Wozu dient `gpresult`?**
Antwort anzeigen `gpresult` zeigt die resultierenden Gruppenrichtlinien für einen Benutzer oder Computer. Es kann angewendete und abgelehnte GPOs, Sicherheitsgruppen, Filter und weitere Verarbeitungsinformationen darstellen.
**Warum ist `gpupdate /force` noch keine Fehlerbehebung?**
Antwort anzeigen Der Befehl löst eine erneute Verarbeitung der Gruppenrichtlinien aus. Er erklärt jedoch nicht, warum eine GPO zuvor nicht angewendet wurde. Dafür müssen Ergebnisbericht, Ereignisse, Filterung, Verknüpfung und Abhängigkeiten geprüft werden.
**Warum kann eine neue Gruppenmitgliedschaft trotz korrektem AD-Eintrag noch wirkungslos sein?**
Antwort anzeigen Das aktuelle Anmeldetoken wurde möglicherweise vor der Gruppenänderung erzeugt. Die neue Mitgliedschaft ist dann noch nicht im Token enthalten und wird häufig erst nach erneuter Anmeldung wirksam.
**Welche drei grundlegenden Abhängigkeiten benötigt Kerberos besonders?**
Antwort anzeigen Kerberos benötigt insbesondere funktionierende DNS-Auflösung, ausreichend genaue Zeitsynchronisation und korrekte beziehungsweise eindeutige Dienstidentitäten in Form von SPNs.
**Was ist ein SPN?**
Antwort anzeigen Ein Service Principal Name identifiziert eine konkrete Dienstinstanz und ist einem Active-Directory-Konto zugeordnet. Der KDC verwendet ihn, um ein Dienstticket für den richtigen Dienst auszustellen.
**Warum kann ein doppelter SPN die Kerberos-Authentifizierung verhindern?**
Antwort anzeigen Der KDC kann den Dienst nicht eindeutig einem Konto zuordnen. Dadurch kann kein korrektes Dienstticket für die erwartete Dienstidentität ausgestellt werden.
**Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?**
Antwort anzeigen Dadurch wird der für die Diagnose wichtige Zustand verändert. Außerdem kann die Maßnahme zusätzliche Probleme mit Computerkonto, Profilen, Berechtigungen, Zertifikaten und verwalteter Konfiguration erzeugen.
**Worin unterscheiden sich AD- und SYSVOL-Replikation bei einer GPO?**
Antwort anzeigen Der Group Policy Container mit den Verzeichnisinformationen liegt im Active Directory. Das Group Policy Template mit den dateibasierten Richtlinieninhalten liegt in SYSVOL. Beide Bestandteile müssen verfügbar und konsistent sein.
--- **39. Prüfungsfallen** - öffentlichen DNS-Server auf einem Domänenmitglied eintragen. - erfolgreichen Ping als Nachweis für funktionierendes Active Directory bewerten. - nur den A-Eintrag, aber keine SRV-Einträge prüfen. - IP-Erreichbarkeit mit funktionierender Authentifizierung gleichsetzen. - Zeitabweichung übersehen. - Domänencontroller und DNS-Server ungeprüft neu starten. - Computer sofort aus der Domäne entfernen. - Computerkonto ohne Sicherung löschen. - Secure Channel reparieren, obwohl DNS oder Replikation gestört ist. - Gruppenmitgliedschaft im AD mit dem aktuellen Token gleichsetzen. - Benutzer wegen fehlender Berechtigung in eine weitreichende Administratorgruppe aufnehmen. - `gpupdate /force` als alleinige Fehleranalyse verwenden. - Benutzer- und Computerrichtlinien verwechseln. - falschen Benutzerkontext für `gpresult` verwenden. - OU des Benutzers prüfen, obwohl eine Computerrichtlinie betroffen ist. - Sicherheitsfilterung, WMI-Filter oder Loopback übersehen. - GPO löschen, statt Verknüpfung und Filterung zu untersuchen. - SYSVOL-Zugriff nicht prüfen. - AD-Replikation prüfen, aber SYSVOL-Replikation übersehen. - Replikation ungeprüft erzwingen. - einzelne `dcdiag`-Warnung ohne Zusammenhang als Ursache bewerten. - Event-ID ohne Provider und vollständigen Text interpretieren. - Kerberos und NTLM nicht unterscheiden. - Zugriff per IP-Adresse als dauerhafte Lösung verwenden. - Ticketcache vor der Dokumentation löschen. - SPN ohne vorherige Suche verändern. - gültigen SPN dem falschen Dienstkonto zuordnen. - doppelten SPN ungeprüft entfernen. - mehrere Änderungen gleichzeitig durchführen. - nach einer Maßnahme weder Ticket noch GPO-Ergebnis erneut prüfen. - keine praktische Benutzerfunktion testen. --- **40. Checkliste** - [ ] exakter Fehlertext wurde dokumentiert. - [ ] Fehlerzeitpunkt und Zeitzone wurden erfasst. - [ ] betroffener Benutzer wurde bestimmt. - [ ] betroffener Computer wurde bestimmt. - [ ] betroffener Zielserver oder Dienst wurde bestimmt. - [ ] lokale und Domänenanmeldung wurden unterschieden. - [ ] IP-Konfiguration wurde geprüft. - [ ] vorgesehene interne DNS-Server werden verwendet. - [ ] DNS-Suffix wurde geprüft. - [ ] AD-SRV-Einträge wurden geprüft. - [ ] verwendeter Domänencontroller wurde bestimmt. - [ ] Standort beziehungsweise AD-Site wurde berücksichtigt. - [ ] DC-Erreichbarkeit wurde geprüft. - [ ] benötigte Ports wurden geprüft. - [ ] SYSVOL wurde geprüft. - [ ] NETLOGON wurde geprüft. - [ ] Zeit und Zeitzone wurden geprüft. - [ ] Zeitquelle wurde geprüft. - [ ] Secure Channel wurde geprüft. - [ ] Benutzerkonto wurde auf Sperre und Ablauf geprüft. - [ ] Computerkonto wurde geprüft. - [ ] AD-Gruppenmitgliedschaften wurden geprüft. - [ ] aktuelles Benutzertoken wurde geprüft. - [ ] AD-Replikation wurde geprüft. - [ ] letzter erfolgreicher Replikationszeitpunkt wurde dokumentiert. - [ ] Replikationsrichtung wurde berücksichtigt. - [ ] `dcdiag` wurde bei DC-Problemen ausgewertet. - [ ] FSMO-Rollen wurden bei passendem Fehlerbild geprüft. - [ ] Benutzer- und Computerrichtlinien wurden unterschieden. - [ ] `gpresult` wurde im richtigen Kontext erzeugt. - [ ] angewendete und abgelehnte GPOs wurden geprüft. - [ ] OU und GPO-Verknüpfung wurden geprüft. - [ ] Sicherheitsfilterung wurde geprüft. - [ ] WMI-Filter wurde geprüft. - [ ] Vererbung und Erzwingen wurden geprüft. - [ ] Loopbackverarbeitung wurde berücksichtigt. - [ ] GroupPolicy-Operational-Protokoll wurde geprüft. - [ ] vorhandene Kerberos-Tickets wurden dokumentiert. - [ ] verwendeter Zielname wurde dokumentiert. - [ ] benötigter SPN wurde bestimmt. - [ ] SPN-Zuordnung wurde geprüft. - [ ] doppelte SPNs wurden bei Bedarf gesucht. - [ ] Kerberos- und Sicherheitsereignisse wurden zeitlich korreliert. - [ ] letzte Änderungen wurden berücksichtigt. - [ ] funktionierender Vergleichsclient wurde verwendet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] Anmeldung wurde erneut getestet. - [ ] GPO-Ergebnis wurde erneut geprüft. - [ ] Kerberos-Ticket wurde erneut geprüft. - [ ] konkrete Benutzerfunktion wurde getestet. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. - [ ] vorbeugende Maßnahme wurde festgelegt. --- **41. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Domäne wird nicht gefunden | `ipconfig /all`, `nslookup`, `nltest /dsgetdc` | | falscher DNS-Server | Adapter-, DHCP- und DNS-Konfiguration | | DC wird nicht gefunden | SRV-Abfragen und `nltest` | | Anmeldung nur offline möglich | DC-Erreichbarkeit, Zeit, Secure Channel | | Vertrauensstellung fehlgeschlagen | `Test-ComputerSecureChannel`, `nltest` | | neues Kennwort funktioniert nicht überall | `repadmin`, verwendeten DC bestimmen | | Replikationsfehler | `repadmin /replsummary`, `repadmin /showrepl` | | DC-Zustand unklar | `dcdiag /v` | | DNS auf DC fehlerhaft | `dcdiag /test:dns /v` | | GPO fehlt | `gpresult`, GPMC | | GPO abgelehnt | `gpresult /h`, Sicherheitsfilterung | | GPO-Einstellung fehlt | Detailbericht und GroupPolicy-Protokoll | | SYSVOL nicht erreichbar | DNS, SMB-Port und Freigaben | | Gruppenänderung wirkt nicht | `whoami /groups`, erneute Anmeldung | | Konto wird wiederholt gesperrt | Sicherheitsprotokoll und gespeicherte Anmeldedaten | | Kerberos-Ticket fehlt | `klist`, DNS, Zeit | | Dienstticket fehlt | `klist`, `setspn -Q` | | doppelter SPN vermutet | `setspn -X` | | Fehler nur über Alias | DNS- und SPN-Zuordnung | | Zugriff nur über IP möglich | DNS, Zielname, SPN und Kerberos | | Fehler nur an einem Standort | AD-Site, DC-Auswahl und Replikation | | Fehler nur auf einem Client | lokale DNS-, Konto-, Token- oder Profilprüfung | --- **Merksatz** > Active-Directory-Fehler werden von unten nach oben analysiert: Netzwerk, DNS, Domänencontroller, Zeit, Secure Channel, Replikation, Konten, Gruppenrichtlinien und Kerberos. Erst wenn die Abhängigkeiten nachweislich funktionieren, wird die betroffene Richtlinie, Berechtigung oder Anwendung verändert. Jede Änderung benötigt einen Rückweg und eine erneute Funktionsprüfung. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – AD DS Troubleshooting](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) - [Microsoft Learn – Troubleshooting Active Directory Replication Problems](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems) - [Microsoft Learn – Diagnose Active Directory Replication Failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [Microsoft Learn – Active Directory Replication Error 1722](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replication-error-1722-rpc-server-unavailable) - [Microsoft Learn – Active Directory Replication Error 5](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replications-fail-with-error-5) - [Microsoft Learn – Group Policy Processing](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-processing) - [Microsoft Learn – Applying Group Policy Troubleshooting Guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance) - [Microsoft Learn – Kerberos Authentication Troubleshooting Guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance) - [Microsoft Learn – Domain Controller Is Not Functioning Correctly](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/domain-controller-not-functioning-correctly) - [Microsoft Learn – Repadmin](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11)) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Gpresult](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – Gpupdate](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate) - [Microsoft Learn – Klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – Setspn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setspn) - [Microsoft Learn – W32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Get-ADReplicationFailure](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationfailure) - [Microsoft Learn – Get-ADReplicationPartnerMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata)