5411 Supplicant stopped responding to ISE

[Mateen Ahmad]

I am facing issue on some client machines windows 10/11, i have 2 node deployment  ISE3.2 p6.

I upgraded wireless adaptor firmware. but no luck. below live logs. I am using PEAP(MSCHAPv2), User and Machine authentications both. But i not using any certificate for machine authentications, I have self signed on ISE server and on client supplicant settings i have disabled "Verify server identity by validating server certificate"

Windows supplicant settings

ISE Policy: 

 Event 5411 Supplicant stopped responding to ISE
Failure Reason
12937 Supplicant stopped responding to ISE after sending it
the first inner EAP-MSCHAPv2 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. Verify that supplicant supports and has a
properly configured inner EAP-MSCHAPv2 method and
user/machine credentials.
Root cause
Supplicant stopped responding to ISE after sending it the first
inner EAP-MSCHAPv2 message 

[Arne Bier]

Is this a lab or production?  Please tell me it's a lab ... you should not be setting up your client devices like this.

Does this happen to only one client or all of them?

EAP-PEAP MSCHAPv2 is a bad idea for Windows enterprise environments for a couple of reasons

Windows Credential Guard will break the ability for your users' credentials to be supplied to the supplicant

When users change their AD password, they must then "forget network" and reconnect. Or how do you suggest they change the supplicant password after they have changed their Windows password (CTRL-ALT-Del) ?

MSCHAPv2 used to be the most convenient way to do network authentication - but better is to use an MDM, or ISE BYOD and put certs on your devices. Seriously.

Telling the supplicant to ignore the server cert is a serious security compromise. Why then waste your time with all this 802.1X - you'd be better off with PSK SSID. Don't use self-signed EAP certs. Make a CA (it's easy) and then sign your ISE EAP server certs and push the CA certs to your clients as a trusted cert (use group policy, or an MDM).

To solve your issue, run an ISE tcpdump and then analyse the EAP conversation in Wireshark to see why the clients are unhappy.

And finally, MAR (Machine Access Restriction) is another no-no. It's unreliable. f you're gonna do user and machine auth together, then please look at EAP-TEAP.  

[Mateen Ahmad]

I am getting this error "Attempt to get credential key by call package blocked by Credential Gaurd"

[thomas]

See https://cs.co/ise-berg#credential-guard

[JPavonM]

Has your setup worked previously?

As @Arne Bier indicates you're using an unsecure way to permit connections, but I understand not everyone has the possibility/hability to deploy and mantain certificates in their environment for multiple reasons.

Moving forward with your setup, what you are telling Windows is to authenticate with machine credentials when in the login page, and when the user is logged in, use the user credentials stored in Windows to connect. (Here the asumptiom from Arne is not true about a change in user credentials, as windows always keep the latest ones so it always uses the good ones, but this is true that if the user blocks the account, they won't be able to join)

The recommendation is that you use an internally signed certificate to be presented by ISE, and you validate it with the CA that signed it (this is cheaper than buying a public one), this way you can prevent non-corporate devices from joining the network, so securing it more.

Regarding your ISE policies, you should split authentication policy for computers and for users, something like this:

And then also split authorizations for machine and user:

As industry's best practice, consider moving formward to EAP-TLS with the same setup, but always validate certificates in both sides, and keep drivers and OS'es updated to latest releases/patches.

By the way, in Win11 you would need to disable Credentials Guard so to allow them to use PEAP. (https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/configure?tabs=reg#disable-credential-guard)

[Aref Alsouqi]

Please try to run Wireshark capture on one of these affected machines and share the output for review.