Cisco VoIP phones onboarding via MAB, then auth via 802.1x ?

[andrew_cooper]

Hello, how do most people use ISE to authorize Cisco VoIP phones on their network out of the box?  In my testing I had created a MAB policy that allowed profiled Cisco VoIP phones to authenticate and the authorization policy assigned them a dACL that restricted them to DCHP, and the option 151 TFTP server for them to pull their config. Once they pulled their config 802.1x is enabled and they reboot and authenticate via EAP-TLS.  

The issue I found with this method is for a brand new phone, ISE will fail the MAB authentication the first time it tries to connect because the MAC was not yet profiled.  Once it fails though the endpoint exists in ISE's endpoint list and it is profiled successfully as a Cisco phone.  If you re-connect the phone 30 seconds or so later MAB will pass the 2nd time.  I tried to figure this out on my own but I haven't been able to find a solution I like.  I changed my dot1x policy-map on the switch to re-try MAB every 60 seconds on failure which achieves the desired end result.  The problem is endpoints that are turned off, or should be denied just keep trying to authenticate every 60 seconds on a never ending loop....

Am I being dumb here?  Is there a better way to do what I'm wanting to do, or get ISE to profile a device BEFORE it makes its first authentication decision?  Below is my switch config

policy-map type control subscriber Dot1x-Default
event session-started match-all
10 class always do-all
10 authenticate using dot1x priority 10
20 authenticate using mab priority 20
event violation match-all
10 class always do-all
10 restrict
event agent-found match-all
10 class always do-all
10 terminate mab
20 authenticate using dot1x
event authentication-failure match-all
10 class AAA-Down do-all
10 authorize
20 activate service-template CRITICAL
30 terminate dot1x
40 terminate mab
20 class Dot1x-Failed do-until-failure
10 authenticate using mab
30 class MAB_FAILED do-until-failure
10 authentication-restart 60

interface GigabitEthernet1/0/8
description 802.1x TEST
subscriber aging probe
switchport access vlan 310
switchport mode access
switchport voice vlan 510
device-tracking
authentication periodic
authentication timer reauthenticate server
access-session host-mode multi-domain
access-session closed
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
service-policy type control subscriber Dot1x-Default
ip dhcp snooping limit rate 5

[Pawan Raut]

i think you should try the first ISE to profile a device BEFORE it makes its first authentication

[andrew_cooper]

Yes that was one of my questions.  How do I get ISE to profile based on MAC OUI before it performs the first authentication 

[Greg Gibbs · Accepted solution]

I suspect the issue here is that you have default AuthZ Policy that is sending an ACCESS_REJECT and when first connected. MAB happens immediately upon connecting, so the phone is hitting that default policy and and receiving the ACCESS_REJECT response.

When endpoints receive an ACCESS_REJECT they typically go into a waiting period before retrying authentication (retry period depends on the endpoint supplicant and settings).

A better approach is to use a default AuthZ policy that sends an ACCESS-ACCEPT with a restrictive DACL (permit only DHCP, DNS, TFTP, etc). This way the phone will connect and get an ACCESS-ACCEPT with restricted access. Once the profiling completes based on DHCP and CDP info received by ISE, it should send a CoA to change the AuthZ of the phone.

Using this approach also mitigates issues with endpoints constantly retrying authentication.

[andrew_cooper]

In this scenario would you change the default authentication policy to "if User not found = continue" ?  Right now it rejects authentication because the MAC is not yet an internal endpoint.  I just did a little bit of testing and found it would only work if I allowed Voice Domain Permission as part of the Autz Profile for the restrictive DACL.  I assume this is expected behavior when using multi-domain mode?  Thanks for your help!

[Greg Gibbs · Accepted solution]

Yes, you would need an AuthC Policy rule for MAB with 'If User not Found = Continue' to allow the session to "fall-through" to the AuthZ process to provide authorisation based on endpoint profile. I typically use a separate AuthC Policy matching on Wired_MAB and using the 'Internal Endpoints' ID store, but you could do the same with the Default AuthC Policy.

Regardless of the switchport mode (Multi-Domain, Multi-Auth, etc), when dot1x/MAB are enabled, the switchport requires the RADIUS server to respond with the Voice Domain Permission to authorise the phone on the configured Voice VLAN.