Die 802.1x Authentifizierung scheitert und der Client antwortet nicht mehr auf EAP Anfragen

(ursprüngliche Version verfaßt am 24.11., Korrektur am 21.12.)

Hallo, hier ist erneut Frank Hennemann aus dem Netzwerk Team mit einem Gastbeitrag. Wieder handelt es sich um das Thema 802.1x Authentifizierung. Was 802.1x ist und wie dieses funktioniert, hatte ich bereits in meinem letzten Blog Beitrag beschrieben, den Ihr hier finden könnt.
Dieses Mal eignet sich der Blog vom deutschen Active Directory Team wieder sehr gut für einen Beitrag zum gleichen Thema, da man die Ursachen für das folgende Problem primär im Group Policy Bereich vermuten könnte und nicht in den 802.1x Komponenten, was aber der Fall ist.

Problem:

Windows Clients führen eine Wired 802.1x Authentifizierung durch und werden über eine Gruppenrichtlinie konfiguriert. Allerdings kann man feststellen, dass unter bestimmten Umständen die 802.1x Authentifizierung scheitert. Dieses geschieht normalerweise beim Booten des Clients. In Einzelfällen ist jedoch der Fehler auch schon aufgetreten, wenn man den Dot3svc Dienst im laufenden Betrieb neugestartet hat.
Wenn man sich die Ursache genauer anschaut (z.B. anhand eines Netzwerktraces oder der Radius Server Logs), stellt man fest, dass der Client nicht die Authentifizierungsparameter nutzt, welche man in der Gruppenrichtlinie eingestellt hat. Stattdessen verwendet der Windows Client unter Umständen eine ganz andere EAP Authentifizierungsmethode oder führt ungewollt eine 802.1x Re-Authentifizierung des Benutzers durch, obowhl man dieses in der Gruppenrichtlinie deaktiviert hatte. Dieses führt dazu, dass die Clients im Fehlerfall die 802.1x Authentifizierung für 20 Minuten aussetzen und nicht auf EAP Request Identity Pakete antworten.

Ursache:

Seit Windows XP SP3, Windows Vista RTM und Windows 7 RTM werden mehrere Profile für die Wired 802.1x Authentifizierung hinterlegt.

• Interface Profil: Dieses wird durch eine manuelle Konfiguration der 802.1x Parameter erstellt. Eine manuelle Konfiguration ist zum Beispiel über netsh.exe (netsh lan add profile file=name.xml) möglich.
• Policy Profil: Dieses Profil wird dann erstellt, wie der Name es schon vermuten lässt, wenn eine 802.1x Gruppenrichtlinie angewendet wird.
• Default Profil: Dieses Profil ist bereits in Windows enthalten und beinhaltet Standard Einstellungen, welche seit Windows XP SP3 PEAP-MSCHAPv2 sind. Des weiteren wird sowohl eine Maschinenauthentifizierung, als auch eine Benutzer Authentifizierung durchgeführt.

Aufgrund eines Timing Problems kann es sein, dass Windows XP, Windows Vista und Windows 7 das Default Profil verwenden, obwohl ein Policy Profil vorhanden ist. Wenn die in dem Default Profil hinterlegten Einstellungen nicht mit den GPO bzw. Radius Server Einstellungen übereinstimmen, wird der Radius Server die Authentifizierungsanfrage ablehnen und ein ‚Radius Access Reject‘ Paket an den Switch bzw. ein EAPOL Failure an den Client senden. Diese fehlschlagende Authentifizierung kann dazu führen, dass der 802.1x Client für 20 Minuten keine EAPOL Authentifizierungsanfragen (EAP Request Identity) mehr beantwortet. Die Tatsache, dass der Client im Fehlerfall für 20 Minuten keine EAPOL Anfragen mehr beantwortet, ist by-Design und in dem folgenden KB Artikel dokumentiert:
957931  A Windows XP-based, Windows Vista-based, or Windows Server 2008-based computer does not respond to 802.1X authentication requests for 20 minutes after a failed authentication, https://support.microsoft.com/default.aspx?scid=kb;EN-US;957931

