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

ISE 2.1 - Profiling "Timing" Issue

juror8
Level 1
Level 1

I have a customer with a large distributed deployment running 2.1.  They have a wired policy set that defaults to a CWA so that they are able to support wired guests.

When devices are plugged into the network for the first time, ISE works on profiling but before this completes, the device runs through the authorization policies and ends up in the CWA flow.

Typically you would think that using the "CoA reauth/port-bounce" option on the device profile (or using the global one) would force the device to re-authenticate after profiling is complete but according to Cisco, this is not the case when the end device is in the CWA flow.

After speaking with TAC, the only option I have is to set a CWA timeout (currently 5 minutes) that will force the device to go through authentication again and this will place the device in the right authorization profile.

This is not an optimal setup for this customer and wondering if there is another fix/work around.

1 Accepted Solution

Accepted Solutions

nspasov
Cisco Employee
Cisco Employee

Yes, that is an expected behavior. Think about it, if CoA happens when a device enters CWA flow then the user/device would never be allowed to complete a web auth :)

I had to deal with issue in the past with IP Phones being stuck in CWA flow. The way I resolved this was by creating a more specific rule above the CWA one. For instance, with Cisco Phones. I created a rule that looked for "Profiled Cisco Devices" that allowed those devices enough network access to be re-profiled as Cisco Phones and consequently hit the "Profiled Cisco Phone" rule. As a result, those devices never hit the CWA rule. 

I have also used "Auto-Smart Ports" where I simply did not run 802.1x on port if a Cisco device (AP, Phone, Video Conferencing Unit, etc) was plugged in. The switch port was automatically re-configured to run 802.1x if one of those devices was unplugged. 

I hope this helps!

Thank you for rating helpful posts!

Thank you for rating helpful posts!

View solution in original post

3 Replies 3

nspasov
Cisco Employee
Cisco Employee

Yes, that is an expected behavior. Think about it, if CoA happens when a device enters CWA flow then the user/device would never be allowed to complete a web auth :)

I had to deal with issue in the past with IP Phones being stuck in CWA flow. The way I resolved this was by creating a more specific rule above the CWA one. For instance, with Cisco Phones. I created a rule that looked for "Profiled Cisco Devices" that allowed those devices enough network access to be re-profiled as Cisco Phones and consequently hit the "Profiled Cisco Phone" rule. As a result, those devices never hit the CWA rule. 

I have also used "Auto-Smart Ports" where I simply did not run 802.1x on port if a Cisco device (AP, Phone, Video Conferencing Unit, etc) was plugged in. The switch port was automatically re-configured to run 802.1x if one of those devices was unplugged. 

I hope this helps!

Thank you for rating helpful posts!

Thank you for rating helpful posts!

Neno,

Thank you for your response and that definitely does make sense.  I have since created a "Parent profiling" rule above the CWA that was supposed to trap both "Cisco-Device" and "HP-Device".

The idea being that the phones and printers would be captured before hitting the CWA and then I could invoke the CoA action.

Question: Would I need to create a separate rule for each level in the profiling tree (unless I pull one of them out to make a separate identity group?  For example, 'Cisco-Device' then 'Cisco-IP-Phone' then to something more specific?

You are welcome and apologies on the delayed reply! 

To answer your question: I only create such "parent" rule for devices that I have/had problems profiling properly. So this would depend on your environment :)

I hope this answers your question!

Thank you for rating helpful posts!

Thank you for rating helpful posts!