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:

eine falsche Anmeldeidentität;

falsche oder veraltete Anmeldeinformationen;

ein gesperrtes, deaktiviertes oder abgelaufenes Benutzerkonto;

eine fehlende Netzwerk- oder VPN-Verbindung;

eine fehlerhafte DNS-Konfiguration;

eine fehlgeschlagene Domänencontroller-Ermittlung;

einen nicht erreichbaren Domänencontroller;

eine zu große Zeitabweichung;

einen Kerberos- oder NTLM-Fehler;

einen beschädigten sicheren Kanal des Computers;

eine fehlerhafte Active-Directory-Replikation;

eine Anmelde-, Sicherheits- oder Zugriffsrichtlinie;

eine Smartcard-, Zertifikats- oder Windows-Hello-Abhängigkeit;

den Benutzerprofildienst, eine Gruppenrichtlinie oder ein Anmeldeskript;

eine RDP-, NLA- oder Remotedesktop-Besonderheit;

eine standort-, RODC- oder vertrauensstellungsabhängige Konfiguration.

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:

Der Benutzer wählt den richtigen Anmeldeanbieter.

Windows ordnet den eingegebenen Namen dem vorgesehenen Konto zu.

Der Computer besitzt eine geeignete Netzwerkverbindung.

Der Client verwendet die vorgesehenen DNS-Server.

DNS liefert die erforderlichen Domänen- und Dienstinformationen.

DC Locator ermittelt einen geeigneten Domänencontroller.

Die benötigten Netzwerkprotokolle erreichen den Domänencontroller.

Client und Domänencontroller besitzen ausreichend synchronisierte Uhrzeiten.

Der Computer besitzt eine gültige Vertrauensbeziehung zur Domäne.

Kerberos, NTLM oder das vorgesehene zertifikatsbasierte Verfahren beginnt.

Der Domänencontroller prüft das Benutzerkonto und die Anmeldeinformationen.

Kontorichtlinien und Anmelderechte werden ausgewertet.

Windows erzeugt die Anmeldesitzung und das Zugriffstoken.

Benutzerprofil, Gruppenrichtlinien und Anmeldeskripte werden verarbeitet.

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:

exakter Wortlaut der Fehlermeldung;

Datum und Uhrzeit des Versuchs;

betroffener Benutzer;

betroffener Computer;

Anmeldeart: lokal, Konsole, RDP, VPN, Smartcard, PIN oder Kennwort;

eingegebenes Namensformat;

aktueller Standort und Netzwerkweg;

Verbindung mit oder ohne VPN;

letzter erfolgreicher Anmeldezeitpunkt;

Umfang des Fehlers;

kürzlich erfolgte Kennwort-, Computer-, DNS-, VPN- oder Richtlinienänderungen;

verwendeter oder erwarteter Domänencontroller;

relevante Ereignisse auf Client und Domänencontroller.

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:

welcher Benutzer angezeigt wird;

welche Domäne oder welcher Computername unter dem Benutzer steht;

ob „Anderer Benutzer“ gewählt wurde;

ob Kennwort, PIN, Smartcard oder ein anderer Anmeldeanbieter aktiv ist;

ob das richtige Tastaturlayout verwendet wird;

ob Feststelltaste oder Num-Taste den eingegebenen Wert verändert;

ob ein alter Benutzername automatisch vorausgefüllt wurde;

ob ein lokales Konto statt des Domänenkontos gewählt wurde;

ob ein UPN oder der DOMÄNE\Benutzer-Name erforderlich ist.

Beispiele:

<NETBIOS-Domäne>\MaxMustermann

max.mustermann@<DNS-Domäne>

.\MaxMustermann

Bedeutung:

<NETBIOS-Domäne>\MaxMustermann erzwingt die Zuordnung zur angegebenen AD-Domäne.

max.mustermann@<DNS-Domäne> verwendet den Benutzerprinzipalnamen.

.\MaxMustermann bezeichnet ein lokales Konto des Computers.

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:

