
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2017 09:09 PM
I have never got a convincing answer to this authentication order and priority.
In our environment we have both priority and order set to dot1x mab
The recommendation was not to switch these since some devices although configured for dot1x will attempt MAB since ISE already knows about this endpoint in its database. Is that still correct ?
Ideally we want to do MAB first to weed out the non dot1x devices in Authorization.
Solved! Go to Solution.
- Labels:
-
Identity Services Engine (ISE)
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2017 09:24 PM
In my many installs since 1.0 I have always done "dot1x mab" for order and priority as the standard. If you are keeping your switch port in open mode the point is mostly moot as the MAB devices will be allowed onto the network while dot1x is timing out. If you are running in closed mode on the port then there is going to be a period of 20-30 seconds of no network access (with modified timers) while dot1x is timing out.
With the newer switches running the new style ISE configs you can actually running dot1x and MAB simultaneously making even the closed mode issue moot.
The issue I have had in the past when you reverse the order and go "mab dot1x" you are requiring the attaching device to initiate the Dot1x authentication. The switch will not initiate unless MAB is denied which is almost never. I have had issues in the past with Mac OS only being a responder to Dot1x and will not initiate. I don't know of that is still true as I always do "dot1x mab" so the switch is initiating.
Those are my thoughts.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2017 09:24 PM
In my many installs since 1.0 I have always done "dot1x mab" for order and priority as the standard. If you are keeping your switch port in open mode the point is mostly moot as the MAB devices will be allowed onto the network while dot1x is timing out. If you are running in closed mode on the port then there is going to be a period of 20-30 seconds of no network access (with modified timers) while dot1x is timing out.
With the newer switches running the new style ISE configs you can actually running dot1x and MAB simultaneously making even the closed mode issue moot.
The issue I have had in the past when you reverse the order and go "mab dot1x" you are requiring the attaching device to initiate the Dot1x authentication. The switch will not initiate unless MAB is denied which is almost never. I have had issues in the past with Mac OS only being a responder to Dot1x and will not initiate. I don't know of that is still true as I always do "dot1x mab" so the switch is initiating.
Those are my thoughts.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2017 07:34 AM
Thanks for the info Paul.
I am very interested in "With the newer switches running the new style ISE configs you can actually running dot1x and MAB simultaneously making even the closed mode issue moot."
Do you have more information ?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2017 07:59 AM
Check out this:
https://communities.cisco.com/docs/DOC-68174
This is the newer style CPL language on the 3850s. My config template is a bit more stripped down than what is in the link above, but concepts are the same.
Paul Haferman
Office- 920.996.3011
Cell- 920.284.9250

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-17-2017 02:16 PM
In our environment
order: mab dot1x
priority: dot1x mab
This made sense in our environment as we wanted to accommodate MAB devices quickly and not make them wait for dot1x timeout. Using the priority allows for dot1x to overrule the MAB process if it sees EAPoL traffic. This assists with quick connection time as well for dot1x nodes.
Issues we faced was that dot1x supplicants could not re-authenticate properly and send EoPLan packet to restart dot1x process. This occurred on Windows, MAC, native as well as AnyConnect supplicants. Only way we found at the time to resolve was to either change order to dot1x mab OR turn off re-auth.
We just recently modified one of our AuthZ profiles to use cisco av-pair = termination-action-modifier=1 .
This will have ISE instruct the switch to re-use the last successful method wether it was dot1x or mab for that session.
This so far has resolved these struggles. We are continuing to test

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-18-2017 09:40 AM
Thank you for sharing your thoughts.
-Krishnan
