7.10 Anmeldung an der Domäne funktioniert nicht

7.10.1 Ausgangssituation

Ein Benutzer kann sich an einem Windows-Computer nicht mit seinem Domänenkonto anmelden.

Mögliche Meldungen sind beispielsweise:

Der Benutzername oder das Kennwort ist falsch.

Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Wir können Sie mit diesen Anmeldeinformationen nicht anmelden, weil Ihre Domäne nicht verfügbar ist.

Der Sicherheitsdatenbank auf dem Server ist kein Computerkonto für diese Arbeitsstationsvertrauensstellung zugeordnet.

Der Benutzerprofildienst konnte die Anmeldung nicht durchführen.

Diese Meldungen beschreiben unterschiedliche Fehlerbereiche. Eine fehlgeschlagene Domänenanmeldung darf deshalb nicht automatisch auf ein falsches Kennwort reduziert werden.

7.10.2 Ziel der Diagnose

Die Diagnose soll eindeutig bestimmen, ob der Fehler verursacht wird durch:

Erst nach dem Nachweis der Ursache wird eine kontrollierte Maßnahme durchgeführt.

7.10.3 Geltungsbereich und Abgrenzung

Diese Seite behandelt hauptsächlich die Anmeldung eines Domänenbenutzers an einem Computer, der Mitglied einer lokalen Active-Directory-Domäne mit Active Directory Domain Services ist.

Davon zu unterscheiden sind:

Konto- oder Geräteart Kennzeichnung beziehungsweise Beispiel
lokales Konto .\MaxMustermann oder <Computername>\MaxMustermann
Active-Directory-Domänenkonto <NETBIOS-Domäne>\MaxMustermann
Active-Directory-UPN max.mustermann@<DNS-Domäne>
Microsoft-Entra-Konto häufig ebenfalls UPN-Format, aber cloudbasierte Identität
Microsoft-Konto persönliche Microsoft-Identität
Smartcard-Anmeldung zertifikatsbasierte Anmeldung
Windows Hello for Business schlüssel- oder zertifikatsbasierte Anmeldung
Remotedesktop-Anmeldung Anmeldung erfolgt am entfernten Zielsystem
Dienst- oder Aufgabenanmeldung nicht interaktiver Anmeldetyp

Ein Benutzername im Format benutzer@domäne beweist allein nicht, ob ein lokales Active Directory, Microsoft Entra ID oder ein anderer Identitätsanbieter verwendet wird.

Microsoft-Entra-Anmeldefehler, MFA und Conditional Access benötigen teilweise andere Diagnoseverfahren. Sie dürfen nicht mit einer klassischen AD-Domänenanmeldung gleichgesetzt werden.

7.10.4 Technischer Anmeldeweg

Eine normale Online-Domänenanmeldung benötigt mehrere funktionierende Ebenen:

  1. Der Benutzer wählt den richtigen Anmeldeanbieter.
  2. Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu.
  3. Der Computer besitzt eine geeignete Netzwerkverbindung.
  4. Der Client verwendet die vorgesehenen DNS-Server.
  5. DNS liefert die erforderlichen Domänen- und Dienstinformationen.
  6. DC Locator ermittelt einen geeigneten Domänencontroller.
  7. Die benötigten Netzwerkprotokolle erreichen den Domänencontroller.
  8. Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten.
  9. Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne.
  10. Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt.
  11. Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen.
  12. Kontorichtlinien und Anmelderechte werden ausgewertet.
  13. Windows erzeugt die Anmeldesitzung und das Zugriffstoken.
  14. Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet.
  15. Der Desktop beziehungsweise die vorgesehene Sitzung wird bereitgestellt.

Der sichtbare Fehler kann an jeder dieser Ebenen entstehen.

7.10.5 Zuerst die genaue Fehlerphase bestimmen

Fehlerphase Typische Beobachtung Wahrscheinlicher Bereich
vor Eingabe der Anmeldedaten Netzwerk- oder Anmeldeoption fehlt Client, Treiber, VPN oder Anmeldeanbieter
unmittelbar nach Eingabe Kennwort- oder Kontofehler Identität, Kennwort, Sperre oder Kontorichtlinie
längere Wartezeit vor Fehlermeldung kein DC, DNS, Netzwerk oder Timeout Infrastruktur und Erreichbarkeit
Meldung über Vertrauensstellung Computerkonto oder sicherer Kanal Computervertrauen
Anmeldung funktioniert offline, aber nicht online Cache oder unterschiedlicher DC-Zustand DNS, DC, Kennwort oder Replikation
Anmeldung wird akzeptiert, Desktop erscheint nicht Profil, Richtlinie, Skript oder Ressource Phase nach der Authentifizierung
temporäres Profil wird geladen Benutzerprofilproblem Profilpfad, Datenträger oder Profildienst
nur RDP schlägt fehl RDP, NLA, Anmelderecht oder Zielsystem entfernter Computer
PIN schlägt fehl, Kennwort funktioniert Windows Hello oder PIN-Anbieter Hello-Schlüssel, TPM oder Richtlinie
Smartcard schlägt fehl, Kennwort funktioniert Zertifikat oder PKI Smartcard, Zertifikatskette, KDC-Zertifikat oder Sperrprüfung

Eine erfolgreiche Kennwortprüfung bedeutet noch nicht, dass Benutzerprofil, Gruppenrichtlinien und Desktop erfolgreich geladen werden.

7.10.6 Beweise vor Änderungen sichern

Vor einem Neustart, einer Kennwortzurücksetzung, dem Entsperren eines Kontos oder einer Reparatur des sicheren Kanals sollten mindestens folgende Informationen gesichert werden:

Kennwörter, PINs, private Schlüssel, Wiederherstellungsschlüssel und vollständige Anmeldetoken dürfen nicht dokumentiert oder weitergegeben werden.

Wiederholte unkontrollierte Anmeldeversuche müssen vermieden werden, weil dadurch das Konto gesperrt werden kann.

7.10.7 Umfang des Fehlers bestimmen

Geeignete Kreuztests:

Vergleich Erkenntnis
gleicher Benutzer an anderem Domänencomputer benutzer- oder computerbezogenen Fehler unterscheiden
anderer Domänenbenutzer am gleichen Computer Benutzerkonto und Computerzustand unterscheiden
gleiches Konto mit und ohne VPN VPN-, DNS- oder Routingabhängigkeit erkennen
gleiches Konto an Konsole und per RDP lokale und entfernte Anmeldung unterscheiden
Kennwort statt PIN Windows-Hello-Fehler abgrenzen
Kennwort statt Smartcard Zertifikats- oder Smartcardfehler abgrenzen
lokales Administratorkonto Zugriff für die Clientdiagnose ermöglichen
Test gegen anderen Standort oder anderen DC standort- oder DC-bezogenen Fehler erkennen