whoami beschreibt die bereits bestehende Sitzung.

$env:LOGONSERVER zeigt den Anmeldeserver dieser Sitzung, nicht zwingend den DC, den ein neuer Versuch verwenden würde.

Eine alte Sitzung kann weiter funktionieren, obwohl eine neue Anmeldung fehlschlägt.

Eine Anmeldung aus dem lokalen Cache kann ohne aktuelle DC-Authentifizierung entstanden sein.

Gruppenmitgliedschaften im bestehenden Zugriffstoken können veraltet sein.

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:

ist der Computer tatsächlich Domänenmitglied?

gehört er zur erwarteten Domäne?

wurde er versehentlich in eine Arbeitsgruppe verschoben?

wurde ein altes Systemabbild oder ein VM-Snapshot wiederhergestellt?

existiert ein anderer Computer mit demselben Namen?

wurde das Computerkonto gelöscht, zurückgesetzt oder neu angelegt?

wurde das Gerät geklont, ohne die Identität ordnungsgemäß vorzubereiten?

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:

dass ein Domänencontroller erreichbar war;

dass das Konto aktuell aktiviert ist;

dass das Konto aktuell nicht gesperrt ist;

dass das aktuelle Domänenkennwort verwendet wurde;

dass Kerberos-Tickets ausgestellt wurden;

dass Netzwerkressourcen erreichbar sind;

dass Gruppenmitgliedschaften aktuell sind.

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:

aktive Schnittstelle;

IPv4- und IPv6-Adresse;

Präfix beziehungsweise Subnetzmaske;

Standardgateway;

DNS-Server;

DHCP-Status;

DNS-Suffix;

VPN-Adapter;

mehrere gleichzeitig aktive Verbindungen;

APIPA-Adresse aus 169.254.0.0/16;

unerwartete öffentliche oder private DNS-Server.

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:

antwortet der vorgesehene interne DNS-Server?

existieren die benötigten SRV-Einträge?

verweisen die SRV-Einträge auf vorhandene Domänencontroller?

lassen sich die zurückgegebenen DC-Namen in gültige Adressen auflösen?

werden alte oder außer Betrieb genommene DCs geliefert?

erhält der Client über VPN andere DNS-Server?

verwendet eine zweite Netzwerkschnittstelle ungeeignete DNS-Server?

stimmt das DNS-Suffix?

sind IPv4- und IPv6-Antworten erreichbar?

unterscheiden sich die Antworten verschiedener DNS-Server?

Ö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:

Test-NetConnection prüft hier nur TCP.

Ein erfolgreicher Test auf TCP 53 beweist keine funktionierende DNS-Kommunikation über UDP.

Ein erfolgreicher Test auf TCP 88 beweist keine vollständige Kerberos-Authentifizierung.

Ein erfolgreicher Test auf TCP 135 beweist nicht, dass der anschließend ausgehandelte dynamische RPC-Port erreichbar ist.

Nicht jede Umgebung benötigt bei jedem Anmeldevorgang alle aufgeführten optionalen Ports.

Ein allgemeiner UDP-Porttest liefert keinen eindeutigen Funktionsnachweis.

Die Freigabe einzelner Ports ohne Kenntnis des vollständigen AD-Verbindungswegs kann unvollständig sein.

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:

Datum;

Uhrzeit;

Zeitzone;

Zeitquelle;

letzter erfolgreicher Synchronisierungszeitpunkt;

Zeitabweichung zum verwendeten DC;

Zustand des Windows-Zeitdienstes;

Hypervisor- oder VM-Zeitsynchronisation;

Zeitquellen der Domänencontroller;

PDC-Emulator und externe Zeitquelle.

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:

existiert das Konto?

wird der richtige UPN verwendet?

ist das Konto aktiviert?

ist das Konto gesperrt?

ist das Konto abgelaufen?

ist das Kennwort abgelaufen?

wurde das Kennwort kürzlich geändert oder zurückgesetzt?

darf sich das Konto nur an bestimmten Arbeitsstationen anmelden?

