ISE 1.2, Patch 7: "NAK requesting to use PEAP instead"

[Andrew Chapman]

We're experiencing seemingly random occurrences of users failing authentication because they're trying PEAP vs EAP. Does anyone know if it is possible to force the Windows supplicant to use EAP only?

For what it's worth, the user can fail authentication for hours and I can either allow open authentication on the port for a bit, or the user can leave for the day and come back tomorrow and authentication will succeed. I'm not sure if it's an ISE problem or a supplicant problem, but I'm leaning towards supplicant.

Personas:	Administration
Role:	PRIMARY(A)
System Time:	Apr 24 2014 08:26:58 AM America/New_York
FIPS Mode:	Disabled
Version:	1.2.0.899
Patch Information:	7,1,3

11001	Received RADIUS Access-Request
	11017	RADIUS created a new session
	15049	Evaluating Policy Group
	15008	Evaluating Service Selection Policy
	15048	Queried PIP
	15048	Queried PIP
	15004	Matched rule
	11507	Extracted EAP-Response/Identity
	12500	Prepared EAP-Request proposing EAP-TLS with challenge
	12625	Valid EAP-Key-Name attribute received
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12301	Extracted EAP-Response/NAK requesting to use PEAP instead
	12300	Prepared EAP-Request proposing PEAP with challenge
	12625	Valid EAP-Key-Name attribute received
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12302	Extracted EAP-Response containing PEAP challenge-response and accepting PEAP as negotiated
	12318	Successfully negotiated PEAP version 0
	12800	Extracted first TLS record; TLS handshake started
	12805	Extracted TLS ClientHello message
	12806	Prepared TLS ServerHello message
	12807	Prepared TLS Certificate message
	12810	Prepared TLS ServerDone message
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12318	Successfully negotiated PEAP version 0
	12812	Extracted TLS ClientKeyExchange message
	12804	Extracted TLS Finished message
	12801	Prepared TLS ChangeCipherSpec message
	12802	Prepared TLS Finished message
	12816	TLS handshake succeeded
	12310	PEAP full handshake finished successfully
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12313	PEAP inner method started
	11521	Prepared EAP-Request/Identity for inner EAP method
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	11522	Extracted EAP-Response/Identity for inner EAP method
	11806	Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	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
	15041	Evaluating Identity Policy
	15006	Matched Default Rule
	15013	Selected Identity Source - *****
	24431	Authenticating machine against Active Directory
	24470	Machine authentication against Active Directory is successful
	22037	Authentication Passed
	11824	EAP-MSCHAP authentication attempt passed
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	11810	Extracted EAP-Response for inner method containing MSCHAP challenge-response
	11814	Inner EAP-MSCHAP authentication succeeded
	11519	Prepared EAP-Success for inner EAP method
	12314	PEAP inner method finished successfully
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	15036	Evaluating Authorization Policy
	24433	Looking up machine in Active Directory - host/*****
	24435	Machine Groups retrieval from Active Directory succeeded
	15048	Queried PIP
	15048	Queried PIP
	15048	Queried PIP
	15048	Queried PIP
	15048	Queried PIP
	15004	Matched rule - Default
	15016	Selected Authorization Profile - DenyAccess
	15039	Rejected per authorization profile
	12306	PEAP authentication succeeded
	11503	Prepared EAP-Success
	11003	Returned RADIUS Access-Reject

[Saurav Lodh]

I don't see any authentication failure above. What is the authorization rule? I see after authentication, users are grant deny access.

[Andrew Chapman]

salodh,

Thank you for your response. Below is the authorization policy it should hit. The trouble is the workstation wants to use PEAP for some reason but we don't want PEAP because we're certificate-based. I understand what you're saying, and it's because I didn't word my question correctly. 

	12500	Prepared EAP-Request proposing EAP-TLS with challenge
	12625	Valid EAP-Key-Name attribute received
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12301	Extracted EAP-Response/NAK requesting to use PEAP instead

If the NAK would not request PEAP, it would continue on to the following Authorization Policy (and succeed):

Name	Wired-******-PC
Conditions

	Radius:Service-Type EQUALS Framed	AND
	Radius:NAS-Port-Type EQUALS Ethernet	AND
	*******:ExternalGroups EQUALS **********/Users/Domain Computers	AND
	Network Access:EapAuthentication EQUALS EAP-TLS

Again, this PEAP request only happens occasionally. This same workstation will work at other days/times. If I could figure out why some workstations randomly request PEAP (or find a way to force EAP only) I think that would take care of it.

Thanks again, sir.

Andrew

[dylanhorner]

