Security

Share the exact alert text from an attempt for better clarity, but a time out like that is almost always going to be a certificate trust issue.  Either client isn't trusting the RADIUS cert or the client is never receiving the RADIUS cert packets.  Also, make sure that the new machines have up to date drivers for the network adapters.

Hi Carson.  Attached is the exact error.

Likely easiest to troubleshoot this with packet captures.  Grab one at the client, see if RADIUS is sending the certificates over to the client.

Last time I saw this there was an MTU issue and had to set the proper EAP fragment values on the NAD.

Hi Carson.  Attached is the exact error.

Share the exact alert text from an attempt for better clarity, but a time out like that is almost always going to be a certificate trust issue.  Either client isn't trusting the RADIUS cert or the client is never receiving the RADIUS cert packets.  Also, make sure that the new machines have up to date drivers for the network adapters.

I did a search before posting and did find mention of changing MTU size.  By NAD I'm assuming you mean on the PC or laptop affected?

Likely easiest to troubleshoot this with packet captures.  Grab one at the client, see if RADIUS is sending the certificates over to the client.

Last time I saw this there was an MTU issue and had to set the proper EAP fragment values on the NAD.

Hi Carson.  Attached is the exact error.

Hi Carson.  Attached is the exact error.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.

Share the exact alert text from an attempt for better clarity, but a time out like that is almost always going to be a certificate trust issue.  Either client isn't trusting the RADIUS cert or the client is never receiving the RADIUS cert packets.  Also, make sure that the new machines have up to date drivers for the network adapters.

I'm not an admin for the server environment.  I'll pass the info on to the guys and see if I can get a snapshot of what we've got currently.  We're also going to alter the MTU size down slightly after a bit of testing to see if that helps the issue.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.

Hi all.  I've attached packet captures showing me plugging a Win11 fresh build laptop into the network.  It seems to show the EAP request in PEAP first, the laptop responding, then the request switches to EAP-TLS instead.  Finally it looks like PEAP again and then assigns it a 192.168.8.X address as it kicks it over to the visitors VLAN for failing to authenticate.

I'll see if I can borrow one of the laptops that upgraded accidentally from Win10 to Win11 since they work fine for whatever reason.  We can't see anything obviously different in the services or certs but maybe a capture of that transaction will provide a hint.

I'm not an admin for the server environment.  I'll pass the info on to the guys and see if I can get a snapshot of what we've got currently.  We're also going to alter the MTU size down slightly after a bit of testing to see if that helps the issue.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.

Hi all.  We seem to have tracked down the issue to the new virtualisation security on Windows 11 stopping MSCHAPv2 authenticating properly.  Disabling that security gets it to work.  We would obviously prefer to get EAP-TLS working on Clearpass rather than put out policies to disable Windows security features.  Currently Clearpass is set to try EAP-TLS first then fail over to EAP-PEAP.

From the packet captures it looks like the Clearpass server is trying to use TLSv1.3 and our Win11 build only has v1.2 and the negotiations fail.  The only control over TLS version I can find is in the server cluster config page.  I can set TLSv1.3 support to All, None, Admin or Network.  Same for v1.0 and v1.1.  If I want to set TLS on the server to 1.2 only I take it I have to set that parameter to 'none'?  I'm wary of trying it without advice since it's a cluster wide change on a live environment with 2000 users and I'm clueless.

Hi all.  I've attached packet captures showing me plugging a Win11 fresh build laptop into the network.  It seems to show the EAP request in PEAP first, the laptop responding, then the request switches to EAP-TLS instead.  Finally it looks like PEAP again and then assigns it a 192.168.8.X address as it kicks it over to the visitors VLAN for failing to authenticate.

I'll see if I can borrow one of the laptops that upgraded accidentally from Win10 to Win11 since they work fine for whatever reason.  We can't see anything obviously different in the services or certs but maybe a capture of that transaction will provide a hint.

I'm not an admin for the server environment.  I'll pass the info on to the guys and see if I can get a snapshot of what we've got currently.  We're also going to alter the MTU size down slightly after a bit of testing to see if that helps the issue.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.

Hi all.  We seem to have tracked down the issue to the new virtualisation security on Windows 11 stopping MSCHAPv2 authenticating properly.  Disabling that security gets it to work.  We would obviously prefer to get EAP-TLS working on Clearpass rather than put out policies to disable Windows security features.  Currently Clearpass is set to try EAP-TLS first then fail over to EAP-PEAP.

From the packet captures it looks like the Clearpass server is trying to use TLSv1.3 and our Win11 build only has v1.2 and the negotiations fail.  The only control over TLS version I can find is in the server cluster config page.  I can set TLSv1.3 support to All, None, Admin or Network.  Same for v1.0 and v1.1.  If I want to set TLS on the server to 1.2 only I take it I have to set that parameter to 'none'?  I'm wary of trying it without advice since it's a cluster wide change on a live environment with 2000 users and I'm clueless.

Hi all.  I've attached packet captures showing me plugging a Win11 fresh build laptop into the network.  It seems to show the EAP request in PEAP first, the laptop responding, then the request switches to EAP-TLS instead.  Finally it looks like PEAP again and then assigns it a 192.168.8.X address as it kicks it over to the visitors VLAN for failing to authenticate.

I'll see if I can borrow one of the laptops that upgraded accidentally from Win10 to Win11 since they work fine for whatever reason.  We can't see anything obviously different in the services or certs but maybe a capture of that transaction will provide a hint.

