Weird 802.1x EAP-TLS Behavior with Windows XP SP3
I'm currently busy with several 802.1x implementations in corporate networks, and in one of those environment I get the strangest behavior in regards to the authentication process.
In this particular case I use a Microsoft 2008 Active Directory. Mandatory for distributing the wired network adapter settings in regards to 802.1x. The clients are a mix of Windows XP (SP1 and SP3) clients and some newer and/or exotic operating systems. The authentication mechanism of choice is EAP-TLS with dynamic VLAN assignment. The RADIUS server used is the Cisco Secure ACS v5.x appliance.
During the authentication process of the XP SP3 PC's I saw that the first authentication attempt was made with the PEAP mechanism. Since PEAP isn't allowed, the authentication mechanism failed. About a minute and twenty seconds later the PC started another dot1x authentication sequence. This time using EAP-TLS, and the PC got access to the network.
We compared this to the behavior of the XP SP1 PC's, and saw that these machines authenticated correctly. EAP-TLS as first, and only authentication mechanism.
Booting both PC's (SP1 and SP3) at the same time revealed that the SP3 version took about 1.5 minute longer to get proper network access, which is not acceptable.
The SP3 PC's are configured correctly (tried it by hand and through a Group Policy), but for some weird reason, the initial dot1x authentication defaults to PEAP instead of EAP-TLS. This behavior is confirmed by verifying the Windows eventlog on the XP3 PC's.
UPDATE: I found this link. Which didn't make me too happy..... "It's by design"
UPDATE2: The link from the earlier update made us look a bit further. This is what we found out;
When a Windows XP SP3 PC has 802.1x configured before its joined to the domain, it remembers these settings in a/the local (default) policy. When a group policy (Windows 2008 Active Directory) is applied to the PC with 802.1x settings, it applies the local policy first during the boot process (with different settings that the domain policy), and directly afterward, the group policy from the domain is applied. This is what's causing the strange behavior.
In my case, the original Windows machine (non-domain member) was configured with PEAP authentication (during a testing period of some sort), and the Active Directory Group Policy was set to EAP-TLS. So when the machine started, it initiated the PEAP authentication first. During the PEAP initiation the group policy was applied, and EAP-TLS authentication was started. The result was that I got time-outs, and that it took the machine almost 1.5 minutes longer before it had proper network access.
Most of this can be tracked in the event-viewer on the Windows machine. The process to filter on is the Dot3svc process. (images etc. will be added later on).
This made us look at the local/default policy on the machine. Fiddling with the settings, we were able to disable 802.1x in the default policy (remove machine from the domain, change settings, and re-join). This left us with a proper authentication process without warnings, and/or failures in the logging. Also, the Dot3svc messages in the eventlog were minimal.
Looking back at the Windows XP SP1 machines (which worked properly); it could be that these machines never had a 802.1x confiugarion in the first place. So there is no (old) default policy to screw things up.
I will update this post later, when I have more on this phenomenon.
Reader Comments (1)
Hi,
I know this topic is a bit old but I've got the same issue now. How do I find the 802.1x Configuration in the local/default policy? Services and the Wired 802.1X Configuration are not included in the local GPO.
Cheers,
Michael