topic Re: Concurrent MAB/Dot1x Again in Network Access Control

Concurrent MAB/Dot1x Again

paul — Thu, 03 Dec 2020 19:00:09 GMT

Yes I know I have exhausted this topic on my previous post (https://community.cisco.com/t5/network-access-control/cpl-template-mab-dot1x-simultaneously/td-p/3749539) but I wanted to post again to ask a question of the BU on this topic.

As a recap, CDW's standard since IBNS 2.0 came out is to do concurrent MAB/Dot1x. We have 10s of millions of switchports running concurrent MAB/Dot1x without an issue. We still use concurrent MAB/Dot1x on all of our installs today. So I started to ask myself "Why have we never seen a problem, but Cisco BU/TAC says their could be?"

If I look a the main bug that documents this issue, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy05270/?rfs=iqvred, the verbiage reads like this:

"ISE is dropping Radius-Access requests when Switch sends dot1x and MAB at the same time

live logs will show what looks like multiple failed mab authentications and possibly client suppression."

Thanks second line seems to imply live logs showing failed MAB attempts which might mean MAB rules that use Access-Reject in the result so ISE might get confused and do client suppression.

In our CDW best practices we never issue Access Rejects for MAB results for two reasons:

If the switch port is in Open mode the Access Reject is ignored.
If you are issuing Access Rejects as your bottom MAB rule you are denying ISE the ability profile new devices using NMAP and SNMP data collection. Our default rule is an Access Accept with a limited access DACL to allow ISE PSNs to profile unknown devices.

Is there any chance the fact that we never issue an Access Reject to our MAB results the reason we have never seen issues with concurrent MAB/Dot1x? If so can we get the wording changed on the bug to include a work around of never issuing an Access Reject for MAB results?

Thanks.

Re: Concurrent MAB/Dot1x Again

Massimo Baschieri — Fri, 18 Dec 2020 16:19:36 GMT

Probably those in attachement are the kind of issue the bug refers to.

I can see very few of them and it seems that host recover very quickly as you can see in the logs

Concurrent MAB/Dot1x Again

Fernando G — Wed, 19 Apr 2023 00:24:32 GMT

Hi @paul

Did you had any confirmation from ISE BU regarding this scenario? That you never experience issues due never sending an "access-reject" to MAB use cases, when using dot1x/mab simultaneous on the switches?

Regards,

Fernando

Re: Concurrent MAB/Dot1x Again

paul — Wed, 19 Apr 2023 12:30:09 GMT

The BU hasn't said anything more on this issue that I know of, but they really can't take a position that concurrent Dot1x/MAB is not supported any more. Meraki put this feature in 2 years ago into their switches. We still use it on all our installs and have been doing it for 4+ years with no issues.

Re: Concurrent MAB/Dot1x Again

ahollifield — Wed, 19 Apr 2023 16:38:49 GMT

Same experience as @paul above

Re: Concurrent MAB/Dot1x Again

Fernando G — Thu, 20 Apr 2023 01:00:49 GMT

Thanks @paul and @ahollifield for your feedback.

That gives me confidence in suggesting that option. The user experience in doing so it's so much better.

It's really weird from Cisco ISE BU not to clarify the scenarios that they support or not, with IBNS 2.0 simultaneous dot1x/mab auth requests.. A competitor NAC solution that I also deploy as part of my job. Support that feature without any issue

Regards,

Fernando.

Re: Concurrent MAB/Dot1x Again

Arne Bier — Thu, 20 Apr 2023 20:15:36 GMT

@paul and @ahollifield

The only thing I would add is to please keep an eye on the ISE Context Visibility for such endpoints. I can't say 100% for sure, but most of the endpoints that I checked in my 3.0p4 network show that MAB was used for authentication, and when I go to the switch, the session was authorized with 802.1X. So yes, the concurrent auth method does work and the endpoints are happy. But ISE can often report the wrong Auth state. It seems that if MAB comes in first and completes, then ISE will record that - even if 10ms later, 802.1X trumps that session and remains in that state. ISE will still report MAB. I think that is perhaps what the ISE BU needs to address (or perhaps will never address).

Re: Concurrent MAB/Dot1x Again

paul — Thu, 20 Apr 2023 21:20:01 GMT

@arn 100% true. I always educate my customer on the inaccuracies of the Context Visibility screen. There are many situations outside of simultaneous MAB/Dot1x where the CV shows the wrong data. I identified issues back in 2.3 with this (have bug numbers) but they have never been fixed. It is why I still need to support an Excel Macro I wrote back in ISE 1.1 that accurately processes RADIUS Auth data to let customers know the last rule the MAC addresses hit.

Re: Concurrent MAB/Dot1x Again

danmassa — Thu, 29 Jun 2023 12:42:02 GMT

@paul , we aren't doing simultaneous dot1x/mab. We are currently doing dot1x-then-mab. We do this because Macs will not do the dot1x unless the switch starts the conversation.

But we would like to do either simultaneous dot1x/mab or maybe mab-then-dot1x because the dot1x timers mess up the devices that are trying to get on and do DHCP. As noted, some clients will give up on DHCP rather quickly!

I think I found a creative solution. We also never send a access-reject on a MAB policy map. I tweaked this event to handle that case...

event authentication-success match-all ! If AUTH with ISE was successful and if it was MAB… 10 class MAB do-until-failure ! Send the EAP-Request/Identity message. ! This should trigger both MAC OSX and Windows 10 devices ! to start the dot1X process. 10 authenticate using dot1x retries 2 retry-time 0 priority 10

With this setup we do the mab-then-dot1x serially, which totally bypasses the bug (behavior defect) that Cisco is referencing.

Probably 85% of our wired devices are BYOD and never do the dot1x, so the load on ISE is pretty low; most devices do the MAB and never end up doing the dot1x. Because we are doing MAB first we bypass all the dot1x retry timers, so devices get on really fast and can get an IP via DHCP.

Does this solve all problems? For devices that do dot1x it is a little bit slower because it does have to complete the MAB first before it can start the dot1x. But again, that's only happening for 15% of our devices. Also, the MAB happens very quickly because there are no back-end Windows AD lookups or anything else that would take dozens of milliseconds.

I can send the full IBNS config to you if you like.

Re: Concurrent MAB/Dot1x Again

danmassa — Thu, 29 Jun 2023 12:46:00 GMT

@paul I am attaching the full modified IBNS config...

I'm interested to hear your thoughts.

Re: Concurrent MAB/Dot1x Again

Andrii Oliinyk — Thu, 18 Jan 2024 13:22:24 GMT

Hi @danmassa
would appreciate you sharing it.
tnx in advance

Re: Concurrent MAB/Dot1x Again

danmassa — Thu, 18 Jan 2024 13:48:54 GMT

Here it is...

Re: Concurrent MAB/Dot1x Again

Andrii Oliinyk — Thu, 18 Jan 2024 14:30:46 GMT

tnx dude

noticed it reading just 1msg below :0)