cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
561
Views
1
Helpful
8
Replies

windows machine use eap-tls & then peap during roaming

time to learn again in my 57...
subject reflects conditions as how they can be seen from ISE perspective (no access to AD, its target computer etc to verify).
asset everytime authenticates with its machine account, but after initial EAP-TLS, when roaming. it switches to PEAP.
How can it be achieved on windows supplicant?

1 Accepted Solution

Accepted Solutions

The Windows supplicant is not capable of automatically 'falling back' to another authentication method (EAP-TLS) if the first one ([PEAP]MSCHAPv2) fails. My guess would be either:

  1. Some custom scripting has been done on the endpoint to trigger the reconfig of the supplicant settings based on some Windows event that is triggered by the auth failure. You would likely have to look into the Task Scheduler and Event Viewer to find that.
  2. Another supplicant (like AnyConnect NAM) is installed and configured for different authC methods for Computer (PEAP) versus User (EAP-TLS) auth and the User certificate enrolled using the Computer FQDN instead of the User credential. That certificate is presented to ISE when the User logs in so it sees the computer FQDN as the identity.

For either scenario (or something else), there would be no way to validate the root cause without detailed investigation of the endpoint.

 

View solution in original post

8 Replies 8

Arne Bier
VIP
VIP

Your question is quite strangely worded. Are you asking, whether a Windows supplicant can mysteriously switch from using EAP-TLS to EAP-PEAP when the endpoint is roaming?

My only guess is that perhaps there is an AnyConnect NAM installed on the endpoint and the machine auth is EAP-TLS, and the user auth is EAP-PEAP. The machine boots up with EAP-TLS. User logs in - EAP-PEAP is triggered. User remains logged in and then goes walkabout roaming).

Same could happen with EAP-TEAP and its EAP chaining support (similar to AnyConnect NAM)

 

Hi Arne 

Glad to see u came to help. It was late yesterday so that i mislooked 2nd method. It's PEAP-MSCHAPv2 according to ISE. But in the rest the situation is exactly like i declared - each time it's machine authentication. I spent tens of hours checking how EAP-FAST (AnyConnect) & EAP-TEAP (Windows) work. But there is no such a feature as concurrent method for the account type (machine|user). So how is it possible to setup Supplicant on windows so that it runs machine authentication with 2 different methods a time?
EAP-TLS one:
...
Username hostname.company.tld
Endpoint Id AA:BB:CC:DD:EE:FF
Endpoint Profile Windows11-Workstation
...
Authentication Method dot1x
Authentication Protocol EAP-TLS
...
12502 Extracted EAP-Response containing EAP-TLS challenge-response and accepting EAP-TLS as negotiated

PEAP-MSCHAPv2 one:
...
Username host/hostname.company.tld
Endpoint Id AA:BB:CC:DD:EE:FF
Endpoint Profile Windows11-Workstation
...
Authentication Method dot1x
Authentication Protocol PEAP (EAP-MSCHAPv2)
...
12304 Extracted EAP-Response containing PEAP challenge-response
11808 Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated
...
24343 RPC Logon request succeeded - hostname$@company.tld (step latency=1990 ms Step latency=1990 ms)
...

 

Arne Bier
VIP
VIP

I still don't know exactly what you're confused about. What do you mean by "concurrent" ?  EAP chaining does exactly that ... it sends both user and machine auth at the same time when the user is logged in.

In your example with username and MAC addresses etc., what are you describing there? Which part is machine auth and which part is user auth?

 

 

Arne,
1) in both cases it's a machine account.
2) if u look on the live logs u see 1st EAP-TLS authC, then series of PEAP-MSCHAPv2 authCs due to roaming. all off them are machine's authCs!
3) under "concurrent" i mean exactly situation when wireless nic may authenticate either with EAP-TLS or PEAP-MSCHAPv2 at a time with its _computer_ account w/o reconfigurations in the middle.
hopefully now it's clear...

 

other words, the windows supplicant that just failed (bc of authZ profile dictated so) with machine's PEAP-MSCHAPv2 & few moments later it authenticates with new session with machine's EAP-TLS. How can this sequence be achieved? any ... idieas pls?

The Windows supplicant is not capable of automatically 'falling back' to another authentication method (EAP-TLS) if the first one ([PEAP]MSCHAPv2) fails. My guess would be either:

  1. Some custom scripting has been done on the endpoint to trigger the reconfig of the supplicant settings based on some Windows event that is triggered by the auth failure. You would likely have to look into the Task Scheduler and Event Viewer to find that.
  2. Another supplicant (like AnyConnect NAM) is installed and configured for different authC methods for Computer (PEAP) versus User (EAP-TLS) auth and the User certificate enrolled using the Computer FQDN instead of the User credential. That certificate is presented to ISE when the User logs in so it sees the computer FQDN as the identity.

For either scenario (or something else), there would be no way to validate the root cause without detailed investigation of the endpoint.

 

JPavonM
VIP
VIP

Is it EAP-TLS happening while in the login screen? If so then the Windows wireless profile is configured to use "user or computer authz" and SSO is enabled to authenticate in the login screen under "Advanced settings". 

JPavonM_1-1710486661019.png

The weird thing here is how Windows is changing from EAP-TLS with computer authZ to PEAP with user authZ, and using TEAP is the only way to do that EAP-chaining in Windows 10:

JPavonM_2-1710486953735.png

Try to create a profile and set this off and use EAP-PEAP and username as authentication mode as "user authz" only if that is what you want, or EAP-TLS by choosing Smartcard.

 

no access to any of endpoint-side relevant tools(
only we can see is process from ISE/WLAN perspective. Each time asset presents either host/computername.company.tld (which in this endpoint's case always accompanied with negotiated method PEAP-MSCHAPv2) or computername.company.tld (which in this endpoint's case always accompanied with negotiated method EAP-TLS). what i can conclude from above for 100% is it's every time computer's authC not user's. but this doesnt hint on how it can be configured on the NIC...