Intermittent Authentication Failures on Wired PC using Native Supplicant

[radhsing]

Hi All,

We have a deployment where some of the Wired Windows 7 PCs are facing Intermittent Authentication Failures in the recent weeks. The deployment was working fine for the past 2 months.

The wired machines stays at "authenticating" for some time and then get the error "Authentication Failed".

ISE Logs shows that Dot1x has failed and it has moved to MAB and MAC Address is not known to ISE.

One observation that we have is that there were some Security Patches installed on systems for Microsoft Windows recently. This has not been identified as the root cause as some of those PC connects automatically after sometime with the patches still installed. Most of the machines though have no problem connecting to the network post patch installation.

List of Windows Security Patches:

KB4474419

KB4489878

KB4490628

KB4489873

KB4489885

KB4486564

Let me know if someone has faced any similar issue.

[Mohammed al Baqari · Accepted solution]

Hi,

My advice to you that move to Cisco NAM because windows native supplicant
is very buggy and it took me months to get a working combination of
patches, network drivers and windows supplicant.

If you still want to continue with window supplicant, the easiest work
around is to have authentication open with deny ip any any ACL. Then DACL
override the deny ACL.

Also, make sure that the following patches are installed on all machines.
These are bug fixes to dot1x related

· KB 2481614

· KB 2491809

· KB 2494172

· KB 2736878

· KB 2835595

· KB 976373

· KB 980295

[radhsing]

Hi Mohammed,

Thanks a lot for the help. We will suggest the customer to get these KB installed on their machines.
Also, we saw the same issue in a windows 7 desktop also having NAM. What will you suggest the NAM can also cause authentication failure due to these issues in windows 7 machine ? Can we ask customer to check with Microsoft team for their machines not responding to dot1x , and not responding to eapol packets.

[paul]

Just a comment here.  I don't agree with the Windows supplicant is "very buggy" and you should go with NAM.  With over 100 ISE installs and probably over 1/2 million Windows devices doing Dot1x with Native supplicant without an issue, I don't have an issue with the Native supplicant.  I think I have used NAM on only 1 or 2 of my installs and it was driven by technical reasons (EAP-Chaining mostly).

Years ago in ISE 1.0 and wired 802.1x was just started to get adopted I would agree with that the Windows supplicant was buggy and we had to install hot fixes, but I rarely have to worry about that in my installs today.

[Mohammed al Baqari]

Hi Paul,

I think we have different experiences and you might be right in what you have faced. However, the way forward is using NAM because windows 7 is going EOS by Jan 2020 and clients have to go to Win10 to get MS support and security patches (no more patches starting from Jan 2020 for Win7). Having this said, windows 10 native supplicant stopped the support for MS-CHAPv2 as inner channel and support only EAP-TLS using certificates. To resume using MS-CHAPv2 as inner method which is very common with SSO deployments and personally prefer for AD integrations you need to have NAM. Otherwise you need to migrate your users to EAP-TLS to continue the use of Win10 native supplicant. I have seen workarounds to hijack the registry in Win10 but MS won't support that. 

**** Please remember to rate useful posts 

[paul]

Can you post the link stating that Microsoft stopped supporting MS-CHAPv2 as the inner method for PEAP authentication on Windows 10?

[Colby LeMaire]

What the gentleman is referring to with Windows 10 not supporting MS-CHAPv2 is only an issue when using Credential Guard.  With Credential Guard enabled, MS-CHAPv2 won't work.  You have to use EAP-TLS.  If you need PEAP with MS-CHAPv2, then you can disable Credential Guard.

[Colby LeMaire]

I also agree with you @paul that the native supplicant works just fine.  I too try to stay away from NAM because of the added complexity and there is rarely a true need to authenticate the user on top of the machine.  I stay away from EAP-Chaining and user authentication unless there is a real reason to differentiate access based on who the user is.