topic Re: An EAP-TLS Wi-Fi is Aksing for Username and Password in Network Access Control

An EAP-TLS Wi-Fi is Aksing for Username and Password

Matthew Martin — Tue, 04 Jun 2024 19:22:58 GMT

I had an 802.1x EAP-TLS Wi-Fi network working in Windows NPS to auth PC's based on a machine certificate on the company laptops.

I'm trying to get this working on ISE. But, for some reason I'm being prompted for a Username and Password.

I pushed the Wi-Fi network settings to a test laptop using GPO. It's configured for Smart Card or other certificate Authentication, and the Mode = Computer. Under Properties I checked off our internal CA server as the Trusted CA.

Then, on ISE I followed this guide to setup the Cert authentication, Policy Sets, Certificate Authentication Profile, etc...

When the test client laptop tries to connect, I am getting prompted for a Username and Password... No idea why this is prompting me.

I have almost the exact same Policy Set for Wired, minus the Called-Station-ID condition, and Wired does not prompt for username and password. So I'm not sure why Wireless is.

Any ideas why this would be prompting for a username and password? Any thoughts would be greatly appreciated!

-Matt

Re: An EAP-TLS Wi-Fi is Aksing for Username and Password

Rob Ingram — Tue, 04 Jun 2024 19:32:34 GMT

@Matthew Martin has the GPO with these settings been applied to the computer? as opposed to the user.

Re: An EAP-TLS Wi-Fi is Aksing for Username and Password

Matthew Martin — Tue, 04 Jun 2024 21:54:26 GMT

Correct, GPO is applied to Computer according to "gpresult /r /scope computer".

Would that be something on the ISE side that is causing the Login Prompt? I tried removing the condition in Policy Sets that says the device needs to be in "Domain Computers" group and I still prompted. So I added that condition back...

-Matt

Re: An EAP-TLS Wi-Fi is Aksing for Username and Password

Greg Gibbs — Tue, 04 Jun 2024 23:25:59 GMT

The Authentication Mode = Computer will only trigger an 802.1x authentication when in the Computer state (before the user logs in or after the user logs out). The supplicant does not have a profile for automatic user authentication using EAP-TLS, which is why you're being prompted for credentials (for PEAP[MSCHAPv2]).

If you want the supplicant to automatically authenticate when in the User state, you would need to change the Authentication mode to either 'User or Computer Authentication' or 'User Authentication'. The latter will mean there will be no network access in the Computer state.

Re: An EAP-TLS Wi-Fi is Aksing for Username and Password

Rob Ingram — Wed, 05 Jun 2024 07:25:40 GMT

@Matthew Martin If it's prompting for authentication I believe this is a supplicant issue. If the supplicant was configured correctly, I'd expect the authentication request to be sent to ISE and the ISE logs to reflect a failed authentication (if the ISE rules where incorrect/not matched), not prompt for credentials on the computer side.

If the device is configured for "Computer authentication" 802.1X can trigger in the user state, it sends the computer credentials to ISE.

Re: An EAP-TLS Wi-Fi is Aksing for Username and Password

Matthew Martin — Mon, 10 Jun 2024 20:19:24 GMT

Hey All,

Sorry for the delayed response. Had to step away from this for a few days and work on another project that we have going on. Came back to this today, and I think I figured out the problem.

I don't know why it was done this way. It was done before I had any involvement on the Windows Admin side. Where each Domain joined PC is getting 2 certificates from our internal CA. One template appears to be created from the standard "Computer" template certificate found in the Windows CA, and the other one, if I remember correctly was setup by a consultant we hired to help us setup ISE many many years ago (*ISE 1.x).. Both certs are still being pushed out via GPO, and are being auto-renewed as well.

The default "Computer" certificate uses all the standard options you'd expect and is configured for Client and Server Auth. The other template that was created by the consultant is a Machine template configured for Client Auth only. It appears that this Cert was configured to not have a Subject Common-Name, which I noticed in the ISE logs and then went to check the Cert on the test laptop and it indeed did NOT have a Subject CN configured. What was configured was Subject Alternative Name "DNS Name=myComputer@mydomain.com". This appears to be the only field in this template that shows the PC Name configured in AD.

Found this in the Auth Details for the Test Laptop:

So I went into the Certificate Authentication Profile and changed the option to: Any Subject or Alternative Name Attributes in the Certificate.

Since both of those client certs I mentioned are signed by our Internal CA, and that is the CA server ticked in the Windows Wireless Profile config (*And Simple Certificate Selection is being used). I'm not sure how it decides which cert to present during Network Authentication. But, it appears that one was being selected.

After changing the Certificate Authentication Profile to any alternative name. Authentication started working correctly on this Wi-Fi network.

-Matt