Endpoint can't connect using Mschapv2 and peap different ways.

[JohnMaida05753]

Hello,

I am using the built int windows supplicant. ISE 3.0 P4.

I am using a 802.1x profile in windows.

When I have the option "Connect automatically when this network is in range" Checked everything works and auths go through.

But I have a specific AD group where they don't want it to connect automatically. So I unchecked it. And auths fail for those endpoints with these errors.

Event	5400 Authentication failed
Failure Reason	22007 Username attribute is not present in the authentication request
Resolution	Check whether the username has been sent along with the authentication request.
Root cause	Username attribute is not present in the authentication request.

	11808	Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated
	22007	Username attribute is not present in the authentication request

I noticed when we try to connect to the SSID on the login page, ISE reports a different Radius hostname format in

DOMAIN\HOSTNAME$

IS there a way to get this to work? Or are we stuck with connecting automatically.

Appreciate all the help.

[Arne Bier]

Hello

One of the key settings in Windows supplicants is whether you're using Machine or User authentication - or both.

Machine - Windows will authenticate to the network (supplicant) when the PC boots up, and when the user Logs Off

User - Windows will authenticate to the network (supplicant) after a successful login at the lock screen 

If you set your supplicant to do machine auth only, then the PC will send the Machine Account details to ISE - these are in the format of host\name$ and the password is only known to the machine itself. This is normal and expected. You should be able to find this account in your AD and also through ISE itself (External Identities, "Test User" - use the lookup feature)

I can't be sure why you'd be seeing RADIUS requests where ISE claims the username is not present - that is not normal - I presume that if you had tried EAP-TLS (certificate based auth) and perhaps the client certificate was malformed and didn't contain any data in the Subject or Subject Alternative Name - then I would expect that error. But not for PEAP.

[JohnMaida05753]

I am using machine and user authentication in the supplicant. 

On my policy I am using a was machine auth compound rule. So only the user auths if the machine did.

Above that a pure Machine auth rule

I am assuming its because the Computer is not connecting automatically at boot up.

[Arne Bier]

I didn't really address your question ... sorry. I guess for convenience you should enable auto connect for those users who are expected to use that service and get connected. Can't you push a group policy update to those users only, and not to the other user base that you're trying to avoid using the wifi? Unless you've locked down Windows config in such a way that unwanted users can't manually connect to the wifi, you won't be able to stop unwanted attempts. But ISE will only authorize based on the AD Group membership.

Are you trying to avoid lots of failed attempts (Live Log error) or what is the use case?

Regarding the error "22007 Username attribute is not present in the authentication request" when you untick the auto connect, which SSID do the clients end up connecting to? Do they manually connect to the intended SSID (which you didn't want them to auto connect to)? If so, then that would possibly explain my theory - they can only connect to the SSID while logged in - hence, they will trigger a user auth to the network - ISE might fail that because the device has not been Computer authenticated (that MUST work and is not in the user's control - have a look of the devices are domain joined and also what happens when those machines boot up - the network auth MUST be visible in ISE) - you can trigger this with a user log off, or a reboot.

[JohnMaida05753]

When I untick autoconnect. and the user trys to connect before login, It says fails to connect to network. And in the ISE live logs those are shown above as the errors. A reboot or logoff didn't help.

I do have 2 group policys for Auto and Manual connect. 

Very odd. Regardless I am going to push my customer to do a full auto connect GP as it was part of my original design.

In ACS it was working. As this is an ACS to ISE migration.

[Arne Bier]

yes odd indeed. Last question: did the ACS perform any Identity Rewrite (found in ISE under the AD External Identities Advanced Settings tab) ?

Functionally I wouldn't have expected ACS and ISE to differ in how PEAP is treated. At least, a basic machine auth should succeed, regardless of auto connect. Having said that, I had no idea that the auto connect could break PEAP.

[JohnMaida05753]

I was thinking upon the rewrites too. as the host had the $ after. I am not using any in ISE. ACS - I'm not too sure where to find if it was in use.

[Arne Bier]

I don't have any ACS's to look around - I couldn't find it in the user guide either. We might be barking up the wrong tree .. because the format of DOMAIN\host$ is valid - if you put that into ISE's "Test User" Lookup, you should find the computer account. It seems that Microsoft appends the "$" to machine account names and therefore these should not get rewritten.

If you had the time and inclination to do so, then perhaps take a tcpdump of the broken case, and the working case, and analyse the first Access-Request packet of each case in Wireshark - there might be a clue in there. 

[Greg Gibbs]

You might also try getting rid of the MAR attribute for 'WasMachineAuthenticated' to see if it works. MAR has many known drawbacks and caveats that can impact user experience as documented in Machine Access Restriction Pros and Cons.

We strongly recommend against using MAR and suggest moving to a more effective way of binding machine and user credentials like EAP Chaining with EAP-TEAP.