I'm not an admin for the server environment.  I'll pass the info on to the guys and see if I can get a snapshot of what we've got currently.  We're also going to alter the MTU size down slightly after a bit of testing to see if that helps the issue.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.

My guess is that you try to connect to the SSID/wired 802.1X without configuration on the client side.

You should pre-configure your client/supplicant, and then you can fix it to EAP-TLS only (or maybe better TEAP) and proper server validation. Then the client doesn't need to guess, and won't connect to something else or ask for username/password.

Configuration of you clients normally happens through Group Policies, or Intune/MDM.

Hi all.  We seem to have tracked down the issue to the new virtualisation security on Windows 11 stopping MSCHAPv2 authenticating properly.  Disabling that security gets it to work.  We would obviously prefer to get EAP-TLS working on Clearpass rather than put out policies to disable Windows security features.  Currently Clearpass is set to try EAP-TLS first then fail over to EAP-PEAP.

From the packet captures it looks like the Clearpass server is trying to use TLSv1.3 and our Win11 build only has v1.2 and the negotiations fail.  The only control over TLS version I can find is in the server cluster config page.  I can set TLSv1.3 support to All, None, Admin or Network.  Same for v1.0 and v1.1.  If I want to set TLS on the server to 1.2 only I take it I have to set that parameter to 'none'?  I'm wary of trying it without advice since it's a cluster wide change on a live environment with 2000 users and I'm clueless.

Hi all.  I've attached packet captures showing me plugging a Win11 fresh build laptop into the network.  It seems to show the EAP request in PEAP first, the laptop responding, then the request switches to EAP-TLS instead.  Finally it looks like PEAP again and then assigns it a 192.168.8.X address as it kicks it over to the visitors VLAN for failing to authenticate.

I'll see if I can borrow one of the laptops that upgraded accidentally from Win10 to Win11 since they work fine for whatever reason.  We can't see anything obviously different in the services or certs but maybe a capture of that transaction will provide a hint.

I'm not an admin for the server environment.  I'll pass the info on to the guys and see if I can get a snapshot of what we've got currently.  We're also going to alter the MTU size down slightly after a bit of testing to see if that helps the issue.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.

Share the exact alert text from an attempt for better clarity, but a time out like that is almost always going to be a certificate trust issue.  Either client isn't trusting the RADIUS cert or the client is never receiving the RADIUS cert packets.  Also, make sure that the new machines have up to date drivers for the network adapters.

Hi Herman.  We use a group policy to turn on the wired & wireless dot1x services, install the certificates and set up the SSID which is not broadcast.  Our server people have been running tests using an upgraded build and a fresh build Windows 11 and have found that the problem is MSCHAP.  It appears TLS doesn't work so it tries EAP-PEAP next and fails because of MSCHAPv2 being broken by the new Credential Guard system on Win11.  We can get the authentication working again by disabling it but I'd prefer to get EAP-TLS or TEAP working instead.

My guess is that you try to connect to the SSID/wired 802.1X without configuration on the client side.

You should pre-configure your client/supplicant, and then you can fix it to EAP-TLS only (or maybe better TEAP) and proper server validation. Then the client doesn't need to guess, and won't connect to something else or ask for username/password.

Configuration of you clients normally happens through Group Policies, or Intune/MDM.

Hi all.  We seem to have tracked down the issue to the new virtualisation security on Windows 11 stopping MSCHAPv2 authenticating properly.  Disabling that security gets it to work.  We would obviously prefer to get EAP-TLS working on Clearpass rather than put out policies to disable Windows security features.  Currently Clearpass is set to try EAP-TLS first then fail over to EAP-PEAP.

From the packet captures it looks like the Clearpass server is trying to use TLSv1.3 and our Win11 build only has v1.2 and the negotiations fail.  The only control over TLS version I can find is in the server cluster config page.  I can set TLSv1.3 support to All, None, Admin or Network.  Same for v1.0 and v1.1.  If I want to set TLS on the server to 1.2 only I take it I have to set that parameter to 'none'?  I'm wary of trying it without advice since it's a cluster wide change on a live environment with 2000 users and I'm clueless.

Hi all.  I've attached packet captures showing me plugging a Win11 fresh build laptop into the network.  It seems to show the EAP request in PEAP first, the laptop responding, then the request switches to EAP-TLS instead.  Finally it looks like PEAP again and then assigns it a 192.168.8.X address as it kicks it over to the visitors VLAN for failing to authenticate.

I'll see if I can borrow one of the laptops that upgraded accidentally from Win10 to Win11 since they work fine for whatever reason.  We can't see anything obviously different in the services or certs but maybe a capture of that transaction will provide a hint.

I'm not an admin for the server environment.  I'll pass the info on to the guys and see if I can get a snapshot of what we've got currently.  We're also going to alter the MTU size down slightly after a bit of testing to see if that helps the issue.

Microsoft has changed the way Windows require information in the 802.1x profile.

You should enable the certificate validation and also provide the host name(s) found in the ClearPass certificate(s). Also select the issuer root of the ClearPass certificate.

This will suppress the prompt to the user. If you have an older version of the GPO you may have a setting to not prompt the user for new certificates, and if the client can't validate the certificate based on the information in the GPO and are not able to prompt the user, it will not be able to connect.

Can you take a screenshot of your GPO settings?

Hi Carson.  Attached is the exact error.