cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
209
Views
2
Helpful
2
Replies

ISE - EAP TLS Machine / User Auth Problem

Jkloz
Level 1
Level 1

Hey all, looking for a bit of assistance with a problem that's popped up on our network in the past few months.  We cannot nail down exactly when this started, but we have some issues specific to EAP-TLS x.509 user smartcard authentication, and machine certificate authentication that we're trying to solve.

The scenario:
Machine Authentication (Workstation Certificate) – Works fine.  When systems restart, or no user is logged into the system, authentication works as intended.  Client certificate is sent by the NAM supplicant, ISE receives, auth happens, everyone is happy.
Machine / User Authentication (Workstation Certificate/X.509 Smartcard) – Works fine, when a user logs into a system with their smartcard, we see EAP chaining work as intended (both user/machine authentication in a single RADIUS session).
Machine Fallback – (User Logged in, x.509 cert removed from the system) – No longer working.  We cannot figure out whether it’s a Windows 11 “Feature” that may have been implemented in one of the latest WIN11 upgrades (Credguard/Devguard?).  If a user pulls their smartcard out of the system, so the users certificate is no longer available, and an 802.1x reauthentication is triggered, the workstation certificate is never presented in the authentication session.  This is something that was previously working, so we are just trying to identify whether it’s a Windows issue or a new NAM bug.  

I’ve tried implementing TEAP, bypassing Secure Client/NAM altogether and the results were the same.  This leads me to believe it’s a windows “feature” regarding credential stores, or protections that Microsoft has implemented in security rollups/revision upgrades.

At this point I’m just wondering what the purpose of the machine fallback is in ISE (user failed/machine succeeded), unless in legacy implementations (PEAP/MSCHAPv2), this is still applicable.

Anyways, thanks for any assistance that you're able to provide!

2 Replies 2

Arne Bier
VIP
VIP

Just theorizing .. If the user has removed their Smart Card from their PC, then that makes sense, that the PC no longer has a User cert to perform User auth. Sorry, I'm just trying to make sense of this, and I don't have experience of using or setting up a Smart Card. You say in the past this used to work, but that would imply that the supplicant is presenting another client cert (which one?) to ISE? 

User Failed / Machine succeeded would be the scenario for an EAP chaining scenario - and in that instance, you would return an Authorization Profile to the NAD that applies for a logged out user - i.e. a dynamic VLAN and/or dACL. 

In your scenario, what Authorization Profile do you return for Machine auth, versus User auth?

I would have thought that Credential Guard etc had to do with MSCHAPv2 creds and not certificates.

Do you use any form of EAP-TLS Session-Resume, whether Stateless or Stateful?  

 

Hey Arne:
---You say in the past this used to work, but that would imply that the supplicant is presenting another client cert (which one?) to ISE?  In the scenario that a user pulls their x.509 (CAC) certificate from the system, the system locks, but doesn't log the user off.  

My systems would fall back and hit this authz rule in ISE:

Jkloz_0-1758587152505.png
The supplicant used to "fallback", to presenting the machine issued certificate (user fail, machine pass).

I believe that I've narrowed this down to a Microsoft change in hardening of the OS/WIN11 23H2 and above:

  • Windows 11 security hardening (especially post 22H2/23H2) brought in a number of Credential Guard and Device Guard refinements:
    • Session isolation means the machine cert context is not always reloaded once a user session has been established and then torn down.
    • When the supplicant is running in user context and a smart card removal triggers re-auth, Windows no longer drops back into system context to fetch the machine cert.
    • This isn’t specific to NAM — TEAP or native Windows supplicant behaves the same.