Bei Windows XP und Windows Vista kann man den Hotfix 957931 einspielen und den Registry Key BlockTime auf 1 setzen, um die negativen Auswirkungen zu minimieren.
Für Windows 7 Clients kann man eine Windows Server 2008 R2 Group Policy verwenden und dort den entsprechenden Wert setzen. Jedoch kann man die Funktionalität nicht gänzlich ausschalten.

Eine weitere Möglichkeit, die Auswirkungen zu minimieren ist, die maximale Anzahl der Fehlversuche zu erhöhen. Dieses geschieht z.B. mittels Group Policy und legt fest, nach wie vielen fehlgeschlagenen Versuchen ein Client die 802.1x Authentifizierung aussetzt, also die BlockTime anwendet.

Der Standardwert beträgt 1, was sehr restriktiv ist und im oben beschriebenen Fehlerfall zu einem Verlust der Netzwerkkonnektivität führt. Welcher Wert sinnvoll ist, muss individuell abgewogen werden.

Lösung:

Eine Lösung hat man noch nicht erreicht, sondern nur die Symtome gelindert.

Was also tun, damit der Client das Policy Profil anwendet und gar nicht erst in die BlockTime „fällt“? Die Antwort ist wie folgt: Das Problem tritt nur auf Maschinen auf, welche nur ein Default- und ein Policy-Profil besitzen, aber eben kein Interface-Profil.
Für Windows 7 wird derzeit ein Hotfix entwickelt, welcher nach aktuellen Planungen im Februar oder März 2011 zur Verfügung stehen wird. Aufgrund des Support Lifecycles wird für Windows XP kein Bugfix veröffentlicht werden. Windows XP befindet sich im Extended Support, somit werden von Microsoft nur noch sicherheitsrelevante Fixes, aber keine funktionalen Bugfixes mehr zur Verfügung gestellt.
Die Lösung für Windows XP und Windows Vista ist, solch ein Interface Profil zu erstellen. Zuerst muß man jedoch die 802.1x Gruppenrichtlinie deaktivieren, damit die Einstellungen überhaupt mittels netsh.exe importiert werden können.
Vorsicht!! Sobald der betroffene Client kein 802.1x Policy mehr hat, wird er das Default Profil anwenden. Wahrscheinlich scheitert dann die Authentifizierung und der Client hat keine Konnektivität mehr. Dieses kann im schlimmsten Fall zu einem Henne-Ei Szenario führen: Man braucht eine Konnektivität, um z.B. eine Policy mit dem netsh.exe Skript herunterzuladen und man muss das Skript herunterladen bzw. anwenden, um eine Konnektivität zu erlangen. Wer also nicht schon immer eine Sehnsucht hatte, alle seine Benutzer mittels Turnschuhadministration zu besuchen, muß sicherstellen, dass auf den Clients bereits die xml Datei und das Skript lokal vorliegen, wenn man die 802.1x Gruppenrichtlinie deaktiviert.

Der nächste Abschnitt beschreibt, wie man ein funktionierende 802.1x Konfiguration in eine xml Datei exportiert und diese auf den betroffenen Clients wieder importiert, um ein Interface Profil zu generieren.

Der folgende Befehl erstellt eine oder mehrere XML Dateien, abhängig davon wieviele NIC’s installiert sind.
netsh lan export profile folder=%windir%
Diese xml Datei muss nun auf die betroffenen Clients kopiert werden. Darüber hinaus muss jedoch noch ein Skript erstellt und auch auf die Clients kopiert werden. Der Name des Skripts kann zum Beispiel netshimport.bat lauten und sollte den folgenden Befehl beinhalten:
netsh lan add profile file=c:\filename.xml
Um das Skript problemlos ausführen zu können, sollte man das Sysinternals Tool psexec.exe verwenden. Somit beugt man eventuellen Berechtigungsproblemen vor. Dieses Tool kann man unter der folgenden Adresse herunterladen und sollte entpackt und auf die Clients kopiert werden https://download.sysinternals.com/Files/PsTools.zip.

Um die Batch Datei auf den Clients auszuführen, bestehen natürlich viele Möglichkeiten. Ich führe hier zwei Möglichkeiten auf, die funktionieren und mit den Boardmitteln von Windows umzusetzen sind:

A) Verwendung des Run(Once) Registry Keys
B) Erstellung eines Scheduled Tasks

