802.1x MAB Inaccessible Authentication Bypass

[aurelijus]

Hello Cisco community,

I have an issue with Inaccessible Authentication Bypass.
On Catalyst 9300 stack we have configured interfaces with multi-auth (802.1x and MAB).
We want that unauthorized users would have the access to Internet, so if authentication fails - device gets VLAN that can only access Internet.

Configuration on the interfaces:
interface GigabitEthernet1/0/x
switchport mode access
authentication host-mode multi-auth
authentication order dot1x mab
authentication port-control auto
authentication event fail action authorize vlan 17
authentication event server dead action authorize vlan 17
mab
dot1x pae authenticator
dot1x timeout tx-period 10
dot1x max-reauth-req 2
dot1x timeout reauth-period 3600
spanning-tree portfast

What we see on Cisco ISE that unauthorized pc keeps trying to connect and never gets VLAN 17.

Is there any command missing on the interface?

[MHM Cisco World]

Friend there is different between failed user and user not try auth'

In your case the user not try auth and hence you can not use critical vlan you need to use guest vlan.

dot1x guest-vlan xxx

Try this in one port and check

MHM

[ahollifield]

You should push VLAN 17 from ISE in an authz profile

[Aref Alsouqi · Accepted solution]

I agree with Adam @ahollifield, you should push the VLAN 17 attribute from ISE for the users that would fail authorization not authentication. Although you can change the action for the users that would fail the authentication in ISE, however, you wouldn't be able to return any authorization attribute to the switch from there because the supported actions are continue, reject, and drop. This is why you need to configure this task in an authorization profile and apply that profile to an authorization rule.

In the authorization profile you would need to configure VLAN 17's attribute to be returned to the switch and then you create (if you don't want to change the default authorization rule's authorization profile) an authorization rule and you apply the authorization profile to it.

One thing to keep in mind is that if you want the MAB devices to hit this new authorization rule (or the default one) then you would need to change the option "If user not found" in the MAB authentication rule to be "Continue", otherwise, the unauthenticated MAB devices will be dropped at the authentication level and will never make it to go through any authorization rule. Configuring "If user not found" to "Continue" doesn't mean that the MAB devices will have access to your network just because they passed the authentication, they will still be subject to go through the authorization rules, and first match will be applied to them.

The command "authentication event server dead action authorize vlan 17" wouldn't take effect unless ISE is unreachable, in that case the switch will force the critical VLAN assignment (inaccessible authentication bypass), but this won't apply in your case as you want to divert the unauthorized users to a specific VLAN while ISE is still up and running.

On the other hand, please keep in mind that as a best practice, you should also apply the critical VLAN assignment command to the voice VLAN, and also to configure the switch to re-initiate the authentication on the port once ISE is back up and running. You would need to add these two commands:

authentication event server dead action authorize voice
authentication event server alive action reinitialize

[MHM Cisco World]

Can I ask you how you can config your suggestions'

Auth policy will contain internal endpoints and if the endpoint unknown then then continue

Then we check authz policy (by order) how we can config it?

I confuse in this point 

Thanks

MHM

[Aref Alsouqi]

Sure. If you go to ISE policy set, in the far right column of the MAB authentication rule you should see a little arrow to expand the options. That will give you a menu with three options, "If Auth fail", "If User not found", and "If Process fail". The one that should be changed from its default "Reject" to "Continue" is the "If User not found" option.

That will then allow the unknown MAC addresses to pass the authentication. However, passing the authentication doesn't mean the devices will be allowed access to the network, because they will still be subject to the authorization rules, and based on the match, the action will be applied. In case no match will be found, they will hit the default authorization rule at the very bottom.

Let me know if any further question please.

[MHM Cisco World]

One more Q the defualt authz what is condition will be used here in this case.

Thanks alot 

MHM

[Aref Alsouqi]

[Greg Gibbs]

Based on the shared configuration, I can see you're using the legacy IBNS configuration which had multiple issues with handling failure scenarios. You should be using the IBNS 2.0 configuration as per best practice documented in the Secure Wired Access Prescriptive Deployment Guide. It has built-in features to handle failure scenarios much better, such as Critical VLAN.

[MHM Cisco World]

Hi @Greg Gibbs can yoh share good ciscolive slides about how to build ibns or migrate from legacy to ibns

Thanks alot 

MHM

[Greg Gibbs]

Hi @MHM Cisco World ... IBNS 2.0 (a.k.a. Policy-Aware IBNS) has been around for 7+ years now, so I don't think there are any Cisco Live presentations available any longer that focus solely on that. The document I shared is the best reference and is considered the Cisco validated design. It includes details on converting from legacy IBNS to IBNS 2.0 and the switch config automated by Catalyst Center is also largely based on that policy configuration.

[aurelijus]

.