Die 802.1x Authentifizierung scheitert, wenn das Maschinenpasswort geändert wurde

Hallo, hier Frank aus dem deutschen Netzwerk Support Team mit einem DEDS Gastbeitrag zum Thema 802.1x, da das unten beschriebene Problem regelmäßig im Rahmen von Support Anfragen ans uns herangetragen wird und weil der bereits veröffentlichte KB Artikel
904943 Authentication may not succeed when you use PEAP-MS-CHAP-v2 as the authentication method for an 802.1X connection in Windows Vista, Windows XP, Windows Server 2003, and Windows 2000; https://support.microsoft.com/default.aspx?scid=kb;EN-US;904943zusätzliche Hintergrundinformationen vertragen kann.

Zunächst ein kurzer Überblick zu 802.1x:
Wenn Windows Clients an einem IEEE 802.1x Switch Port angeschlossen werden, erhalten sie nur Zugriff auf das Netzwerk, wenn eine erfolgreiche Authentifizierung stattgefunden hat.
Dazu ein typischer Aufbau:

Normalerweise findet zuerst eine Authentifizierung des Computerkontos statt. Sobald sich ein Benutzer am Client anmeldet, wird eine Authentifizierung des Benutzers initiiert. Man kann für die 802.1x Authentifizierung zwischen verschiedenen EAP Methoden wählen. Die von Windows Clients unterstützen und von Microsoft mitgelieferten Methoden sind EAP-TLS, PEAP-TLS und PEAP-MCHAPv2. Für die beiden ersten Methoden benötigt der Client ein entsprechendes Zertifikat, wobei PEAP-MCHAPv2 eine Authentifizierung des Clients über dessen Passwort durchführt. Nur der Radius Server benötigt ein Zertifikat für die gegenseitige Authentifizierung.

Des Weiteren kann man die Konfiguration des Clients so anpassen, dass nur eine 802.1x Authentifizierung des Computerkontos durchgeführt wird, aber eben keine (anschließende) Authentifizierung des Benutzers. Diese Änderung der Standardkonfiguration ist sowohl Client- als auch Serverseitig möglich. Hierzu die entsprechenden Artikel:
949984 Changes to the 802.1X-based wired network connection settings in Windows XP Service Pack 3; https://support.microsoft.com/default.aspx?scid=kb;EN-US;949984 
929847 How to enable computer-only authentication for an 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack 3; https://support.microsoft.com/default.aspx?scid=kb;EN-US;929847

Problem
Windows Clients ändern auch offline das Kennwort des Computerkontos. Wenn dieses offline geschieht und diese Änderung nicht mit einem Domain Controller synchronisiert wurde, schlägt die nachfolgende 802.1x Maschinenauthentifizierung fehl. Es handelt sich um die gleichen Probleme, wie sie in KB904943 beschrieben sind.
Wenn die 802.1x Authentifizierung des Benutzers deaktiviert wurde, kommt es zu folgendem Problem: Man benötigt einen Netzwerkzugriff, um die Passwortänderungen mit einem Domain Controller zu synchronisieren und man benötigt ein synchronisiertes Passwort, um Netzwerkzugriff zu erhalten. Ein klassisches Henne-Ei Problem.
Bei einer normalen Domänen Anmeldung ohne 802.1x wird auch das vorher eingestellte Passwort als Fallback Mechanismus zur Authentifizierung verwendet. Dieses trifft aber nicht auf eine 802.1x Authentifizierung zu.

Lösungsmöglichkeiten
Es gibt vier verschiedene Methoden, dieses Problem zu adressieren, wovon zwei Möglichkeiten in dem oben erwähnten Artikel KB904943 aufgeführt sind:

1. Einsetzen der Benutzerauthentifizierung
2. Einsetzen von Clientseitigen Zertifikaten
3. Erhöhung des Passwort Wechsel Intervalls
4. Migration auf Windows 7

Zu 1. Einsetzen der Benutzerauthentifizierung:
Selbst wenn die 802.1x Maschinenauthentifizierung vorher gescheitert ist, würde eine erfolgreiche 802.1x Authentifizierung im Kontext des Benutzers den Switch Port aufschalten. Somit könnte der Netlogon Dienst anschließend das Passwort der Maschine mit einem Domain Controller abgleichen. Die nächste 802.1x Maschinenauthentifizierung würde dann wieder erfolgreich sein.