Auswertung:

Ergebnis Wahrscheinlicher Bereich
nur ein Benutzer betroffen Benutzerkonto, Kennwort, Sperre oder Benutzerprofil
alle Benutzer an einem Computer betroffen Client, DNS, Netzwerk, Zeit oder sicherer Kanal
viele Computer betroffen DNS, DC, Netzwerk, Zeitdienst, Replikation oder zentrale Richtlinie
nur ein Standort betroffen Standortnetz, VPN, DNS, Firewall oder Standortzuordnung
nur ein Domänencontroller betroffen DC-Dienst, DNS-Registrierung, Replikation oder Zeit
nur neue Kennwörter betroffen Kennwortcache, Replikation oder gespeicherte alte Anmeldedaten
Authentifizierung funktioniert, Desktop nicht Profil, Gruppenrichtlinie, Skript oder Ressource

Ein Testkonto darf nur nach den organisatorischen Sicherheitsvorgaben verwendet werden.

7.10.8 Richtige Identität und Anmeldeoption prüfen

Am Anmeldebildschirm muss geprüft werden:

Beispiele:

<NETBIOS-Domäne>\MaxMustermann

max.mustermann@<DNS-Domäne>

.\MaxMustermann

Bedeutung:

NETBIOS-Domänenname und DNS-Domänenname müssen nicht identisch sein.

Ein lokaler Anmeldeerfolg beweist weder eine funktionierende Domänenverbindung noch ein gültiges Domänenkonto.

7.10.9 Bestehende Sitzung und Identität prüfen

Wenn noch eine bestehende Sitzung verfügbar ist:

whoami
whoami /user
whoami /fqdn
whoami /groups

In PowerShell:

$env:USERDOMAIN
$env:USERDNSDOMAIN
$env:LOGONSERVER

Wichtige Einschränkungen:

7.10.10 Domänenmitgliedschaft des Computers prüfen

Mit einem autorisierten lokalen Konto oder einer noch verfügbaren Administrationssitzung:

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, PartOfDomain, Domain, Workgroup

Erwartet wird:

PartOfDomain : True
Domain       : <DNS-Domäne>

Zusätzlich:

systeminfo

Relevante Felder sind:

Domäne
Anmeldeserver

Zu prüfen sind:

PartOfDomain : True beweist nur die lokale Mitgliedschaftskonfiguration. Es beweist nicht, dass der sichere Kanal aktuell funktioniert.

7.10.11 Online-Anmeldung und zwischengespeicherte Domänenanmeldung unterscheiden

Windows kann Informationen früherer Domänenanmeldungen lokal zwischenspeichern. Dadurch kann sich ein Benutzer unter bestimmten Voraussetzungen anmelden, obwohl kein Domänencontroller erreichbar ist.

Eine zwischengespeicherte Anmeldung beweist nicht:

Wurde das Kennwort an einem anderen Computer geändert, kann ein offline verwendeter Client weiterhin den früher zwischengespeicherten Kennwortnachweis erwarten. Erst eine erfolgreiche Online-Anmeldung kann den lokalen Anmeldecache aktualisieren.

Die Anzahl zwischengespeicherter eindeutiger Benutzer wird durch die Sicherheitsrichtlinie bestimmt:

Computerkonfiguration
└── Windows-Einstellungen
    └── Sicherheitseinstellungen
        └── Lokale Richtlinien
            └── Sicherheitsoptionen
                └── Interaktive Anmeldung:
                   Anzahl zwischenzuspeichernder vorheriger Anmeldungen

Der genaue Wert ist eine Sicherheitsentscheidung der Organisation. Er darf nicht nur zur Fehlerumgehung verändert werden.

Typische Unterscheidung:

Verhalten Einordnung
Anmeldung ohne Netzwerk funktioniert Cache-Anmeldung möglich
Anmeldung mit Netzwerk schlägt fehl Online-Authentifizierung oder anderer DC-Zustand fehlerhaft
altes Kennwort funktioniert offline lokaler Cache kann noch den alten Nachweis enthalten
neues Kennwort funktioniert online DC kennt das neue Kennwort
neues Kennwort funktioniert an einem Gerät, an anderem nicht Cache, DC-Auswahl oder Replikation prüfen
noch nie auf diesem Computer angemeldeter Benutzer kann offline nicht anmelden kein passender lokaler Anmeldecache vorhanden

7.10.12 Netzwerkzustand des Clients prüfen

Get-NetAdapter |
  Select-Object Name, Status, LinkSpeed, MacAddress

Get-NetIPConfiguration

ipconfig /all

Zu dokumentieren sind:

Ein Ping zum Gateway oder zu einem DC ist nur ein Teilnachweis. Die Domänenanmeldung benötigt DNS, DC Locator und mehrere Anwendungsprotokolle.

Bei einer Anmeldung außerhalb des Unternehmensnetzes ist zu prüfen, ob eine Anmeldung vor dem Windows-Desktop überhaupt eine VPN-Verbindung herstellen kann. Ein VPN, das erst nach der Benutzeranmeldung startet, kann keine erstmalige Online-Domänenanmeldung ermöglichen.

7.10.13 DNS-Konfiguration prüfen

Active Directory ist auf DNS-basierte Diensterkennung angewiesen. Der Client sollte die für die AD-Domäne vorgesehenen DNS-Server verwenden.

DNS-Server anzeigen:

Get-DnsClientServerAddress |
  Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Domänenname prüfen:

Resolve-DnsName -Name <DNS-Domäne> -Type A

Domänencontroller-Dienst prüfen:

Resolve-DnsName `
  -Name _ldap._tcp.dc._msdcs.<DNS-Domäne> `
  -Type SRV

Kerberos-Dienst prüfen:

Resolve-DnsName `
  -Name _kerberos._tcp.<DNS-Domäne> `
  -Type SRV

Einen bestimmten DNS-Server verwenden:

Resolve-DnsName `
  -Name _ldap._tcp.dc._msdcs.<DNS-Domäne> `
  -Type SRV `
  -Server <DNS-Server>

Zu prüfen sind:

Öffentliche Resolver kennen die internen Active-Directory-Dienstinformationen normalerweise nicht. Ein zusätzlich eingetragener öffentlicher DNS-Server ist kein zuverlässiger Ersatz für den vorgesehenen AD-DNS-Server.

DNS-Caches sollten nicht sofort gelöscht werden. Zuerst müssen aktuelle Antworten, DNS-Server und die verwendete Zieladresse dokumentiert werden.

7.10.14 Domänencontroller-Ermittlung prüfen

Windows verwendet DC Locator und den Netlogon-Dienst, um über DNS-SRV-Einträge einen geeigneten Domänencontroller zu finden.

nltest /dsgetdc:<DNS-Domäne>

Erneute DNS-basierte Ermittlung ohne den bisherigen DC-Cache:

nltest /dsgetdc:<DNS-Domäne> /force

Nur einen beschreibbaren DC anfordern:

nltest /dsgetdc:<DNS-Domäne> /writable /force

Lokalen AD-Standort anzeigen:

nltest /dsgetsite

Bekannte Domänencontroller auflisten:

nltest /dclist:<DNS-Domäne>

In der Ausgabe von nltest /dsgetdc sind unter anderem wichtig:

DC
Address
Domain Name
Forest Name
Dc Site Name
Our Site Name
Flags

Auswertung:

Ergebnis Bedeutung
geeigneter DC wird gefunden DC Locator war für diesen Versuch erfolgreich
ERROR_NO_SUCH_DOMAIN Domäne oder DC konnte nicht gefunden werden
falscher Standort Subnetz- oder Standortzuordnung prüfen
alter DC wird geliefert DNS-Registrierung und AD-Metadaten prüfen
nur ein entfernter DC wird gefunden lokaler DC, Standort oder DNS möglicherweise fehlerhaft
DC wird gefunden, Anmeldung scheitert trotzdem Erreichbarkeit, Zeit, Konto, sicherer Kanal und Protokoll prüfen

Ein erfolgreiches nltest /dsgetdc beweist nicht, dass alle für die Anmeldung benötigten Protokolle funktionieren.

7.10.15 Erreichbarkeit der benötigten Dienste prüfen

Grundlegende TCP-Tests:

Test-NetConnection -ComputerName <DC-FQDN> -Port 53
Test-NetConnection -ComputerName <DC-FQDN> -Port 88
Test-NetConnection -ComputerName <DC-FQDN> -Port 135
Test-NetConnection -ComputerName <DC-FQDN> -Port 389
Test-NetConnection -ComputerName <DC-FQDN> -Port 445

Je nach Funktion zusätzlich:

Test-NetConnection -ComputerName <DC-FQDN> -Port 464
Test-NetConnection -ComputerName <DC-FQDN> -Port 3268
Test-NetConnection -ComputerName <DC-FQDN> -Port 636
Test-NetConnection -ComputerName <DC-FQDN> -Port 3269

Wichtige AD-Protokolle:

Dienst Protokoll und Port Bedeutung
DNS TCP/UDP 53 Namens- und Dienstauflösung
Kerberos TCP/UDP 88 Kerberos-Authentifizierung
Windows-Zeit UDP 123 Zeitsynchronisation
RPC Endpoint Mapper TCP 135 RPC-Endpunktermittlung
LDAP TCP 389 Verzeichniszugriff
DC Locator UDP 389 DC-Ermittlung
SMB TCP 445 Netlogon, SYSVOL und Gruppenrichtlinien
Kerberos-Kennwortdienst TCP/UDP 464 Kennwortänderungen
Global Catalog TCP 3268 gesamtstrukturweite Abfragen
LDAPS TCP 636 LDAP über TLS, sofern verwendet
Global Catalog über TLS TCP 3269 GC über TLS, sofern verwendet
dynamische RPC-Ports üblicherweise TCP 49152–65535 bei modernen Windows-Versionen ausgehandelte RPC-Verbindungen

Wichtige Einschränkungen:

Firewalls dürfen nicht pauschal deaktiviert werden. Die konkrete Regel muss anhand von Quelle, Ziel, Protokoll, Port, Richtung und Zeitstempel geprüft werden.

7.10.16 Zeit und Zeitsynchronisation prüfen

Kerberos benötigt ausreichend synchronisierte Uhrzeiten. Die standardmäßige maximale Kerberos-Zeitabweichung beträgt in vielen AD-Umgebungen fünf Minuten, kann aber durch Richtlinien verändert werden.

Clientstatus:

w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Zeitabweichung zu einem DC beobachten:

w32tm /stripchart /computer:<DC-FQDN> /dataonly /samples:5

Zusätzlich zu prüfen:

Get-Service W32Time

Zu vergleichen sind:

Eine richtige Bildschirmanzeige allein beweist keine korrekte Zeitkonfiguration. Zeitzone, UTC-Zeit, Zeitquelle und tatsächliche Abweichung müssen getrennt betrachtet werden.

Eine Resynchronisation ist eine Änderung und sollte erst nach Dokumentation der bisherigen Quelle und Abweichung erfolgen:

w32tm /resync /rediscover

Danach müssen Quelle, Status und Abweichung erneut geprüft werden.

7.10.17 Benutzerkonto prüfen

Mit dem ActiveDirectory-PowerShell-Modul und ausreichender Leseberechtigung:

Get-ADUser `
  -Identity "<Benutzername>" `
  -Properties Enabled,
              LockedOut,
              PasswordExpired,
              AccountExpirationDate,
              PasswordLastSet,
              LastBadPasswordAttempt,
              BadLogonCount,
              LogonWorkstations |
  Select-Object SamAccountName,
                UserPrincipalName,
                Enabled,
                LockedOut,
                PasswordExpired,
                AccountExpirationDate,
                PasswordLastSet,
                LastBadPasswordAttempt,
                BadLogonCount,
                LogonWorkstations

Ergebnisbezogene Kennwortrichtlinie prüfen:

Get-ADUserResultantPasswordPolicy `
  -Identity "<Benutzername>"

Gezielte Suchbefehle:

Search-ADAccount -LockedOut -UsersOnly
Search-ADAccount -AccountDisabled -UsersOnly
Search-ADAccount -AccountExpired -UsersOnly
Search-ADAccount -PasswordExpired -UsersOnly

Alternativ mit integrierten Werkzeugen:

net user <Benutzername> /domain

Zu prüfen sind:

BadLogonCount, LastBadPasswordAttempt und ähnliche Werte können DC-abhängig sein. Sie dürfen nicht ohne Berücksichtigung des abgefragten Domänencontrollers und der Replikation interpretiert werden.