gelten eingeschränkte Anmeldezeiten?

gilt eine fein abgestufte Kennwortrichtlinie?

besitzt das Konto besondere Authentifizierungsanforderungen?

stammt der angezeigte Zustand vom gleichen DC, der den Fehler verarbeitet hat?

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:

falscher Benutzer oder falsche Domäne;

falsches Tastaturlayout;

Feststelltaste oder Num-Taste;

Kennwort wurde kürzlich geändert;

alter zwischengespeicherter Anmeldenachweis;

Kennwortänderung wurde noch nicht vollständig repliziert;

gespeicherte alte Anmeldeinformationen;

Konto wurde gesperrt;

Kennwort ist abgelaufen;

Benutzer muss das Kennwort bei der nächsten Anmeldung ändern;

Kennwortänderungsdienst oder DC ist nicht erreichbar;

Smartcard- oder Windows-Hello-Anbieter wurde statt Kennwort gewählt.

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:

Test-ComputerSecureChannel ist für Domänenmitgliedscomputer geeignet.

Auf Domänencontrollern kann das Cmdlet falsch-negative Ergebnisse liefern.

nltest /sc_query meldet den Zustand der letzten Verwendung und ist kein vollständiger neuer Funktionstest.

nltest /sc_verify ist kein rein lesender Test: Wenn der Kanal nicht funktioniert, kann der Befehl den Kanal entfernen und neu aufbauen.

nltest /sc_reset, nltest /sc_change_pwd, Reset-ComputerMachinePassword und Test-ComputerSecureChannel -Repair verändern den Zustand.

Eine Reparatur darf erst nach Prüfung von DNS, Netzwerk, Zeit, DC-Zustand und Computerkonto erfolgen.

Mögliche Ursachen eines defekten sicheren Kanals:

Wiederherstellung eines alten VM-Snapshots;

Zurückspielen eines veralteten Systemabbilds;

doppelter Computername;

gelöschtes oder zurückgesetztes Computerkonto;

Neuinstallation mit wiederverwendetem Computernamen;

nicht ordnungsgemäß geklonter Rechner;

nicht übereinstimmendes Computerkennwort;

AD-Replikationsfehler;

längere Netzwerk- oder DC-Probleme;

fehlerhafte Automatisierung bei der Gerätebereitstellung.

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:

funktionierende DNS-Auflösung;

erreichbaren KDC auf dem Domänencontroller;

ausreichend synchronisierte Zeit;

ein gültiges Benutzerkonto;

passende kryptografische Schlüssel;

bei Dienstzugriffen einen korrekten Service Principal Name;

bei Smartcard-Anmeldung geeignete Zertifikate und Vertrauensketten.

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:

ist ein Ticket Granting Ticket vorhanden?

für welche Kerberos-Realm wurde es ausgestellt?

welcher KDC hat das Ticket ausgestellt?

sind Start- und Ablaufzeit plausibel?

sind Diensttickets für die erwarteten Dienste vorhanden?

wird statt Kerberos möglicherweise NTLM verwendet?

stimmt der Servername mit dem erwarteten Dienstnamen überein?

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

klist purge

Mögliche Auswirkungen:

bestehende Zugriffe müssen neu authentifiziert werden;

Netzlaufwerke oder Anwendungen können vorübergehend Verbindungen verlieren;

die eigentliche Ursache kann durch das Löschen alter Nachweise verdeckt werden;

der Befehl betrifft nur die ausgewählte Anmeldesitzung.

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:

Windows-Protokolle → System

Windows-Protokolle → Sicherheit

Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational

Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Profile Service → Operational

Netlogon-, DNS-Client-, LSA-, Kerberos-, W32Time- und Gruppenrichtlinienereignisse

Auf dem beteiligten Domänencontroller:

Windows-Protokolle → Sicherheit

Windows-Protokolle → System

Verzeichnisdienst

DNS-Server

DFS-Replikation

Kerberos-, Netlogon-, KDC-, LSA- und Replikationsereignisse

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:

Ereignis 4740;

aufrufender Computer;

Ereignisse 4771 bei Kerberos;

Ereignisse 4776 bei NTLM;

Ereignisse 4625 auf Quell- und Zielsystemen;

gespeicherte Windows-Anmeldeinformationen;

verbundene Netzlaufwerke;

geplante Aufgaben;

Windows-Dienste;

Anwendungen mit gespeichertem Kennwort;

Mobilgeräte und Mailprogramme;

VPN-Clients;

alte RDP-Sitzungen;

Skripte;

weitere Computer des Benutzers.

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:

letzte erfolgreiche Replikation;

Anzahl und Dauer der Fehler;

betroffene Verzeichnispartition;

Quell- und Ziel-DC;

DNS-Fehler;

RPC-Fehler;

Zugriffs- oder Vertrauensfehler;

Zeitabweichung;

Replikation von Benutzer- und Computerkontoänderungen;

Erreichbarkeit des PDC-Emulators;

SYSVOL- und DFSR-Zustand.

Mögliche Symptome eines Replikationsfehlers:

neues Kennwort funktioniert nur über bestimmte DCs;

Konto erscheint auf einem DC gesperrt und auf einem anderen nicht;

neues Benutzer- oder Computerkonto ist nicht überall vorhanden;

reparierter sicherer Kanal schlägt über einen anderen DC erneut fehl;

Gruppenmitgliedschaften unterscheiden sich;

Anmeldung funktioniert standortabhängig.

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:

ist das Clientsubnetz in Active Directory Sites and Services eingetragen?

ist es dem richtigen Standort zugeordnet?

besitzt dieser Standort einen erreichbaren DC?

antwortet ein entfernter DC schneller als der lokale DC?

verteilt das VPN das richtige AD-Subnetz und die richtigen DNS-Server?

sind die notwendigen Netze über den Tunnel erreichbar?

existieren unterschiedliche Regeln vor und nach der Benutzeranmeldung?

verwendet der Standort einen Read-Only Domain Controller?

darf der RODC die Anmeldeinformationen dieses Benutzers zwischenspeichern?

ist ein beschreibbarer DC erreichbar, wenn Kennwortänderung oder Kontosperrenbehandlung erforderlich ist?

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:

wird der richtige Zielcomputer angesprochen?

verwendet der RDP-Client gespeicherte alte Anmeldeinformationen?

ist das richtige Namensformat angegeben?

ist Network Level Authentication aktiv?

kann das Zielsystem einen DC erreichen?

ist der sichere Kanal des Zielsystems gültig?

besitzt der Benutzer das Recht zur Anmeldung über Remotedesktopdienste?

wird dieses Recht durch eine Verweigerungsrichtlinie überschrieben?

ist der Benutzer Mitglied der vorgesehenen lokalen oder domänenweiten Gruppe?

existiert bereits eine eingeschränkte oder getrennte Sitzung?

liegt Ereignis 4625 mit Logon Type 10 vor?

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:

Smartcard und Lesegerät;

Benutzerzertifikat;

Gültigkeitszeitraum;

UPN beziehungsweise Identitätszuordnung;

Zertifikatskette;

Sperrstatus und Erreichbarkeit der CRL- oder OCSP-Dienste;

KDC-Zertifikat des Domänencontrollers;

geeignete Zertifikatvorlage;

unterstützte Kryptografie;

Zeit;

Ereignis 4771 und PKINIT-Fehlercodes.

Bei Windows Hello for Business zu prüfen:

wurde PIN oder Kennwort gewählt?

ist das Gerät ordnungsgemäß registriert?

ist der Hello-Schlüssel vorhanden?

ist das TPM verfügbar?

stimmt der Vertrauensmodus der Organisation?

wurden Richtlinien oder Zertifikate verändert?

ist eine Onlineverbindung für den jeweiligen Vorgang erforderlich?

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:

Benutzerprofildienst kann das Profil nicht laden;

Profilpfad ist nicht erreichbar;

