NAC EndPoint stopped responding to ISE

[hennie001]

Please advise what causes an EndPoint to stop responding to Cisco ISE?

Event	5411 Supplicant stopped responding to ISE
Failure Reason	12931 Supplicant stopped responding to ISE after sending it the first EAP-TLS message
Resolution	Verify that supplicant is configured properly to conduct a full EAP conversation with ISE. Verify that NAS is configured properly to transfer EAP messages to/from supplicant. Verify that supplicant or NAS does not have a short timeout for EAP conversation. Check the network that connects the Network Access Server to ISE.
Root cause	Supplicant stopped responding to ISE after sending it the first EAP-TLS message

[jan.nielsen · Accepted solution]

Could be many things, i would suggest to look at your certificate trust setting in your client, make sure you have the whole CA chain installed and you are trusting the correct CA that the ISE is presenting to your client during EAP negotiation. However it can also happen when roaming between controllers, or when your client is out of reach of an AP.

[pnowikow · Accepted solution]

In my case this was happening if the Windows 10 PC had been on the network too long without a reboot; we're talking weeks.  My desktops had this happen more.  Restarting the WiredAutoConfig service wasn't enough to fix it but a reboot took care of it.  There's a GPO we run to configure the 802.1x and all the other PCs worked fine.  

[pnowikow]

Spoke too soon.  I still have about 60 endpoints using 802.1x native Windows supplicant that require occasional reboots to fix the issue.  Windows 10, Server 2012/2016 across multiple sites and using various switch model types.  I'm trying to find a common denominator here as it's preventing up from enabling Low-Impact mode. 

[thomas]

As others have said, this is a Windows 802.1X native supplicant configuration issue.

Verify these devices have your necessary Group Policy Objects (GPOs) from AD applied for certificates trust like your properly working systems.

[paul · Accepted solution]

Just to give you an idea of how much weight we give to this alarm, we disable this alarm along with misconfigured supplicant detected as part of our best practice.  In 100+ ISE deployments I have never regretted disabling this alarm.  It yields so many false positives or situations that fix themselves on their own that it becomes background noise you are never going to investigate until you hear of an actual connection issue.

[pnowikow]

Thanks Paul.  If I look in the RADIUS Live Logs for one of the endpoints that "failed" it sees it properly.  False positive is right.  All the PCs get the same GPOs which include the 802.1x config as well as the certs needed from the internal CA.

[Darkmatter]

Hi Paul,

How exactly do you disable this alarm?

I've been looking into the logging options but cannot seem to find it. Googling this didn't help much either, it seems like Cisco doesn't seems to like us disabling any alarming.

[Joe Kiema]

Not sure if its too late for this one. You go to:

Administration-System-Settings-Alarm Settings 

[Amar_Tufo]

I have to totally agree with that statement. the alarm is a full false positive one. no one is acctually complaining about connectivity loss in a deployment with around 1000 wired endpoints, even if those alarms are occuring from time to time. 

[pnowikow]

@thomas @paul @Darkmatter @Joe Kiema @hennie001 @jan.nielsen 

After a long time calling MS, TAC, these forums, I was able to determine my root cause.  It boiled down to a GPO change in Windows 10 so that the endpoints attempted multiple connection attempts instead of MS's default of 1 then waiting 20 min.  The other Community post below has all the details /w screen shots.

https://community.cisco.com/t5/network-access-control/5411-supplicant-stopped-responding-to-ise-quot-use-eap-tls-for/td-p/4084578

[Darkmatter]

Thanks a lot! Will check this somewhere next week when i have some more time to tinker.

I'll let you know when improvements are seen.