Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

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

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

 

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

I don't see any

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

New Member

salodh, Thank you for your

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. 

  
 12500Prepared EAP-Request proposing EAP-TLS with challenge
 12625Valid EAP-Key-Name attribute received
 11006Returned RADIUS Access-Challenge
 11001Received RADIUS Access-Request
 11018RADIUS is re-using an existing session
 12301Extracted 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):

 
Conditions
 
 
 
 

 

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

New Member

Did you happen to ever find a

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

New Member

Nothing yet, unfortunately. I

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. 

Hello Andrew,we are running

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.

New Member

Andrew,

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.

New Member

Ryan,

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

New Member

Andrew,

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.

New Member

Andrew,

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.

New Member

Awesome Andrew also have this

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

New Member

Have you found any solution?

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.

Hi,

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

805
Views
23
Helpful
12
Replies