topic Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy in Network Access Control

failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Andrii Oliinyk — Thu, 29 Apr 2021 21:27:27 GMT

Gentlemen

i've some deployment 2.1 with single dot1x policy matching CAP.

Dot1X : If Wired_802.1X OR
Wireless_802.1XAllow Protocols : Default Network Access and
Default : use MyPKI_Certificate

endpoints configured for EAP-TLS authenticate nice.

but i have some endpoints not configured for EAP-TLS but trying to use PEAP (EAP-MSCHAPv2) instead. They expectedly fails:

Failure Reason 22044 Identity policy result is configured for certificate based authentication methods but received password based
Authentication Method dot1x
Authentication Protocol PEAP (EAP-MSCHAPv2)

When i create policy like this:

If Wired_802.1X AND
Radius:Calling-Station-ID EQUALS AA-BB-CC-DD-EE-FF AND
Allow Protocols : Default Network Access and
Default : use My_AD

endpoints just nice authenticate against AD with PEAP (EAP-MSCHAPv2)

but when i modify policy like this:

If Wired_802.1X AND
Radius:Calling-Station-ID EQUALS AA-BB-CC-DD-EE-FF AND
Network Access:EapTunnel EQUALS PEAP Allow Protocols : Default Network Access and
Default : use My_AD

or like this:

Dot1X_AD_Computers_MSCHAP_test : If Wired_802.1X AND
Radius:Calling-Station-ID EQUALS AA-BB-CC-DD-EE-FF AND
Network Access:EapAuthentication EQUALS EAP-MSCHAPv2 Allow Protocols : Default Network Access and
Default : use My_AD

or like this:

Dot1X_AD_Computers_MSCHAP_test : If Wired_802.1X AND
Radius:Calling-Station-ID EQUALS AA-BB-CC-DD-EE-FF AND
Network Access:EapTunnel EQUALS PEAP AND
Network Access:EapAuthentication EQUALS EAP-MSCHAPv2 Allow Protocols : Default Network Access and
Default : use My_AD

target endpoints never match policy & fallback to one EAP-TLS based with expected result.

worth to note that AuthZ policy created for PEAP (EAP-MSCHAPv2) case works like a charm whilst has the same condition inside & always converts Calling-Station-ID into ":" delimiter format

if (Wired_802.1X AND My_AD:ExternalGroups EQUALS myad.local/Users/Domain Computers AND Network Access:EapAuthentication EQUALS EAP-MSCHAPv2 AND Network Access:EapTunnel EQUALS PEAP AND Radius:Calling-Station-ID EQUALS AA:BB:CC:DD:EE:FF )

can anybody help here pls?

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Arne Bier — Fri, 30 Apr 2021 11:16:29 GMT

I always separate out Wired and Wireless into separate Policy Sets. Period. I find the separation for Wireless 802.1X is very handy because I often combine it with an SSID check too - different logic per SSID - hence, give each SSID its own Policy Set. Nice and clean. It also make adds/moves/changes more atomic.

So, why not create a Wired 802.1X and a Wireless 802.1X and then you don't need to test that condition in AuthN and AuthZ. It's tested once at the top of the Policy Set as the primary "condition of entry" into that Policy Set.

And per Policy Set, I always separate out my Authentication methods

EAP-TLS -> Use a Cert Profile (e.g. that checks the SAN for an AD user credential)

EAP-PEAP -> Use an Identity Source Sequence that does a lookup in AD, then ISE local accounts

Once AuthN is taken care of, then take care of Authorization (AuthZ)

Remember that you got this far because AuthN succeeded. Therefore, you perform checks like AD membership etc.

Why are you checking Calling Station ID? I presume that is for a test of a single endpoint only?

I typically don't care about testing the EAP method again in AuthZ unless the logic really demands it. Because, in many cases you can check for AD membership in AuthZ irrespective of whether the endpoint did EAP-TLS or EAP-PEAP - the AD username is present in either EAP method and in AuthZ you would check that AD user against an AD Group. Just an example, but you get my point?

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Andrii Oliinyk — Fri, 30 Apr 2021 12:38:15 GMT

hi Arne

tnx for input. i totally agree with approach u've described, but this cube came to me as is . that's why particularly i narrowize potential modifications to selected endpoints ;0) meaning i cannot start with splitting policies at this point...

Returning to the problem though, as u can assume i started exactly with AuthC policy (no AuthZ policy yet though i've looked up username against AD & received success - good news at that moment so that i've ran to configure AuthC policy) & stuck :0o

why, how, what??? this policy SHOULD match but didnt... at that point i fell back to the simplest

