Getting past intermittent/unexplained 802.1x problems on Windows 7

[Vivek Santuka]

Very often 802.1x deployments run into Windows 7 machines that will exhibit erratic authentication problems such as:

• Not able to authenticate when coming back from sleep or hibernation
• Using the wrong protocol on boot up
• Not able to authenticate after a single authentication failure

Such problems often boil down to one or more of the following problems :

Problem Summary	KB
Win 7 connected behind IP Phones will not authenticate after waking up from sleep or hibernation	KB 976373
Win 7 stops responding to 802.1x after first authentication fails	KB 980295
Win 7 selects a protocol different from what the GPO states. (GPO is configured for EAP-TLS but PEAP is used because local config had PEAP selected)	KB 2481614
Win 7 does not prompt for 802.1x credentials to some users on a shared PC	KB 2491809
Win 7 does not prompt for 802.1x credentials	KB 2835595
Win 7 cannot authenticate if a valid and an invalid certificate is present	KB 2494172
Win 7 selects wrong certificate for a machine migrated across two forests	KB 2769121
Win 7 Authentication fails intermittently	KB 2736878

So if you have a 802.1x implementation or are considering it in a Windows 7 environment, these hotfixes should be pushed out to the endpoints to avoid problems with authentication. Some of these are not part of a Service pack so, they need to be downloaded and pushed out specifically.

On a side note, some laptops manufactured in 2013/2014, especially from HP, require a device driver upgrade to authenticate correctly.

[minkumar]

Excellent Document!!!

[mistr]

Thanks for the info Vivek. Are you able to provide any links or hp references to the laptop device driver issue?

Thanks

Mike

[Lisa Latour]

Hi Mike - you may also want to ask your question during out Expert Q&A Session, With Javier Henderson, This is an opportunity to learn and ask questions about how to configure and troubleshoot 802.1X

https://supportforums.cisco.com/discussion/12301381/ask-expert-configuring-and-troubleshooting-8021x-open-questions

[Vivek Santuka]

Mike,

Unfortunately I did not note the version of the bad driver so am unable to provide any details. I do know that the "fixed" version was released close to April 2014

[Pranav Gade]

Hi Vivek Santuka,

Thanks for the information. I am also facing somewhat  same issue  in certificate authentication. 

We are using certificate authentication with windows native supplicant but logoff machine its not re-initiating dot1x request only its happing when we restart the machine.

Can you help me for the same..?

Thanks and advance

[mistr]

Hi Pranav,

          I had the same symptom with many of our clients. I saw this behaviour happening intermittantly. A reboot fixed it. I sniffed the traffic and I was seeing that the dot1x supplicant on the client just seemed to stop responding. After a LOT of digging we eventually paid microsoft to look at the problem. They identified this patch which needed to be installed:

https://support.microsoft.com/en-us/kb/2999237

Applying this patch fixed the issue 100% of the time for me and it has not reoccured since!

We have a mix of windows 8.0 and windows 7.1 clients. I can't remember now if this issue was specific to windows 8 for us but suggest you take a look at this. Also make sure NIC drivers are up to date.

Regards

Mike

[kumar-sumit]

This is the Best document i have ever seen for all common 802.1X problems and their fixes.

Gr8 work Vivek and Thank you so much for creating this document.

[Aaron Woland]

+1

I reference this document constantly!

-Aaron

[mperreault1980]

Glad you posted the note about 2013/14 HPs. We had many HP Probook 640 notebooks that were having all sorts of problems authenticating and upgrading the Intel NIC drivers seems to have helped.

[michael.schloegl1]

just read the following KB Article 980295 "No response to 802.1X authentication requests after authentication fails on a computer that is running Windows 7 or Windows Server 2008 R2"

is it possible that this issue has reoccured somehow, as we're pretty well above PreSP1 and facing this issue in our current 802.1X environment ?

1.) Client is booting from cold&dark over WLAN-NIC, 802.1X authentication is done, Client is able to send data over the Network

2.) AntiVirus is issuing a configuration Change that forces NAP to do a 802.1X re-authenticate

3.) 802.1X Re-Auth is initiated by Win7 Client and always fails to respond to the "Network" at EAP-Request Identifier 65.

4.) after several tries to get an answer from the Client to this Request the "Network" closes the communication

5.) Client is searching for given SSID, re-finds it, connects, is doing the 802.1X Procedure again, and ends with EAP-Success from "Network"

6.) whole day working without problems

the problem is that between these 2-3 Minutes (from step 2 to step 5) all programs that are automatically started  eg Outlook, Lync fail, because over WIFI !!! the communication to the "Network" is blocked imediately after the Win7 Client initiates the EAP-Start - and fails to re-authenticate as the Win7 Client refuses to answer the network correctly. Only after "Network" closes the communication and WIN7 Client is re-connectiong to the WIFI a completely new 802.1X authentication Request succseeds in an "EAP-Success"

[Johannes Luther]

Perfect document. Thanks for the collection. Nevertheless I have one tiny question regarding Windows 7 ignoring EAP identity requests after one failed authentication (for 20 minutes)

I guess KB980295 ("Win 7 stops responding to 802.1x after first authentication fails") and KB976373 ("Win 7 connected behind IP Phones will not authenticate after waking up from sleep or hibernation") are addressing this issue, right?

From my point of view KB976373 is a dirty workaround, because the ignoring time of EAP identity packets of 20 minutes can be modified. The result is, that the client initiates 802.1X authentication more frequently (depending on the timer).

The timer can be modified with a registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\dot3svc
Name: BlockTime; DWORD (32-Bit); Value: blocking period of 802.1X attempts in minutes

or with the netsh shell

netsh lan set blockperiod value=<blocking period of 802.1X attempts in minutes>

When disabling this blocking period timer (value of 0), the client constantly tries to authenticate via 802.1X. This fills up switch logs and authentication server logs pretty quickly.

So here's my question:

Did anybody manage, that a Windows 7 client just responds to all EAP identity requests from the switch in a reliable way. Normally I would expect this from KB 980295, but this did not change the observed behavior.

[Luca Utili]

Very good document. I was able to solve all my problems with win7 clients. Do you know if exist a similar reference list for Win10 clients?

[josedunet]

Exacte, Do you know if exist a similar reference list for Win8 clients also ?

Thanks.

[Alex Martin]

Johannes, did your get this working by using the updates listed above or did you use your workaround setting the blocking period?  I'm my testing, I am using ISE 2.1 and the Windows 7 supplicant for 802.1X with EAP-TLS with both Machine and User setup so I see the machine auth then the user after they log in successfully.  This all works great unless it's the first time a new user logs on to that workstation.  The user certificate does get requested and installed on the machine during the initial login, but during the process of logging in, the switch sends new EAPOL request, identity packet, but the Windows 7 supplicant will not send back a response, identity packet.  I've tried installing all of the relevant updates listed in the OP, but to no avail.  I haven't updated drivers.  Any help is appreciated!

Alex

[Johannes Luther]

Hi Alex,

first of all I'm just using machine auth... I'm afraid of the additional problems when changing the user context :)

Besides using the hotfixes above, you need to tweak the blocking timer (see above), to convince Windows to talk to a dot1x switchport after a failed authentication and avoid the long waiting time.

Nevertheless I didn't manage it, that a Win7 client answers to EAPoL requests from a switch. The client always want to be the EAPoL initiator (which is pretty crappy in my eyes)