ISE performs MAB lookup even though 802.1x on that endpoint

[creserva1]

If I am using 802.1x as my authentication I don't need to Active Directory probe right? 

Here are my switch config

class-map type control subscriber match-all DOT1X_NO_RESP
match method dot1x
match result-type method dot1x agent-not-found

class-map type control subscriber match-all MAB_FAILED
match method mab
match result-type method mab authoritative

policy-map type control subscriber DOT1X-DEFAULT
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x priority 10
event authentication-failure match-first
10 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
20 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
30 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 60
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x priority 10

Interface gi0/2
switchport access vlan 10
switchport mode access
authentication timer reauthenticate server
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 2
spanning-tree portfast
spanning-tree bpduguard enable
service-policy type control subscriber DOT1X-DEFAULT

When new endpoints connects, looking on Radius Live Logs, ISE performs MAB lookup even though I have turned 802.1x on that endpoint. Is there I need to be checking on the switch configuration that triggers MAB?

[hslai]

If I am using 802.1x as my authentication I don't need to Active Directory probe right?

---

As your endpoint is 802.1X with its computer credentials, you are correct that it does not really need the ISE profiler AD probe to collect AD info. We may use the computer AD groups or attributes to further authorize, if needed.

class-map type control subscriber match-all DOT1X_NO_RESP
match method dot1x
match result-type method dot1x agent-not-found

... 

policy-map type control subscriber DOT1X-DEFAULT
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x priority 10
event authentication-failure match-first
10 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
20 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
30 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 60
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x priority 10

... 

When new endpoints connects, looking on Radius Live Logs, ISE performs MAB lookup even though I have turned 802.1x on that endpoint. Is there I need to be checking on the switch configuration that triggers MAB?

---

Actually, it's the switch that initiates MAB while ISE responding and recording the event.

Your switch configuration looks the same as the first example given in IBNS 2.0 Deployment Guide. The Figure 5 in the guide shows,

DOT1X_NO_RESP means no response from the endpoint. When that happens, it terminates 802.1X and starts MAB.

I believe there is a small time gap before the switch detects an EAPoL frame from the endpoint so that DOT1X_NO_RESP triggered. Once it detects EAPoL start, it should switch back to DOT1X due to the event agent-found.

If you prefer trying DOT1X first and then MAB, I think it might be better to use a different control class. For example,

class-map type control subscriber match-all DOT1X-FAILED

match method dot1x

match result-type method dot1x authoritative

Troubleshoot Identity-Based Networking Services (IBNS) 2.0 - Cisco has info on IOS switch debugging that might of interest to you.

[creserva1]

That was my thought is dot1x first then mab. Your suggestion is to use different class control so it will match-all the dot1x first then after endpoints didn't match the dot1x control class the switch will trigger the next class control for MAB. 

[hslai]

Yes and no. Your configuration is fine other than it's like doing auth order mab dot1x with dot1x higher priority. This is good in many cases.

On the other hand, if you want it more like auth order dot1x mab, then yes, it's good to use the other dot1x control class, which waits for dot1x auth to timeout and fail before attempting mab.

I got the configuration fragment from Hosuk's How To: Universal 3850 Wired Class-based Policy Language (C3PL) Configuration for ISE.

[BHAGEMANN]

Depending on what clients you want to authenticate the MAB-use besides 802.1x makes sense. 

Think of older printers for example. 

We just testet 802.1X with a small amount of clients and used the following in addition to the config on the ports.

authentication order mab dot1x
authentication priority dot1x mab

This will make the system look für MAB and then 802.1X and if the endpoint is able to perform 802.1X this authentication will be used instead of the MAB-Authentication. 

You can also play with the counters for both, but we got issues with the PXE-boot because the 802.1X method with its timer and then the MAB-method with its timer took too long for the endpoint to get DHCP and the PXE-boot-offers. 

So first making MAB an then 802.1X made more sense for us and got the PXE-boot working.

[creserva1]

Did you had to build your database for ISE to know all the endpoints? Like you had to do phase 1 pretty much have ISE to allow anything before creating your policy sets right?

[BHAGEMANN]

Hi!

I am pretty new to this forum and  I am not sure if your reply refers to my post or the op.

So, if you asked me: 

1. First we created a ruleset that would make  the ISE controll everything but with result "access permit". 

2. On the switches we had configured authentication open

3. We configured the switches to MAB-Authentication

----- Till now the ISE would do her job but won´t prevent any endpoint to enter our LAN, but we could get all endpoints that were missing in our endpoint database, check them and enter them to the fitting authentication group. All the endpoints were imported via .csv and we used our DHCP as database, but there were several endpoints missing like NAS, some older endpoints... -----

4. After setting every switch to MAB-Auhtentication via the "lookup"-regulatory on the ISE and no unknown endpoints popping up for two weeks we started to configure switch/stack by switch/stack to the productive rule-set which would prevent unknown endpoints to enter our LAN by MAB. -> Set Switch to MAB authentication and change groups in ISE from "look-up" to productive. 

Short story: We worked with 2 rulesets, one "look-up" one productive, switches with authentication open, added all endpoints needed, switched ISE to productive rule-set and configured switches to authentication MAB. (The rest of the cofngiuration needed for ISE was already on the switches.)

[BHAGEMANN · Accepted solution]

Hi!

I am pretty new to this forum and  I am not sure if your reply refers to my post or the op.

So, if you asked me: 

1. First we created a ruleset that would make  the ISE controll everything but with result "access permit". 

2. On the switches we had configured authentication open

3. We configured the switches to MAB-Authentication

----- Till now the ISE would do her job but won´t prevent any endpoint to enter our LAN, but we could get all endpoints that were missing in our endpoint database, check them and enter them to the fitting authentication group. All the endpoints were imported via .csv and we used our DHCP as database, but there were several endpoints missing like NAS, some older endpoints... -----

4. After setting every switch to MAB-Auhtentication via the "lookup"-regulatory on the ISE and no unknown endpoints popping up for two weeks we started to configure switch/stack by switch/stack to the productive rule-set which would prevent unknown endpoints to enter our LAN by MAB. -> Set Switch to MAB authentication and change groups in ISE from "look-up" to productive. 

Short story: We worked with 2 rulesets, one "look-up" one productive, switches with authentication open, added all endpoints needed, switched ISE to productive rule-set and configured switches to authentication MAB. (The rest of the cofngiuration needed for ISE was already on the switches.)

[creserva1]

I think this is similar to our deployment now. I have all new stack switches with 802.1x configured on all switchports and created a groups phase 1 just basically every switches on the new building so anyone connecting to these switches will grant access. My thought was to build up the database so I could create necessary rules for authentication mab and 802.1x then move into next phase 2

From lurking around most of everyone are doing mab and 802.1x at the same time while the priority is 802.1x