Zu A)
Der Run bzw. der RunOnce Registry Key ist in dem folgenden KB Artikel beschrieben:
314866  A definition of the Run keys in the Windows XP registry, https://support.microsoft.com/default.aspx?scid=kb;EN-US;314866

Folgender Registry Key muss auf den Clients erstellt werden:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
Type: Reg_SZ
Name: FreiwählbarerName
Wert: C:\psexec /accepteula -s -i c:\netshimport.bat

Bitte beachten: Bitte den Pfad zu dem Tool psexec.exe und der xml Datei anpassen.

Wie oben beschrieben sollte der Inhalt der Batch Datei netshimport.bat folgenden Inhalt haben
netsh lan add profile file=c:\filename.xml

Zu B)
Die Vorgehensweise ist sehr ähnlich wie bei Punkt A. Statt des Run(Once) Registry Keys wird ein scheduled task erstellt, welcher die gleiche Batch Datei ausführt.
Ein scheduled task kann zum Beispiel über entweder die Systemsteuerung des Windows Clients oder über das Kommandozeilen Tool schtasks.exe erstellt werden. Eine sinnvolle Option bei der Erstellung des scheduled tasks ist, die Ausführung nach der Anmeldung des Benutzers zu starten.
Erneut müssen folgende Dateien auf die Clients vorher verteilt werden: psexec.exe, netshimport.bat und die exportierte xml Datei, welche auf den betroffenen Clients importiert werden soll.

Symptome:

Hier nun ein paar Logauszüge, damit man eindeutig bestimmen kann, dass man in den beschriebenen Fehler reingelaufen ist, nämlich dass der Client das Default Profil und nicht das Policy Profil anwendet. Diese Auszüge stammen von einem Windows XP SP3 Client, auf dem mittels „netsh ras set tra * ena“ das entsprechende Logging gestartet wurde. Die Logs werden in dem Verzeichnis %windir%\tracing abgespeichert.

Das Problem ist, dass nicht die Reihenfolge garantiert werden kann, in welcher der dot3svc Dienst startet und die Group Policy angwendet wird.

[2268] 01-14 12:31:19:721: [IntfApplyGroupPolicySettings
<< Die Policy Einstellungen werden angewendet durch einen Call vom gpsvc in den dot3svc Dienst
[2360] 01-14 12:31:19:721: [AceGetNextState (current state = Profile change, trigger = Connect
<< Der Download der Policy führt dazu, dass eine Verbindung initiiert wird.
[2360] 01-14 12:31:19:721: AceGetNextState (next state = BeginConnecting)]
[3548] 01-14 12:31:19:737: Port(1): ProcessOneXEvent: Event [StartAuth]
[3548] 01-14 12:31:19:799: Port(1): EapBeginSession called for eap type 25
<< Als EAP Typ wird Typ 25, also PEAP benutzt, welches dem Default Profil entspricht.
[2208] 01-14 12:31:19:846: [AceGetNextState (current state = Connecting, trigger = Load Profile
<< Hier wird das Default Profil mittels eines separaten Aufrufs auf dem Interface angewendet.
[2208] 01-14 12:31:19:846: AceGetNextState (next state = Profile change)]
[2208] 01-14 12:31:19:846: [AceGetNextState (current state = Profile change, trigger = Connect
<< Die Änderung des Profils führt dazu, dass erneut eine Verbindung getriggert wird.
[2208] 01-14 12:31:19:846: AceGetNextState (next state = BeginConnecting)]
[2360] 01-14 12:31:19:878: Port(2): ProcessOneXEvent: Event [StartAuth]
<<Hier wird nun das Policy Profil und somit die korrekten EAP Einstellungen angewendet
[2360] 01-14 12:31:19:878: Port(2): EapBeginSession called for eap type 13
<<Man kann sehen, dass dieses Mal EAP-TLS anstatt PEAP verwendet wird.

In dem Applikationseventlog des Client findet man das Event 15506, wenn die BlockTime angewendet wird. Des weiteren enthält dieses Event auch den angwendeten Wert.

Ich hoffe, dass dieser Artikel hilft, die Ursache dieses Problems besser zu verstehen und alle Lösungmöglichkeiten verständlich aufzeigt. Über Lob, Tadel, Fragen oder auch ein generelles Feedback würde ich mich sehr freuen.
Euer Frank