Continue a failed dot1x authentication

[philipp.staiger]

Hi,

is it possible to continue to authorization policy even if 802.1x authentication has failed? I can not find any configuration which allows this scenario.

I am using PEAP MS-CHAPv2 over WiFi and want to redirect people with invalid credentials because of a missing domain to a portal. Therefore I have a authentication policy that matches on users that do not have a domain in their usernames and then cherck internal user identity store. Also I have configured all scenarios to continue. (see attachment for screenshot of the rule)

However ISE rejects the client before going to the authorization policy:

15013	Selected Identity Source - Internal Users
24210	Looking up User in Internal Users IDStore - tester
24216	The user is not found in the internal users identity store
22056	Subject not found in the applicable identity store(s)
22058	The advanced option that is configured for an unknown user is used
22060	The 'Continue' advanced option is configured in case of a failed authentication request
11823	EAP-MSCHAP authentication attempt failed
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
11815	Inner EAP-MSCHAP authentication failed
11520	Prepared EAP-Failure for inner EAP method
22028	Authentication failed and the advanced options are ignored
11006	Returned RADIUS Access-Challenge

Is this not possible in general when using 802.1x, or just not using MSCHAPv2?

Thanks in advance for any hints, info or other comments :)

[Jason Kunst · Accepted solution]

Not a feature of wireless dot1x. It runs in closed mode meaning if there is a failure then it won’t pass and traffic.

On wired it would fail to MAB and you can dim something like you listed there

[philipp.staiger]

Thank you Jason,

is there any way to run it in "open" mode without MAB but rather using 802.1x or another way to just accept any credentials?

In LAN it would also fail if the client does dot1x unless the switchport has the priority set to mab to override dot1x!? But clients would still try to rerun dot1x and kicking them out of their mab session again?

[paul]

In theory you could allow a Dot1x session to move past authentication when it fails by changing Auth Fail to Continue in the options.

Then you can check the Network Access Authentication Status to see if the user passed authentication or not.

[Arne Bier]

@paul   - I think this is not possible in the wireless world because the wireless client L2 has to match the configuration of the WLC L2 - if client WLAN profile is configured with a supplicant, then he will never be able to talk on an openssid/PSK WLAN SSID because even at the OS level there is no fall back - similarly, if the WLAN SSID is configured for 802.1X (Enterprise WPA2) then the link layer is only brought up after a successful EAP conversation - it cannot fall back half way to any other method.  In wired world we can sense the link up on the L1 electrical layer and then take steps from there.  The way I see it, in wireless, OpenSSID is like a round hole - and a supplicant is like a square peg ... it's gotta match.

[paul]

Yes the client has to do Dot1x. I am saying they don’t need to pass Dot1x. I can use the options to get around failed credentials or username not found.

[philipp.staiger]

Well, I set everything to continue and it did once but it will just try to do MSCHAP again and Fails and the second time it won't continue.

So if you @paul have any more specific Details on how you are doing it, I would also be intrested if this also works with PEAP-MSCHAPv2.

I can imagine using EAP-TLS and just use a certificate Profile without going against an identity store. But for password based methods it doesn't seem to work.

@Arne Bier I think Layer2 is not the issue here since they agree on dot1x via PEAP MSCHAPv2 and then it is only a Thing between ISE and Supplicant accepting their EAP Credentials.

I do not see, why ISE makes a difference in handling HostLookup vs. identity based methods, while People know what they are doing of course :)

[Arne Bier]

OK I am all ears now :-)   Keen to see how this works because I am sure it's something I could re-use in my own deployments.

So are you saying that if EAP-PEAP fails, then the client should be redirected to a web portal?  Sounds like a great idea.  I'd like to know how that is done too.

I can tell yo from my own experience, the only time this has worked for me is in the BYOD flow, where a client authenticates with a cert that is close to expiration. My AuthZ rule catches this condition, and causes a web redirection to the BYOD renewal portal.  BUT - and this is the crucial thing - the authentication was successful (and if you did a Wireshark you'll see that the EAP-TLS conversation came to a happy ending (EAP Success)).  This then allows the supplicant to be allowed on the WPA2 Enterprise SSID ("RUN" State) and the web redirection does its magic on that same VLAN. 

[paul]

Grr sorry, I just remember that this isn't possible. There actually used to be a message in the options fields that told you that in older versions. It is still there in the guides:



"For authentications using PEAP, LEAP, EAP-FAST, EAP-TLS, or RADIUS MSCHAP, it is not possible to continue processing the request when authentication fails or user is not found."



I have used the Continue trick before but it was for PAP ASCII based authentication on VPNs.



Sorry for the confusion.

[philipp.staiger]

That is too bad. Bummer it is not in any of the guides anymore..

However if that is not an unsolveable issue with EAP itself, this would ne a nice feature. I feel like that this is not made possible to protect the users(admins) from themselves? Could this be a feature request?

For EAP-TLS I have done it for devices which received their certificate without being in any kind of IS. And therefore without using the Continue method, as I just selected a Certificate Profile without an associated identity store. Then I only matched on the Issuer CN and for a special tag in the Subject CN. So there was no real identity based authentication behind it..