Zu 2. Einsetzen von Clientseitigen Zertifikaten:
Wie oben beschrieben, verwendet ein 802.1x Client ein Zertifikat anstatt eines Passworts, wenn als EAP Methode EAP-TLS oder PEAP-TLS eingesetzt wird. Somit wäre eine Änderung des Computer Kennworts für die 802.1x Authentifizierung unerheblich, auch wenn dieses geschehen sollte, während keine Verbindung zu der Domäne besteht.

Zu 3. Erhöhung des Passwort Wechsel Intervalls:
Es gibt die Möglichkeit, zum Beispiel mittels einer Gruppenrichtlinie die Passwortänderungsintervalle auf einen sehr hohen Wert zu setzen. Man könnte den Wert auf den Maximalwert stellen und eine Passwortänderung forcieren, so dass die 802.1x Maschinenauthentifizierung für die nächsten 999 Tage nicht mehr scheitern würde, jedenfalls nicht aus den oben beschriebenen Gründen.
Anmerkung: Dieser Ansatz wird hier der Vollständigkeit halber aufgeführt, allerdings geschieht der Einsatz auf eigenes Risiko. Die von Microsoft empfohlenen Methoden sind für Windows XP unter 1.) und 2.) aufgeführt.

Zu 4. Migration auf Windows 7:
In Windows 7 wurde die Funktionalität der Domänenpasswortänderung angepasst, so dass dieses Problem nur noch in extrem seltenen Fällen bzw. nur noch theoretisch passieren könnte.
Hier ein paar Details zu der Änderung:
Ein Windows 7 Client kontaktiert den DC, bevor der Netlogon Dienst ein neues Passwort generiert. Somit ist sichergestellt, dass ein Windows Server erreichbar ist und die Änderung synchronisiert werden kann. Sollte es sich um Windows Server 2008 R2 handeln, kann zusätzlich der Secure Channel verifiziert werden, bevor diese Operation durchgeführt wird. Nur wenn dieses erfolgreich ist, wird die Änderung durchgeführt.
Es kann nur noch dann zu den oben beschriebenen Problemen kommen, wenn der Domain Controller zwischen diesen beiden Aufrufen abstürzt bzw. nicht mehr erreichbar ist. Das Zeitfenster ist natürlich entsprechend klein.

Datenanalyse
Um das Verhalten näher zu untersuchen, kann man auf dem Client und dem Radius Server das Netlogon Log einschalten und zusätzlich auf dem Client noch das RASCHAP Logging mit NETSH.
Das Netlogon Log kann wie folgt erstellt werden:

-Starte eine cmd.exe Eingabeaufforderung
-Führe folgenden Befehl aus: nltest /dbflag:0x2080ffff
-Dieses erstellt das netlogon.log in %Windir%\Debug; also meisten C:\Windows\Debug
-Abschließend kann das Logging durch den folgenden Befehl deaktivieren werden: nltest /dbflag:0x0

Weitere Informationen dazu siehe Artikel KB 109626 Enabling debug logging for the Net Logon service; https://support.microsoft.com/default.aspx?scid=kb;EN-US;109626

Dazu noch das RASCHAP Logging am Client:

-Aktiviere das Logging durch die Eingabe von “netsh ras set tracing * enabled” in einer Eingabeaufforderung
-Die Logs sind in %windir%\tracing
-Abschließend kann das Logging durch den folgenden Befehl deaktivieren werden: netsh ras set tracing * disabled

Nun zu den Symptomen und Fehlern in den Logs an einem Windows XP Client, wenn das Problem auftritt:
Client Netlogon Log zum Zeitpunkt der Passwortänderung:

06/27 13:00:30 [MISC] NetpDcGetName: DOMAIN similar query failed recently 0
06/27 13:00:30 [CRITICAL] DOMAIN: NlDiscoverDc: Cannot find DC.
06/27 13:00:30 [CRITICAL] DOMAIN: NlSessionSetup: Session setup: cannot pick trusted DC
06/27 13:00:30 [MISC] Eventlog: 5719 (1) "DOMAIN" 0xc000005e c000005e ^.… <== hier sollte Netlogon Event 5719 im System Eventlog erscheinen
...
06/27 13:00:30 [MISC] NetpDcGetName: DOMAIN similar query failed recently 10
06/27 13:00:30 [MISC] DsGetDcName function returns 1355: Dom:DOMAIN Acct:(null) Flags: DS BACKGROUND NETBIOS RET_DNS  <== Fehler: ERROR_NO_SUCH_DOMAIN

06/27 13:00:30 [SESSION] DOMAIN: NlSetStatusClientSession: Set connection status to c000005e 06/27 13:00:30 [SESSION] DOMAIN: NlSessionSetup: Session setup Failed
06/27 13:00:30 [INIT] Started successfully
...
06/27 13:16:27 [CRITICAL] NetpDcGetNameNetbios: DOMAIN: Cannot NlBrowserSendDatagram. (1C) 53 <== Fehler: ERROR_BAD_NETPATH

06/27 13:16:27 [CRITICAL] NetpDcGetName: DOMAIN: IP and Netbios are both done.
06/27 13:16:27 [CRITICAL] DOMAIN: NlDiscoverDc: Cannot find DC.
06/27 13:16:27 [CRITICAL] DOMAIN: NlGetAnyDCName: Discovery failed c000005e 06/27 13:16:27 [CRITICAL] DsrGetSiteName: NlGetAnyDCName failed. Returning site '(null)' from local cache.
06/27 13:16:27 [MISC] DsGetDcName function called: Dom:(null) Acct:(null) Flags: IP TIMESERV AVOIDSELF BACKGROUND
06/27 13:16:27 [DNS] Cache: DOMAIN (null): Found existing domain cache entry
06/27 13:16:27 [MISC] NetpDcGetName: DOMAIN similar query failed recently 10 06/27 13:16:27 [MISC] DsGetDcName function returns 1355: Dom:(null) Acct:(null) Flags: IP TIMESERV AVOIDSELF BACKGROUND
06/27 13:16:29 [SESSION] I_NetLogonGetAuthData: (null) DOMAIN
06/27 13:16:29 [CRITICAL] I_NetLogonGetAuthData: DOMAIN: failed C000005E <== Fehler: STATUS_NO_LOGON_SERVERS

Client RASCHAP Log bei späterer Anmeldung:

[1116] 06-27 13:23:19:852: Message received...
04 0A 00 34 45 3D 36 39 31 20 52 3D 31 20 43 3D |...4E=691 R=1 C=| <== 691 <== Fehler: ERROR_AUTHENTICATION_FAILURE
[1116] 06-27 13:23:19:852: GetInfoFromFailure...
[1116] 06-27 13:23:19:852: 'C=' challenge provided,bytes=16...
7F 13 4E F6 B5 52 B6 76 DD 7C C8 31 E0 2B EA 70 |.N..R.v.|.1.+.p|
[1116] 06-27 13:23:19:852: GetInfoFromFailure done,e=691,r=1,v=3
[1116] 06-27 13:23:19:852: Retry :| ex=11 ts=11
[1116] 06-27 13:23:52:879: EapMSChapv2End
[1116] 06-27 13:23:52:879: ChapEnd

Radius Server Netlogon Log:

06/27 13:23:20 [MISC] DOMAIN: DsGetDcName function returns 0: Dom:DOMAIN Acct:(null) Flags: DSP NETBIOS RET_DNS
06/27 13:23:20 [LOGON] DOMAIN: SamLogon: Network logon of DOMAIN\COMPUTER$ from Entered
06/27 13:23:20 [LOGON] DOMAIN: SamLogon: Network logon of DOMAIN\COMPUTER$ from Returns 0xC000006A <== Fehler: STATUS_WRONG_PASSWORD 

Weitere Informationen zum Thema IEEE 802.1x sind sehr gut über folgenden Technet Eintrag zusammengestellt:
Wired Networking with 802.1X Authentication; https://technet.microsoft.com/en-us/network/bb545365.aspx

So, nun hoffe ich, ein paar Schleier zum Thema 802.1x gelüftet zu haben – und bei dem schlechten August-Wetter ruhig auch mal an das Thema herantrauen…

Damit viel Erfolg, Frank