servergespeichertes Profil ist beschädigt;

lokaler Profildatenträger ist voll;

Berechtigungen des Profilordners sind fehlerhaft;

Gruppenrichtlinienverarbeitung hängt;

Anmeldeskript wartet auf eine nicht erreichbare Ressource;

Ordnerumleitung schlägt fehl;

Netzlaufwerk oder Druckerzuordnung hat ein Timeout;

Sicherheitssoftware blockiert den Sitzungsaufbau;

Windows lädt ein temporäres Profil.

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

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

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

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

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

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

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

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

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

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

Domänencontroller ermitteln
nltest /dsgetdc und Standortinformationen auswerten.

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

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

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

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

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

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

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

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

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

Hypothese formulieren
Erwarteten Befund und möglichen Gegenbeweis festlegen.

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

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

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

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:

die Domänenmitgliedschaft bestätigt ist;

DNS korrekt funktioniert;

ein geeigneter DC erreichbar ist;

die Zeit ausreichend synchronisiert ist;

das Computerkonto vorhanden ist;

Replikationsprobleme berücksichtigt wurden;

ein autorisiertes lokales Administratorkonto verfügbar ist;

Risiko und Rückweg dokumentiert wurden.

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:

Zugangsdaten dürfen nicht direkt in Klartext in einen Befehl geschrieben werden.

nltest /sc_verify, nltest /sc_reset und nltest /sc_change_pwd können den Vertrauenszustand verändern.

Auf Domänencontrollern gelten andere Reparaturverfahren.

Das Entfernen und erneute Hinzufügen zur Domäne ist eine letzte Maßnahme.

Eine Domänenneuanmeldung ohne Ursachenanalyse kann das Symptom nur vorübergehend beseitigen.

Bei wiederkehrenden Vertrauensfehlern müssen Snapshot-Verfahren, Klonprozesse, doppelte Computernamen, Replikation und Computerkennwortänderungen untersucht werden.

7.10.36 Verifikation

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

Computer ist weiterhin Mitglied der richtigen Domäne;

Client verwendet die vorgesehenen DNS-Server;

LDAP- und Kerberos-SRV-Einträge werden korrekt aufgelöst;

DC Locator findet einen geeigneten Domänencontroller;

Client ist dem richtigen AD-Standort zugeordnet;

erforderliche AD-Dienste sind erreichbar;

Zeitquelle und Zeitabweichung sind plausibel;

sicherer Kanal liefert ein erfolgreiches Ergebnis;

Benutzerkonto ist aktiviert und nicht gesperrt;

Anmeldung verwendet den richtigen Benutzer und die richtige Domäne;

Anmeldung erfolgt online gegen einen Domänencontroller;

ein Kerberos-TGT kann ausgestellt werden, sofern Kerberos vorgesehen ist;

keine neuen Fehler 4625, 4771, 4776, 3210 oder 5719 entstehen;

Benutzerprofil wird vollständig geladen;

Gruppenrichtlinien werden verarbeitet;

Anmeldeskripte werden abgeschlossen;

benötigte Netzressourcen funktionieren;

RDP funktioniert, wenn es zum ursprünglichen Fehler gehörte;

mehrere repräsentative Benutzer oder Clients funktionieren, wenn der Fehler größeren Umfang hatte;

temporäre Diagnoseänderungen wurden zurückgenommen;

Sicherheitsfunktionen wie NLA, Firewall und Zertifikatsprüfung bleiben aktiv;

Ursache, Maßnahme und Prävention wurden dokumentiert.

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

7.10.37 Präventionsmaßnahmen

redundante und überwachte Domänencontroller bereitstellen;

DNS-Dienste und AD-SRV-Einträge überwachen;

Clients ausschließlich mit vorgesehenen AD-DNS-Servern konfigurieren;

AD-Standorte und Subnetze vollständig dokumentieren;

VPN mit geeigneter DNS- und Routingkonfiguration bereitstellen;

bei Bedarf einen sicheren Voranmelde-VPN-Weg vorsehen;

