cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
457
Views
0
Helpful
3
Replies

Is ISE profiling devices into Identity groups fast enough to be used in AuthZ?

Ralphy006
Level 1
Level 1

I'm running ISE with 3850 switches and 802.1x wired. I have cisco phones with CAPF certificates used with EAP-TLS. There's a chicken/egg scenario with phones.

 

I know we can deploy new phones in a lab first that has no 802.1x restrictions, get a cert, and then deploy.

 

However, I'd prefer it to look like thi:

-Configure phone in CUCM, set to obtain a cert in the future

-Brand new phone with no cert plugs into 802.1x wired port

-dot1x failsover to MAB

-ISE ideally profiles the phone via profiling/Identity Group and there is an AuthZ rule referencing this. And puts a remediation DACL on the port that allows the phone to register to CUCM and obtain a cert.

-After it gets the cert, the phone reboots with the cert, and then dot1x succeeds and the phone gets properly put on the voice-domain with no DACL

 

However, when the phone plugs in for the first time, the AuthZ rule referencing the Cisco-IPPhone Identity group doesn't get hit. It hits the GUEST-DACL.

 

The phone ends up re-auth'ing and eventually gets the remediation DACL. But is there a way to make it so it profiles faster so AuthZ policies can use the identity groups?

 

We use radius accounting and device sensors

1 Accepted Solution

Accepted Solutions

That looks like a good concept to me. The profiling is done using device sensor on the switches? That should be pretty fast actually. Every new CDP/LLDP Info Element should trigger an immediate RADIUS Interim Accounting update to ISE which will then learn that there is a phone on that port. Check the prescriptive Wired 802.1x guide. Then ISE sends a CoA to reauth that port. Now your AuthZ for phones will be hit before the catch all rule, because you place them higher in the AuthZ list ;-)

View solution in original post

3 Replies 3

Arne Bier
VIP
VIP

Sounds to me like it’s working as designed. If you have to wait to fail 802.1x and fail MAB to eventually end up in the remediation VLAN then this is the way to go. It will take time to fail all the way through. Maybe you can make the timers more aggressive. Alternatively you could try IBNS 2.0 which allows multiple authentication methods in parallel (usually 802.1x and MAB). Not sure if that will allow you to fail through to remediation VLAN ?

 

 

Thanks for the response.

 

I actually have 2 different types of "remediation" VLAN's:

  1. For Phones. To register with CUCM and pull a certificate
    1. The device only gets put into this if it's profiled as a Cisco Phone
  2. Catch-all GUEST. Internet-only (blocks RFC1918)

So the problem is it always first falls into the catch-all since it's not profiling the Cisco Phone fast enough. Is that normal? And after it profiles, does it send the device through the AuthC and AuthZ policies again automatically? Or does it their need to be a re-auth triggered by the switch?

That looks like a good concept to me. The profiling is done using device sensor on the switches? That should be pretty fast actually. Every new CDP/LLDP Info Element should trigger an immediate RADIUS Interim Accounting update to ISE which will then learn that there is a phone on that port. Check the prescriptive Wired 802.1x guide. Then ISE sends a CoA to reauth that port. Now your AuthZ for phones will be hit before the catch all rule, because you place them higher in the AuthZ list ;-)