This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
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:
Let me know if someone has faced any similar issue.
Solved! Go to Solution.
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.
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
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.
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.