If Wired_802.1X AND
Radius:Calling-Station-ID EQUALS AA-BB-CC-DD-EE-FF AND
Allow Protocols : Default Network Access and
Default : use My_AD

& it worked but got failed to AuthZ. Ok. i've configured AuthZ policy (intentionally with all that EAP-stuff)

& it worked - endpoint got fully AuthC/AuthZ'ed...

But as soon as i add that Network Access:Eap* conditions in my simple AuthC policy stuff stops to work.

Can u pls explain why Network Access:Eap* conditions dont work in my original AuthC policy?

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Arne Bier — Fri, 30 Apr 2021 21:30:44 GMT

Hello Andy

I find the best way to resolve these things is by lab testing. I have a handy way to test this without needing any equipment, other than ISE and a Linux workstation. In your example you show Wired 802.1X, but if you would agree that Wireless 802.1X is an equivalent, then I would like to share with you my lab setup below. I don't know exactly what config you put in the Policy Set Condition (the top-most part) and what you put into the Authentication Policy - let's start with the config below and then tell me if I got it wrong:

My test client is a Linux workstation with wpa_supplicant configured on it. I wrote a blog series about this years ago - still one of my favourite things to lab with. The command below sends RADIUS requests to ISE and it looks to ISE as if it came from a Wireless Controler. The user is defined in a config file:

[admin-biera@iptel-centos-01 radius]$ cat mschap.conf
#
network={
        ssid="example"
        key_mgmt=WPA-EAP
        eap=PEAP
        identity="biera"
        anonymous_identity="anonymous"
        password="MyADPassword"
        phase2="autheap=MSCHAPV2"
        ca_cert="/home/admin-biera/radius/IPTEL-ROOT.CA.pem"
}

Then a client connection is simulated with this command

[admin-biera@iptel-centos-01 radius]$ eapol_test -c mschap.conf -s secretkey -a 192.168.0.220 -M '04:00:00:00:00:DD' -N '6:d:2' -N '8:x:C0A815CA'

The output on the CLI is very long and debug-like - but we look for the last message

WPA: Clear old PMK and PTK
EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit
ENGINE: engine deinit
MPPE keys OK: 1  mismatch: 0
SUCCESS

If you have this setup in the lab, you can quickly test any ISE Policy Set.

Let me know the exact test you want to run and I can try again. I am using ISE 2.7 patch 3

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Andrii Oliinyk — Sat, 01 May 2021 09:31:12 GMT

Hi Arne

i've in that deployment number of endpoints like this. No lab is needed. Can u pls show me how AAA details look like in your case?

i guess i need turn on AAA debug on ISE to drill down this issue.

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Arne Bier — Sat, 01 May 2021 10:10:52 GMT

Do you mean the Auth result details? I need to fire up the lab again.

In the meantime can you post a screenshot of your exact policy set? I can’t follow your text based explanations.
And you’re running ISE 2.1. Ancient release and I don’t remember all the possible bugs.

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Andrii Oliinyk — Sat, 01 May 2021 12:22:28 GMT

Hi Arne

policy attached. session details r below:

Overview
Event 5400 Authentication failed
Username host/host0DTL0222.myad.local
Endpoint Id AA:BB:CC:DD:EE:FF
Endpoint Profile
Authentication Policy Default >> Dot1X >> Default
Authorization Result

Authentication Details
Source Timestamp 2021-05-01 13:56:01.837
Received Timestamp 2021-05-01 13:56:01.838
Policy Server PSN1
Event 5400 Authentication failed
Failure Reason 22044 Identity policy result is configured for certificate based authentication methods but received password based
Resolution Check the appropriate configuration in Policy > Authentication. This error happens when the identity source is configured for certificate based and received a password based authentication request.
Root cause Identity policy result is configured for certificate based authentication methods but received password based
Username host/host0DTL0222.myad.local
Endpoint Id AA:BB:CC:DD:EE:FF
Calling Station Id AA-BB-CC-DD-EE-FF
IPv4 Address 192.168.1.173
Audit Session Id 000000000004F56132ADBC21
Authentication Method dot1x
Authentication Protocol PEAP (EAP-MSCHAPv2)
Service Type Framed
Network Device SWT0S1STL
Device Type All Device Types#Switch#Production
Location All Locations#host0
NAS IPv4 Address 192.168.24.104
NAS Port Id GigabitEthernet2/0/34
NAS Port Type Ethernet
Response Time 1