Did you happen to ever find a solution to this? Experiencing the same thing here which throws all clients into my BYOD policy

[Andrew Chapman]

Nothing yet, unfortunately. I hope to involve Microsoft support soon, but I'm waiting on our server team to open a case. This was the TAC response (there's an option you can try - Policy > Policy Elements > Results > Authentication > Allowed Protocols > Default Network Access > Preferred Network Protocol > EAP-TLS): 

Hello Andrew,

As we discussed,   through the AuthC profile,  we can “propose” the client to go through EAP-TLS as the first option.

This will not block any clients trying to connect using other protocols.

Also, this will propose EAP-TLS,  but there is no way we can enforce it at supplicant level.  At the end,  this will be a client decision always.

Please monitor this after the  change we applied,   but if the issue persists,   since we are dealing with windows supplicant,   it would be a good idea to involve the native supplicant support. 

[romanrodichev@iementor.com]

We've run into this before, it might happen if you mistype SSID in the NSP profile. For example, real SSID is TEST_TEST, but in NSP profile you type TEST-TEST, and Wizard won't complain about it on the client, but Wizard won't update the correct SSID on supplicant from PEAP to EAP-TLS and therefore it will continue to use PEAP.

[Ryan Coombs]

Andrew,

Was this ever resolved and if so do you mind sharing the fix?  We have upgraded to ISE 1.4 from 1.2 and are expierencing the same issue with about 30 clients.  Not a huge deal as we are supporting around 15K but still annoying and is driving our users nuts.

We are using EAP-TLS for Wireless Machine authentications only, using a mixture of WISM-2 and 5508 Controllers.  All running code 7.6.130.26

This was not expierenced or at least not reported with ISE 1.1 to 1.3 and we've been up and running for almost 3 years.

We are currently running ISE 1.4 Patch 3 and tested with P4 without luck either.  The clients login to the machine using PIV which doesnt point to ISE.  Later in the day, they realize there PIV card has been locked out due to Failed Attempts.

Thanks and any help is appreciated.

[Andrew Chapman]

Ryan,

Our issue was related to DLL updates. I've included a transcript from our Microsoft case.

Best of luck,
Andrew

Issue:  Few laptops are requesting for PEAP when the authentication protocol is set to EAP-TLS on the Cisco ISE RADIUS server using Wired 802.1X network.

Cause:  The dot3svc.dll file was not updated.

Resolution:  Updated dot3svc.dll to the latest version.

Troubleshooting steps followed:

-              Collected WLAN ETL and RAS traces on the client while reproducing the issue.

-              Commands:

netsh trace start scenario=LAN capture=yes persistent=yes tracefile=c:\lan-client.etl

netsh ras set tracing * enable

Reproduced the issue.

Stop the traces using the commands:

netsh trace stop

netsh ras set tracing * disable 

-              From the traces we found that we were getting EAP: Identity Request packets but we were not seeing any response.

-              We also found that the Dot3svc packet was throwing an error and ignoring the preceding packet.

15:41:08.1117768 293 0.0000000  svchost.exe (332)   Dot3svc_MicrosoftWindowsWiredAutoConfig Dot3svc_MicrosoftWindowsWiredAutoConfig:No 1X port exists. Ignoring the packet received

-              Updated the dot3svc.dll file on the clients. Link: http://support.microsoft.com/kb/2736878/en-us

-              On one of the other clients we updated the rastls.dll file. Link: http://support.microsoft.com/kb/2494172

[Ryan Coombs]

Andrew,

Wow excellent notes and Thanks a million for sharing.  5 Stars and i'll provide an update once we test.  Well done my man.

[Ryan Coombs]

Andrew,

We had the help desk update the clients as you suggested.  We just recieved word yesterday its happening again.  Whats weird is it cleared the issue for approx 5 days then returned.  I'm going to have them contact Microsoft as well and see what they discover.

Thanks for the assistance.

[marc.groenen]

Awesome Andrew also have this issue with an implementation for a client with ISE 1.3

[bomos32768]

Have you found any solution?

I've got the same issue with ISE 2.0...

Wired clients, unplugging/plugging network cable helps, but it isn't an acceptable solution.

[Christos Stefaneskou]

Hi,

Seems it's a supplicant issue. If you're using windows 7 native supplicant, check the hotfix KB 2481614.

https://supportforums.cisco.com/discussion/11916581/cisco-ise-8021x-eap-tls-list-applicable-hot-fixes

https://supportforums.cisco.com/blog/12256681/getting-past-intermittentunexplained-8021x-problems-windows-7

Hope this helps.

Regards,

Christos