802.1X failures sporadically for Windows 10 clients

[Bwilson13]

Hello all,

We've been experiencing random authentication failures after a scheduled weekly reboot script runs at 3 am EST on Sunday mornings. The Windows 10 clients are using the native supplicant are a combination of Lenovo small form factor desktops and X1 Carbon laptops (G6 - G9) with docking stations.  The clients are running Win10 Enterprise 21H2, and we have a two node ISE 3.1 cluster with patch update 3, and the access layer switches are 3850s running IOS XE 16.12.5b. 

The Win10 clients have machine certs used for EAP-TLS authentication. The one thing that I was able to find in the TCPdump from ISE is a failed client wasn't sending the correct identity (MAC address opposed to devicename$@domain).

And the wired autoconfig log event ID 15514 reason text says there's something wrong with the user account. I interpret that to mean the machine account being used.

Is there anyone in the community experiencing strange behavior like this? Can this be an issue with the Windows supplicant after a reboot?

[Bwilson13]

Hi Arne - I do see it but was curious as to why the session timeout field shows "N/A"?

Thanks,

Bruce

[Arne Bier · Accepted solution]

When it says "N/A" it means that there is no session timeout for that endpoint session. This is unique to wired NAC because there is sometimes no need for a re-auth due to the fact that the device is physically connected to the switch and the link is up. The switch knows that the endpoint is still there - hence no need for a re-auth. It's different for devices that are daisy-chained to a deskphone - here the switch only sees the physical link to the deskphone, but not to the PC attached to the phone. Session timeout used to be a good mechanism to ensure that those types of endpoints were forced to re-auth to validate that they were still there. Cisco and other manufacturers desk phones will send a proxy logoff to the switch on behalf of the PC to avoid that situation. And of course in wireless NAC you cannot prove the client is still there - so session timeouts are used to maintain those sessions.

Bottom line - in wired NAC you don't need session timeouts and there is no default applied by the switch. The RADIUS server sends this optional timer value

[Bwilson13]

Thanks, Arne! I appreciate the insight here because I was thinking that may have played into our sporadic dot1x auth issues.

[Arne Bier · Accepted solution]

I would go as far as saying that session timeouts for directly connected wired endpoints is a bad thing and not necessary. It can be a bad thing in the event that all connections to the RADIUS server are lost, and then the session counts down to zero. Unless you're using IBNS 2.0 you're gonna have a bad day. And IBSN 2.0 can only save you up to a point. Better still is to not use session timeouts on critical gear, so that you are never faced with a re-auth. 

In theory, ISE should maintain the session (no matter how many months/years it exists for) by means of RADIUS Accounting updates. That tells ISE that the endpoint is still there. If this mechanism breaks down for whatever reason, then you have zombie sessions. I have seen those too. In that case, having a regular re-auth could avoid that, because you're forcing endpoints to re-establish those sessions.

[Bwilson13]

Thanks, Arne! Based on what you explained for any environment like mine using IBNS 1.0, you shouldn't have static configurations set on switch side for session timeout? Everything should be driven by ISE based on endpoint sessions?

The majority of Windows clients in my environment are behind Cisco phones. The other directly wired devices are printers, WAPs, 3rd party conference phones, Lighting, etc., .

I'm reviewing the wired access prescriptive guide again to see if there are any other options to further optimization configurations.

My interface configs for reauth and inactivity timer have the following set:

authentication periodic
authentication timer reauthenticate server
authentication timer inactivity server dynamic

[Arne Bier]

I suppose there are pros and cons to using session timeouts. My thoughts are as follows:

Send session-timeouts to endpoints when these endpoints are not directly connected to a switch interface (e.g. they are subtended off a phone, or another switch, etc.)

In all other cases, do not send a session timeout. Let the switch terminate the session when the Ethernet link goes down. 

[Bwilson13]

Thanks, Arnie! After doing some more research via the ISE secure wired access prescriptive guide and wired 802.1X deployment guide, and the your guidance, this all makes more sense now.

Since sending the re-auth timer to the switch is optional from ISE, I could effectively create another authorization profile for wired dot1x clients and just uncheck the following?

[Arne Bier]

Yep - in fact I find it a good practice to have unique authorization profiles for pretty much everything - it helps when filtering and creating reports.