Other Attributes
ConfigVersionId 492
Device Port 1645
DestinationPort 1812
RadiusPacketType AccessRequest
Protocol Radius
NAS-Port 50234
Framed-MTU 1500
State 37CPMSessionID=000000000004F56132ADBC21;38SessionID=PSN1/401633359/56582778;
NetworkDeviceProfileName Cisco
NetworkDeviceProfileId 6dd2ed4c-7ab2-4eb1-87dc-0cf56da7114e
IsThirdPartyDeviceFlow false
RadiusFlowType Wired802_1x
SSID 01-02-03-04-05-06
AcsSessionID PSN1/401633359/56582778
DetailedInfo Invalid username or password specified
CPMSessionID 000000000004F56132ADBC21
EndPointMACAddress AA-BB-CC-DD-EE-FF
ISEPolicySetName Default
AllowedProtocolMatchedRule Dot1X
IdentitySelectionMatchedRule Default
TLSCipher ECDHE-RSA-AES256-SHA
TLSVersion TLSv1
Location Location#All Locations#host0
Device Type Device Type#All Device Types#Switch#Production
Network Device Profile Cisco
RADIUS Username host/host0DTL0222.myad.local
Device IP Address 192.168.24.104
Called-Station-ID 01-02-03-04-05-06
CiscoAVPair service-type=Framed, audit-session-id=000000000004F56132ADBC21, method=dot1x

Result
RadiusPacketType AccessReject

Session Events
2021-05-01 13:56:02.382 RADIUS Accounting start request
2021-05-01 13:56:02.038 RADIUS Accounting stop request
2021-05-01 13:56:01.838 Authentication failed
2021-05-01 13:36:00.674 RADIUS Accounting start request
2021-05-01 13:35:59.376 RADIUS Accounting stop request
2021-05-01 13:35:59.213 Authentication failed
2021-05-01 13:15:57.299 RADIUS Accounting start request
2021-05-01 13:15:56.829 RADIUS Accounting stop request
2021-05-01 13:15:56.665 Authentication failed
2021-05-01 12:55:54.784 RADIUS Accounting start request

Steps
11001 Received RADIUS Access-Request
11017 RADIUS created a new session
15049 Evaluating Policy Group
15008 Evaluating Service Selection Policy
15048 Queried PIP - Network Access.EapTunnel
15048 Queried PIP - Radius.User-Name
15048 Queried PIP - DEVICE.Device Type
15004 Matched rule - Dot1X
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
12808 Prepared TLS ServerKeyExchange message
12810 Prepared TLS ServerDone message
12811 Extracted TLS Certificate message containing client certificate
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
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
12813 Extracted TLS CertificateVerify 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
22044 Identity policy result is configured for certificate based authentication methods but received password based
11815 Inner EAP-MSCHAP authentication failed
11520 Prepared EAP-Failure for inner EAP method
22028 Authentication failed and the advanced options are ignored
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
12307 PEAP authentication failed
11504 Prepared EAP-Failure
11003 Returned RADIUS Access-Reject

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Arne Bier — Sat, 01 May 2021 22:00:47 GMT

Hi @Andrii Oliinyk

I think it's safe to say that you cannot (and should not) test the EAP Inner Methods in the Policy Set Condition (in other words, the outer-most part that happens BEFORE Authentication and Authorization). In ISE 2.1 it seems you could still try and test all those methods, but they will fail. In ISE 2.7 you can still try and test MS-CHAPV2 but it will fail. I think the reason is that ISE does not check inside the EAP packets yet for the Inner Method. That is the job of the Authentication Policy configuration section. The misleading issue is that even ISE 2.7 still lets you configure MSCHAPV2 in the Policy Set Condition - not sure what the use case would be for - but for EAP-PEAP it does not work. I was able to confirm that. I think your config will be fixed if you remove that from the Policy Set and put your EAP checks into the Authentication Section.

Below shows what's still possible in ISE 2.7 - only MSCHAPV2 in the outer Policy Set Condition:

The results:

In my case, if I include the MSCHAPV2 check in the Policy Set, it will fail that Policy Set, and try the next one. In my case the nect Policy Set is called IPTEL WIRELESS 802.1X and it's a very simple Condition that only checks for "Wireless_802.1X" - that of course is good enough, and hence the Policy passes. But in our little experiment here, it proves that we had a "failure".

Re: failure to hit Authentication Protocol PEAP (EAP-MSCHAPv2) based AuthC policy

Andrii Oliinyk — Mon, 03 May 2021 11:01:01 GMT

Hi Arne

ton of tnx for your valuable help. PolicySet-writing convention like this have been always confusing me!

I've modified my original policy set (because it's Policy Set - u r totally right!) & stuff started to work :0)