Windows-Zeithierarchie überwachen;

PDC-Emulator und externe Zeitquelle dokumentieren;

AD-Replikation kontinuierlich überwachen;

Domänencontrollerereignisse zentral sammeln;

Kontosperren mit Quellcomputer auswerten;

Kennwortänderungen und gespeicherte Anmeldeinformationen berücksichtigen;

Computerobjekte nicht unkontrolliert löschen oder zurücksetzen;

VM-Snapshot- und Wiederherstellungsverfahren mit AD-Vertrauensbeziehungen abstimmen;

Computer nur über standardisierte Verfahren klonen;

doppelte Computernamen verhindern;

sicheren Kanal überwachen, ohne automatische unkontrollierte Reparaturen auszuführen;

lokale Notfalladministration nach Sicherheitsvorgabe gewährleisten;

Gruppenrichtlinien vor breiter Verteilung testen;

Profil-, SYSVOL- und DFSR-Zustand überwachen;

Zertifikatsablauf und Sperrprüfungsdienste bei Smartcard-Anmeldung überwachen;

Windows-Hello-Bereitstellung und Vertrauensmodell dokumentieren;

Sicherheitsprotokolle ausreichend groß dimensionieren;

Uhrzeiten aller Systeme zentral korrelierbar halten;

Runbooks für DNS-, DC-, Replikations- und Vertrauensfehler testen.

7.10.38 Typische Fehler bei der Diagnose

Die Meldung sofort als falsches Kennwort interpretieren.

Lokales Konto und Domänenkonto verwechseln.

UPN, DNS-Domäne und NETBIOS-Domäne gleichsetzen.

PIN und Domänenkennwort gleichsetzen.

Eine Cache-Anmeldung als erfolgreiche Online-Domänenanmeldung werten.

Nur den Domänennamen anpingen.

Einen erfolgreichen Ping als Nachweis der AD-Anmeldung betrachten.

Öffentliche DNS-Server auf einem Domänenclient eintragen.

DNS-Caches löschen, bevor die falsche Antwort dokumentiert wurde.

Nur TCP 389 prüfen und die übrigen AD-Abhängigkeiten ignorieren.

Einen erfolgreichen Test auf TCP 135 als vollständigen RPC-Nachweis betrachten.

UDP mit einem allgemeinen Porttest als sicher funktionsfähig einstufen.

Zeit nur optisch ablesen und die tatsächliche Abweichung nicht messen.

Ein Konto wiederholt testen und dadurch sperren.

Ein gesperrtes Konto entsperren, ohne die Sperrquelle zu ermitteln.

Das Kennwort vorsorglich zurücksetzen.

Gespeicherte alte Kennwörter in Diensten oder Aufgaben ignorieren.

nltest /sc_verify als rein lesenden Test verwenden.

Den sicheren Kanal reparieren, bevor DNS und Netzwerk funktionieren.

Test-ComputerSecureChannel auf einem DC wie auf einem Mitgliedscomputer interpretieren.

Den Computer sofort aus der Domäne entfernen.

AD-Replikation durch eine erzwungene Synchronisation „reparieren“, ohne den Fehler auszuwerten.

Nur einen Domänencontroller untersuchen.

Den verwendeten DC und Standort nicht dokumentieren.

Ereignis 4625 ohne Status, Substatus und Logon Type interpretieren.

Kerberos-Code 0x19 automatisch als Störung einstufen.

Kerberos-Tickets löschen, bevor sie dokumentiert wurden.

RDP-Fehler nur auf dem lokalen Client untersuchen.

NLA, Firewall oder Zertifikatsprüfung dauerhaft deaktivieren.

Profilfehler mit fehlgeschlagener Kennwortprüfung verwechseln.

Vor der Protokollsicherung neu starten.

Kennwörter oder vollständige Sicherheitsprotokolle ungeschützt weitergeben.

Nach der Maßnahme nur eine lokale oder zwischengespeicherte Anmeldung testen.

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