Ein Konto sollte nicht vorsorglich entsperrt oder dessen Kennwort zurückgesetzt werden, bevor die Quelle fehlerhafter Anmeldeversuche untersucht wurde. Gespeicherte alte Kennwörter in Diensten, Aufgaben, Mobilgeräten oder Anwendungen können das Konto sofort erneut sperren.

7.10.18 Kennwortfehler systematisch abgrenzen

Mögliche Ursachen trotz scheinbar richtiger Eingabe:

Ein administratives Zurücksetzen des Kennworts kann Auswirkungen auf verschlüsselte benutzerbezogene Daten, gespeicherte Anmeldeinformationen und Zertifikatsschlüssel besitzen. Es muss nach dem vorgesehenen Identitäts- und Wiederherstellungsverfahren erfolgen.

7.10.19 Sicheren Kanal des Computers prüfen

Domänencomputer und Domäne besitzen eine Vertrauensbeziehung auf Grundlage des Computerkontos und eines Computerkennworts. Stimmen der lokale und der in Active Directory gespeicherte Zustand nicht mehr überein, kann der sichere Kanal fehlschlagen.

Typische Meldung:

Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Nur prüfen:

powershell

Test-ComputerSecureChannel -Verbose


Erwartetes Ergebnis:

```text
True

Ein bestimmter DC kann für den Test angegeben werden:

Test-ComputerSecureChannel `
  -Server "<DC-FQDN>" `
  -Verbose

Status des zuletzt verwendeten Netlogon-Kanals anzeigen:

nltest /sc_query:<DNS-Domäne>

Wichtige Einschränkungen:

Mögliche Ursachen eines defekten sicheren Kanals:

Ein defekter sicherer Kanal ist ein konkreter Befund. Der Computer sollte nicht vorsorglich aus der Domäne entfernt werden.

7.10.20 Kerberos und NTLM unterscheiden

Windows verwendet häufig das Aushandlungspaket Negotiate. Dieses wählt nach Möglichkeit Kerberos und kann unter bestimmten Bedingungen NTLM verwenden.

Kerberos benötigt unter anderem:

NTLM benötigt ebenfalls einen erreichbaren zuständigen Authentifizierungsserver und darf nicht als automatische oder dauerhafte Lösung für Kerberos-Probleme betrachtet werden.

Ein erfolgreicher NTLM-Versuch beweist nicht, dass Kerberos funktioniert. Ein Fehlschlag bei Kerberos darf nicht ungeprüft durch Lockerung der Sicherheitsrichtlinien oder dauerhafte Aktivierung veralteter Verfahren umgangen werden.

7.10.21 Kerberos-Tickets prüfen

In einer bestehenden Domänensitzung:

klist

TGT anzeigen:

klist tgt

Alle Tickets der aktuellen Sitzung anzeigen:

klist tickets

Zu prüfen sind:

klist purge löscht Kerberos-Tickets der angegebenen Anmeldesitzung und ist daher keine rein lesende Diagnose:

klist purge

Mögliche Auswirkungen:

Tickets sollten deshalb zuerst dokumentiert und nur im Rahmen eines kontrollierten Tests gelöscht werden.

Eine fehlgeschlagene interaktive Anmeldung besitzt möglicherweise noch keine normale Benutzersitzung, in der klist ausgeführt werden kann. In diesem Fall sind die Ereignisse auf dem Domänencontroller besonders wichtig.

7.10.22 Relevante Ereignisprotokolle

Ereignisse müssen anhand des gleichen Benutzer-, Computer- und Fehlerzeitpunkts korreliert werden.

Auf dem betroffenen Client:

Auf dem beteiligten Domänencontroller:

Beispiel für Clientereignisse der letzten zwei Stunden:

Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  StartTime = (Get-Date).AddHours(-2)
} |
  Where-Object {
    $_.ProviderName -match 'NETLOGON|W32Time|DNS|Lsa'
  } |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Fehlgeschlagene Anmeldungen auf einem System:

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4625
  StartTime = (Get-Date).AddHours(-2)
} |
  Select-Object TimeCreated, Id, Message

Relevante Ereignisse:

Ereignis-ID Typische Bedeutung Typischer Ort
4624 erfolgreiche Anmeldung System, auf dem die Anmeldung erfolgte
4625 fehlgeschlagene Anmeldung System, auf dem die Anmeldung versucht wurde
4740 Benutzerkonto wurde gesperrt zuständiges System beziehungsweise DC
4767 Benutzerkonto wurde entsperrt Domänencontroller
4768 Kerberos-TGT wurde angefordert Domänencontroller
4769 Kerberos-Dienstticket wurde angefordert Domänencontroller
4771 Kerberos-Vorauthentifizierung fehlgeschlagen Domänencontroller
4776 NTLM-Anmeldeinformationen wurden geprüft für Domänenkonten auf dem zuständigen DC
3210 Netlogon konnte Computer nicht beim DC authentifizieren Mitgliedscomputer
5719 kein Domänencontroller für sichere Sitzung verfügbar Mitgliedscomputer
1053 oder 1055 Gruppenrichtlinienverarbeitung mit Domänen- oder DC-Problem Mitgliedscomputer

Die Ereignisse erscheinen nur, wenn die entsprechenden Überwachungsrichtlinien und Protokollkanäle aktiviert sind. Das Fehlen eines Ereignisses beweist deshalb nicht, dass kein Versuch stattgefunden hat.

7.10.23 Ereignis 4625 auswerten

Bei Ereignis 4625 sind besonders wichtig:

Account Name
Account Domain
Failure Reason
Status
Sub Status
Logon Type
Logon Process
Authentication Package
Workstation Name
Source Network Address
Caller Process Name

Wichtige Anmeldetypen:

Logon Type Bedeutung
2 interaktive lokale Anmeldung
3 Netzwerkanmeldung
4 Batch beziehungsweise geplante Aufgabe
5 Dienstanmeldung
7 Entsperren
10 Remotedesktop beziehungsweise RemoteInteractive
11 zwischengespeicherte interaktive Anmeldung

Häufige Status- oder Substatuswerte:

Code Bedeutung Nächster Nachweis
0xC000005E keine Anmeldeserver verfügbar DNS, DC Locator, Netzwerk und DC-Zustand prüfen
0xC0000064 Benutzerkonto nicht gefunden Benutzername, Domäne und Kontobestand prüfen
0xC000006A falsches Kennwort Eingabe, Kennwortänderung und gespeicherte Kennwörter prüfen
0xC000006D allgemeiner Fehler bei Benutzername oder Authentifizierungsdaten Status, Substatus und Authentifizierungspaket korrelieren
0xC000006F Anmeldung außerhalb erlaubter Zeiten Anmeldezeiten prüfen
0xC0000070 Anmeldung von nicht erlaubter Arbeitsstation Arbeitsstationsbeschränkung prüfen
0xC0000071 Kennwort abgelaufen Kennwortstatus und Änderungsweg prüfen
0xC0000072 Konto deaktiviert Kontostatus und Änderungshistorie prüfen
0xC000015B erforderlicher Anmeldetyp nicht gewährt Benutzerrechte und Richtlinien prüfen
0xC0000192 Netlogon-Dienst ist nicht gestartet Dienstzustand und Systemereignisse prüfen
0xC0000193 Konto abgelaufen Ablaufdatum des Kontos prüfen
0xC0000234 Konto gesperrt Ereignis 4740 und Quelle der Fehlversuche untersuchen
0xC0000413 Authentifizierungsfirewall verhindert Anmeldung Authentifizierungsrichtlinie und zulässige Systeme prüfen

Status und Substatus müssen gemeinsam ausgewertet werden. Der sichtbare Meldungstext am Anmeldebildschirm kann absichtlich weniger genau sein als das Sicherheitsereignis.

7.10.24 Kerberos-Ereignisse auswerten

Ereignis 4768 zeigt die Anforderung eines Kerberos-TGT. Ereignis 4771 zeigt eine fehlgeschlagene Kerberos-Vorauthentifizierung.

Häufige Kerberos-Fehlercodes:

Code Kerberos-Bezeichnung Einordnung
0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN Benutzerprinzipal nicht in Kerberos-Datenbank gefunden
0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN angeforderter Dienstprinzipal nicht gefunden
0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE Prinzipal nicht eindeutig
0xC KDC_ERR_POLICY KDC-Richtlinie lehnt Anfrage ab
0xE KDC_ERR_ETYPE_NOSUPP keine gemeinsame unterstützte Verschlüsselungsart
0x10 KDC_ERR_PADATA_TYPE_NOSUPP Vorauthentifizierungstyp nicht unterstützt; bei Smartcard auch Zertifikatsproblem möglich
0x12 KDC_ERR_CLIENT_REVOKED Anmeldeinformationen des Clients wurden widerrufen
0x17 KDC_ERR_KEY_EXPIRED Kennwort abgelaufen
0x18 KDC_ERR_PREAUTH_FAILED Vorauthentifizierung ungültig; häufig falsches Kennwort
0x19 KDC_ERR_PREAUTH_REQUIRED zusätzliche Vorauthentifizierung erforderlich; nicht automatisch ein Fehler
0x1D KDC_ERR_SVC_UNAVAILABLE Kerberos-Dienst nicht verfügbar
0x20 KRB_AP_ERR_TKT_EXPIRED Ticket abgelaufen
0x25 KRB_AP_ERR_SKEW Zeitabweichung zu groß
0x34 KRB_ERR_RESPONSE_TOO_BIG Antwort zu groß für UDP; erneuter Versuch über TCP erforderlich

Ein einzelner Kerberos-Fehlercode muss mit Benutzer, Clientadresse, DC, Zeitstempel und nachfolgendem Erfolg oder Fehlschlag korreliert werden.

Der Code 0x19 kann Teil eines normalen Kerberos-Ablaufs sein und darf nicht allein als Störung gewertet werden.

7.10.25 Kontosperren bis zur Quelle verfolgen

Bei einer Sperre muss nicht nur das Konto entsperrt, sondern die Quelle der wiederholten falschen Kennwörter bestimmt werden.

Zu untersuchen sind:

Eine Kontosperre kann durch einen Hintergrundprozess entstehen, obwohl der Benutzer sein aktuelles Kennwort am Anmeldebildschirm richtig eingibt.

7.10.26 Active-Directory-Replikation prüfen

Wenn Anmeldungen abhängig vom verwendeten Domänencontroller unterschiedlich reagieren, müssen Replikation und DC-Zustand geprüft werden.

Auf einem autorisierten Administrationssystem oder Domänencontroller:

repadmin /replsummary

repadmin /showrepl

Gesamtstrukturweite Übersicht:

repadmin /showrepl * /csv

Grundlegender DC-Test:

dcdiag /v

DNS-Test für einen bestimmten DC:

dcdiag /test:DNS /v /s:<DC-Name>

Zu prüfen sind:

Mögliche Symptome eines Replikationsfehlers:

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Fehlercode, Ursache und Replikationspartner bestimmt werden.

7.10.27 Standort, VPN und RODC berücksichtigen

AD-Standorte beeinflussen die Auswahl eines Domänencontrollers.

Clientstandort anzeigen:

nltest /dsgetsite

Zu prüfen sind:

Ein RODC kann nur solche Anmeldungen lokal verarbeiten, für die die erforderlichen Anmeldeinformationen entsprechend der Kennwortreplikationsrichtlinie verfügbar sind oder ein beschreibbarer DC erreicht werden kann.

7.10.28 RDP- und NLA-Anmeldungen abgrenzen

Bei Remotedesktop erfolgt die Anmeldung am entfernten Computer. Entscheidend sind daher DNS, Netzwerk, Zeit, Domänenverbindung, sicherer Kanal und Anmelderechte des Zielsystems.

Zu prüfen sind:

Ein erfolgreicher Domänenlogin am lokalen Notebook beweist nicht, dass der entfernte Server die Domäne erreichen oder den Benutzer anmelden kann.

NLA sollte nicht dauerhaft deaktiviert werden, nur um einen Authentifizierungsfehler zu umgehen.

7.10.29 Smartcard und Windows Hello for Business abgrenzen

Wenn Kennwortanmeldung funktioniert, aber Smartcard oder Windows Hello fehlschlägt, ist die normale Kennwortprüfung wahrscheinlich nicht die Hauptursache.

Bei Smartcard-Anmeldung zu prüfen:

Bei Windows Hello for Business zu prüfen:

Eine PIN ist nicht das Domänenkennwort. Ein PIN-Fehler beweist deshalb nicht, dass das AD-Kennwort falsch ist.

7.10.30 Authentifizierung, Sitzung und Benutzerprofil unterscheiden

Nach erfolgreicher Authentifizierung können weitere Fehler auftreten:

Typische Unterscheidung:

Beobachtung Einordnung
Ereignis 4624 vorhanden, danach Profilfehler Authentifizierung war wahrscheinlich erfolgreich
Desktop erscheint nach langer Wartezeit Gruppenrichtlinie, Skript oder Ressource prüfen
temporäres Profil Benutzerprofil und Datenträger prüfen
nur ein Benutzerprofil betroffen lokales oder servergespeichertes Profil möglich
Anmeldung anderer Benutzer funktioniert allgemeine DC-Erreichbarkeit wahrscheinlich vorhanden
Anmeldung im abgesicherten Diagnosekontext funktioniert nachgelagerte Erweiterung, Richtlinie oder Dienst möglich

Gruppenrichtlinienstatus in einer bestehenden Sitzung:

gpresult /r

Computerrichtlinien:

gpresult /r /scope computer

Benutzerrichtlinien:

gpresult /r /scope user

gpupdate /force ist keine reine Diagnose. Der Befehl kann neue Richtlinien anwenden und den Ausgangszustand verändern.

7.10.31 Systematischer Diagnoseablauf

  1. Fehlermeldung aufnehmen
    Exakten Wortlaut, Benutzer, Computer, Uhrzeit und Anmeldeart dokumentieren.

  2. Anmeldephase bestimmen
    Identität, Authentifizierung, Sitzung oder Profil unterscheiden.

  3. Umfang bestimmen
    Einen Benutzer, einen Computer, einen Standort oder die gesamte Domäne unterscheiden.

  4. Anmeldeanbieter kontrollieren
    Kennwort, PIN, Smartcard, lokales Konto und Domänenkonto unterscheiden.

  5. Namensformat prüfen
    UPN und DOMÄNE\Benutzer kontrolliert vergleichen.

  6. Domänenmitgliedschaft prüfen
    Lokale Mitgliedschaft und erwartete Domäne bestätigen.

  7. Online- und Cache-Anmeldung unterscheiden
    Feststellen, ob ein DC tatsächlich beteiligt war.

  8. Netzwerkzustand prüfen
    Schnittstelle, Adresse, Gateway, VPN und DNS-Server dokumentieren.

  9. DNS-SRV-Einträge prüfen
    LDAP- und Kerberos-Diensteinträge auflösen.

  10. Domänencontroller ermitteln
    nltest /dsgetdc und Standortinformationen auswerten.

  11. DC-Erreichbarkeit prüfen
    DNS, Kerberos, LDAP, SMB, RPC und benötigte Zusatzdienste untersuchen.

  12. Zeit prüfen
    Zeitquelle, Status und Abweichung zum DC bestimmen.

  13. Benutzerkonto prüfen
    Existenz, UPN, Aktivierung, Sperre, Ablauf und Kennwortstatus auswerten.

  14. Sicheren Kanal prüfen
    Ausschließlich mit lesenden Tests beginnen.

  15. Authentifizierungsverfahren bestimmen
    Kerberos, NTLM, Smartcard oder Windows Hello unterscheiden.

  16. Ereignisse korrelieren
    Client- und DC-Ereignisse auf denselben Versuch begrenzen.

  17. Fehlercode auswerten
    Status, Substatus, Kerberos-Code und Anmeldetyp bestimmen.

  18. Replikation prüfen
    Besonders bei DC- oder Standortabhängigkeit.

  19. Nachgelagerte Anmeldung prüfen
    Profil, Gruppenrichtlinie, Skript und Ressourcen untersuchen.

  20. Hypothese formulieren
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

  21. Eine kontrollierte Maßnahme durchführen
    Risiko, Berechtigung, Rückweg und Erfolgskriterium dokumentieren.

  22. Online-Domänenanmeldung verifizieren
    Nicht nur Cache- oder lokale Anmeldung testen.

  23. Vollständige Benutzerfunktion prüfen
    Desktop, Gruppenrichtlinien und benötigte Ressourcen kontrollieren.

  24. Nachkontrolle durchführen
    Ereignisse, Replikation und weitere Benutzer beziehungsweise Systeme prüfen.

7.10.32 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
lokales Konto funktioniert, Domänenkonto nicht Domänenweg oder Domänenkonto fehlerhaft DNS, DC Locator, Konto und sicheren Kanal prüfen
anderer Benutzer funktioniert am gleichen Computer benutzerbezogener Fehler Kontostatus, Kennwort und Profil prüfen
gleicher Benutzer funktioniert an anderem Computer clientbezogener Fehler DNS, Zeit, sicherer Kanal und Profil prüfen
Anmeldung funktioniert nur offline Cache-Anmeldung Onlineweg zum DC prüfen
altes Kennwort funktioniert offline alter lokaler Anmeldecache Onlineanmeldung mit aktuellem Kennwort prüfen
nltest /dsgetdc findet keinen DC DNS, Netzwerk oder Netlogon SRV-Einträge, DNS-Server und Dienst prüfen
DC wird gefunden, Ports schlagen fehl Firewall, Routing oder DC-Dienst Regeln und beidseitige Protokolle prüfen
Ereignis 0xC000005E keine Anmeldeserver verfügbar DNS, DC Locator und Netzwerk prüfen
Ereignis 0xC0000064 Benutzer nicht gefunden Identität und Kontobestand prüfen
Ereignis 0xC000006A falsches Kennwort Kennwort, Cache und gespeicherte Daten prüfen
Ereignis 0xC0000234 Konto gesperrt Ereignis 4740 und Sperrquelle prüfen
Kerberos 0x18 Vorauthentifizierung fehlgeschlagen Kennwort und zugehörigen Versuch prüfen
Kerberos 0x25 Zeitabweichung zu groß Zeitquelle und Abweichung prüfen
sicherer Kanal liefert False Computervertrauen fehlerhaft DNS, Zeit, Computerkonto und Replikation prüfen
Vertrauensfehler nur bei einem Computer Computerkennwort oder Computerkonto sicheren Kanal kontrolliert reparieren
Anmeldung funktioniert abhängig vom DC Replikations- oder DC-Fehler DC-Ereignisse und repadmin auswerten
Kennwort funktioniert, PIN nicht Windows-Hello-Problem Hello-, TPM- und Richtlinienzustand prüfen
Kennwort funktioniert, Smartcard nicht PKI- oder Zertifikatsproblem Zertifikate, KDC und Sperrprüfung untersuchen
Ereignis 4624 vorhanden, Desktop fehlt Authentifizierung erfolgreich, Folgephase fehlerhaft Profil, GPO und Skripte prüfen
nur RDP schlägt fehl RDP-Recht, NLA oder Zielsystem Logon Type 10 und Zielsystem prüfen
Konto wird sofort erneut gesperrt gespeichertes altes Kennwort Quellcomputer und Hintergrundprozesse ermitteln

7.10.33 Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falsches Namensformat Anmeldung richtet sich nachweislich an falsche Domäne oder lokales Konto
falsches Kennwort Ereigniscode und kontrollierter Identitätsabgleich bestätigen die Ursache
Konto gesperrt AD-Kontostatus und Ereignis gesper 4740 bestätigen die Sperre
Konto deaktiviert Enabled : False oder entsprechendes Änderungsereignis
Konto abgelaufen Ablaufdatum liegt in der Vergangenheit
Kennwort abgelaufen PasswordExpired oder Kerberos-Code 0x17
falscher DNS-Server Client verwendet nicht den vorgesehenen AD-DNS-Server
fehlender SRV-Eintrag autorisierte DNS-Abfrage liefert den benötigten Eintrag nicht
falscher DC-Eintrag SRV- oder A/AAAA-Eintrag verweist auf falschen oder alten DC
DC nicht erreichbar protokollspezifischer Test und Netzwerkprotokoll bestätigen Unterbrechung
falscher AD-Standort nltest /dsgetsite und Subnetzkonfiguration stimmen nicht überein
VPN vor Anmeldung fehlt Onlineweg zum DC ist am Anmeldebildschirm nicht vorhanden
Zeitabweichung w32tm oder Kerberos-Code 0x25 bestätigt die Abweichung
defekter sicherer Kanal Test-ComputerSecureChannel meldet reproduzierbar False
Computerkonto fehlt AD-Abfrage bestätigt fehlendes oder falsches Computerkonto
doppelter Computername zwei Systeme verwenden nachweislich dieselbe Computeridentität
AD-Replikationsfehler repadmin oder DC-Protokolle zeigen fehlgeschlagene Replikation
Kerberos-Verschlüsselungsproblem Kerberos-Code und Kontokonfiguration bestätigen fehlende gemeinsame Verschlüsselungsart
Smartcard-Zertifikatsproblem Zertifikatsprüfung oder PKINIT-Ereignis bestätigt Ursache
fehlendes Anmelderecht Ereignis 0xC000015B und wirksame Richtlinie stimmen überein
Profilfehler erfolgreiche Authentifizierung und Profildienstereignis liegen nacheinander vor
Gruppenrichtlinienfehler GroupPolicy-Protokoll zeigt konkrete fehlgeschlagene Richtlinienverarbeitung
gespeichertes altes Kennwort Ereignisse zeigen wiederholte Fehlversuche von bestimmtem Gerät oder Prozess

7.10.34 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg beziehungsweise Kontrolle
richtigen Benutzer oder richtige Domäne auswählen gering ursprüngliche Eingabe dokumentieren
Tastaturlayout korrigieren Fehleingabe bleibt möglich kontrollierte Testeingabe ohne Kennwortprotokollierung
Netzwerk oder Voranmelde-VPN wiederherstellen anderer Netzwerkweg wird aktiv vorherigen Netzwerkzustand dokumentieren
DNS-Konfiguration korrigieren andere Namensauflösung kann beeinflusst werden bisherige DNS-Werte sichern
falschen SRV- oder Hosteintrag korrigieren viele Clients können betroffen sein bisherigen Wert und TTL dokumentieren
Windows-Zeit kontrolliert synchronisieren Zeitsprung kann Dienste beeinflussen alte Quelle und Abweichung sichern
Konto nach Ursachenprüfung entsperren erneute sofortige Sperre möglich Sperrquelle vorher ermitteln
Kennwort nach Identitätsprüfung zurücksetzen gespeicherte Daten oder Schlüssel können betroffen sein vorgesehenes Identitätsverfahren verwenden
sicheren Kanal reparieren Computervertrauen wird verändert verwendeten DC und Ausgangsbefund dokumentieren
Computerkennwort zurücksetzen Vertrauensbeziehung kann bei Fehler weiter ausfallen lokale Administrationsmöglichkeit sicherstellen
Computer neu in Domäne aufnehmen Neustarts, Profilzuordnung und Verwaltungszustand können betroffen sein nur als letzte Maßnahme mit Wiederaufnahmeplan
AD-Replikationsfehler beheben domänenweite Auswirkungen möglich DC-spezifischen Änderungsplan verwenden
GPO korrigieren viele Benutzer oder Computer betroffen Version, Sicherung und Zielbereich dokumentieren
beschädigtes Profil reparieren Benutzerdaten können verloren gehen Profil und Daten nach Vorgabe sichern
gespeicherte alte Anmeldeinformation aktualisieren Anwendung oder Dienst kann ausfallen betroffene Abhängigkeit vorher bestimmen

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

7.10.35 Sicheren Kanal kontrolliert reparieren

Eine Reparatur ist nur gerechtfertigt, wenn:

Reparatur mit PowerShell:

$Credential = Get-Credential "<NETBIOS-Domäne>\<Administrationskonto>"

Test-ComputerSecureChannel `
  -Repair `
  -Server "<DC-FQDN>" `
  -Credential $Credential `
  -Verbose

Alternativ kann das lokale Computerkennwort kontrolliert zurückgesetzt werden:

$Credential = Get-Credential "<NETBIOS-Domäne>\<Administrationskonto>"

Reset-ComputerMachinePassword `
  -Server "<DC-FQDN>" `
  -Credential $Credential

Danach:

Test-ComputerSecureChannel `
  -Server "<DC-FQDN>" `
  -Verbose

Anschließend sind je nach Verfahren ein Neustart und eine erneute Online-Domänenanmeldung erforderlich.

Wichtig:

7.10.36 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine erfolgreiche lokale oder zwischengespeicherte Anmeldung ist keine ausreichende Verifikation einer reparierten Domänenanmeldung.

7.10.37 Präventionsmaßnahmen

7.10.38 Typische Fehler bei der Diagnose

7.10.39 Typische Prüfungsfragen

Warum kann eine Domänenanmeldung trotz richtiger Anmeldedaten fehlschlagen?

Die Anmeldung benötigt neben gültigen Anmeldedaten unter anderem Netzwerk, DNS, einen erreichbaren Domänencontroller, ausreichende Zeitsynchronisation, ein gültiges Benutzerkonto und eine funktionierende Computervertrauensstellung.

Warum ist DNS für eine Active-Directory-Anmeldung erforderlich?

Der Client ermittelt Domänencontroller und Kerberos-Dienste über DNS-SRV-Einträge. Eine einfache Auflösung des Domänennamens reicht dafür nicht aus.

Was bedeutet die Meldung, dass keine Anmeldeserver verfügbar sind?

Der Client konnte keinen geeigneten Domänencontroller für die Anmeldeanforderung verwenden. Danach müssen DNS, DC Locator, Netzwerk, benötigte Dienste und der Zustand der Domänencontroller geprüft werden.

Was ist eine zwischengespeicherte Domänenanmeldung?

Windows verwendet lokal gespeicherte Informationen einer früheren erfolgreichen Domänenanmeldung, wenn kein Domänencontroller erreichbar ist. Dabei findet keine vollständige aktuelle Onlineprüfung des Domänenkontos statt.

Was beweist eine erfolgreiche Cache-Anmeldung nicht?

Sie beweist weder die Erreichbarkeit eines Domänencontrollers noch den aktuellen Konto-, Kennwort-, Gruppen- oder Sperrstatus.

Warum kann nach einer Kennwortänderung offline noch das alte Kennwort funktionieren?

Der lokale Computer kann noch den Nachweis der früheren erfolgreichen Domänenanmeldung gespeichert haben. Der Cache wird erst durch eine geeignete erfolgreiche Online-Anmeldung aktualisiert.

Welche Bedeutung besitzt die Uhrzeit bei Kerberos?

Kerberos verwendet Zeitstempel zum Schutz gegen Wiederholungsangriffe. Eine zu große Zeitabweichung zwischen Client und Domänencontroller kann die Authentifizierung verhindern.

Was bedeutet ein Kerberos-Fehler 0x18?

Die Kerberos-Vorauthentifizierungsinformationen waren ungültig. Häufig wurde ein falsches Kennwort verwendet. Der konkrete Versuch muss mit Benutzer, Client und Zeitpunkt korreliert werden.

Was bedeutet Ereignis 4625?

Auf dem protokollierenden System ist eine Anmeldung fehlgeschlagen. Status, Substatus, Anmeldetyp, Konto, Quelladresse und Authentifizierungspaket müssen gemeinsam ausgewertet werden.

Was bedeutet Ereignis 4740?

Ein Benutzerkonto wurde gesperrt. Das Ereignis sollte verwendet werden, um Zeitpunkt und auslösenden Computer beziehungsweise Anmeldeweg zu bestimmen.

Was ist der sichere Kanal eines Domänencomputers?

Es ist die durch das Computerkonto und sein Kennwort abgesicherte Vertrauensbeziehung zwischen Domänenmitglied und Domäne.

Wie wird der sichere Kanal zunächst geprüft?

Auf einem Mitgliedscomputer mit:

Test-ComputerSecureChannel -Verbose

Der Test sollte zuerst ohne -Repair ausgeführt werden.

Warum ist nltest /sc_verify kein rein lesender Test?

Wenn der sichere Kanal nicht funktioniert, kann der Befehl den bestehenden Kanal entfernen und neu aufbauen.

Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?

DNS-, Netzwerk-, Zeit- oder Replikationsfehler können die eigentliche Ursache sein. Eine erneute Domänenaufnahme verändert den Systemzustand, benötigt Neustarts und kann weitere Verwaltungs- oder Profilprobleme verursachen.

Warum kann die Anmeldung über einen DC funktionieren und über einen anderen fehlschlagen?

Benutzer-, Kennwort- oder Computerkontoänderungen können wegen eines Replikationsfehlers nicht auf allen Domänencontrollern den gleichen Stand besitzen.

Warum kann die Kennwortanmeldung funktionieren, während die PIN fehlschlägt?

Die Windows-Hello-PIN verwendet einen gerätegebundenen Schlüssel und ist nicht identisch mit dem Domänenkennwort.

Warum kann Ereignis 4624 vorhanden sein, obwohl der Benutzer keinen Desktop erhält?

Die Authentifizierung und Sitzungserstellung können erfolgreich gewesen sein, während Benutzerprofil, Gruppenrichtlinie, Anmeldeskript oder eine benötigte Ressource anschließend fehlschlagen.

7.10.40 Checkliste

7.10.41 Schnellreferenz

Aufgabe Befehl
aktuelle Identität whoami
Benutzer-SID whoami /user
vollständige Domänenidentität whoami /fqdn
Gruppen der Sitzung whoami /groups
Domänenmitgliedschaft Get-CimInstance Win32_ComputerSystem
Netzwerkkonfiguration ipconfig /all
DNS-Server Get-DnsClientServerAddress
LDAP-SRV-Eintrag Resolve-DnsName _ldap._tcp.dc._msdcs.<Domäne> -Type SRV
Kerberos-SRV-Eintrag Resolve-DnsName _kerberos._tcp.<Domäne> -Type SRV
DC ermitteln nltest /dsgetdc:<Domäne>
DC neu ermitteln nltest /dsgetdc:<Domäne> /force
AD-Standort nltest /dsgetsite
DC-Liste nltest /dclist:<Domäne>
DNS-TCP-Test Test-NetConnection <DC> -Port 53
Kerberos-TCP-Test Test-NetConnection <DC> -Port 88
LDAP-TCP-Test Test-NetConnection <DC> -Port 389
SMB-TCP-Test Test-NetConnection <DC> -Port 445
RPC Endpoint Mapper Test-NetConnection <DC> -Port 135
Zeitstatus w32tm /query /status
Zeitquelle w32tm /query /source
Zeitvergleich w32tm /stripchart /computer:<DC> /dataonly /samples:5
Benutzerkonto Get-ADUser <Benutzer> -Properties *
gesperrte Konten Search-ADAccount -LockedOut -UsersOnly
sicherer Kanal, nur Test Test-ComputerSecureChannel -Verbose
letzter Netlogon-Kanalstatus nltest /sc_query:<Domäne>
Kerberos-Tickets klist tickets
Kerberos-TGT klist tgt
Anmeldefehler Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
DC-Gesundheit dcdiag /v
DC-DNS-Test dcdiag /test:DNS /v
Replikationsübersicht repadmin /replsummary
Replikationsdetails repadmin /showrepl
Gruppenrichtlinienergebnis gpresult /r

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Test-ComputerSecureChannel -Repair
Reset-ComputerMachinePassword
nltest /sc_verify
nltest /sc_reset
nltest /sc_change_pwd
klist purge
w32tm /resync
gpupdate /force

7.10.42 Quellen

Offizielle Microsoft-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

Revision #1
Created 2 August 2026 14:16:51 by Admin
Updated 2 August 2026 14:17:06 by Admin