Cisco ISE Profiling - Enabling DHCPSPAN

[MattMH]

Does anyone know if enabling the DHCPSPAN service on the Deployment Node impacts production traffic for ISE?

I am asking because I suspect our MAB devices are not getting profiled correctly. I would like to see if this is the issue (it is currently not enabled), but concerned this will impact our production environment.

[Rodrigo Diaz]

hello @MattMH , with the DHCPSPAN probe the ISE will consume resources in order to process the data as the traffic is directly mirrored to one of the interfaces of the PSN through SPAN or RSPAN , for this scenario the impact will be directly related to the amount of data you send in this probe, as a Cisco best practice is recommended to use DHCP probe rather than this DHCP SPAN probe, also if you are using MAB as authentication method another alternative would be using radius probes through device-sensor feature on the NAD, for your reference :  https://community.cisco.com/t5/security-knowledge-base/ise-profiling-design-guide/ta-p/3739456#toc-hId-826550277 

Let me know if that helped you. 

[MattMH]

Thanks Rodrigo, I confused DHCP with DHCPSPAN, and shortly after my initial post I realized that.

I might be missing something then.

Our profiling is technically working. If I look at a Cisco IP Phone, which is a MAB device I am testing to start with, I can see in the live logs the device is profiled as a Cisco 8845. It authenticates and gets authorization.

Then I make a change. I remove the device from ISE and the "authentication open" from the switchport config.

My live logs then show it is failing. I get these errors in this order...

Event	5400 Authentication failed
Username	5C:E1:76:84:BE:E2
Endpoint Id	5C:E1:76:84:BE:E2
Endpoint Profile
Authentication Policy	Area 51 IP Phone >> Wired MAB Area 51
Authorization Policy	Area 51 IP Phone >> Default
Authorization Result	DenyAccess

Overview

Event	5205 Dynamic Authorization succeeded
Username
Endpoint Id	5C:E1:76:84:BE:E2
Endpoint Profile
Authorization Result

Its not in the Internal Endpoints IDStore, which makes sense to me why it is failing then.

In that failed log, I also see ISE has not confirmed locally previous successful machine authentication for user in Active Directory, which is odd since I am not looking at AD for a MAB device.

Anyway, it does not get profiled correctly when that "authentication open" command is removed. It then hits the default authorization rule to deny access. It is the same policy set rule that passed it with authentication open applied. It seems like it is passing authentication, but since it is no longer profiling it as a phone, it is denied.

What I am failing to understand is, is authentication open required for MAB to work? Right now, when authentication open is applied, the switchport ACL kicks in and it has permit ip any any, so I am assuming something in that interim period between authentication and authorization is happening.

When this is erroring out, I see the phone mac address on both data and voice vlan in a "drop" state

My goal, which is perhaps again related to my misunderstanding, is that if profiling is configured, we can get rid of the authentication open switchport config to increase security.

[Rodrigo Diaz]

hi @MattMH , answering your question is authentication open required for MAB to work? , it can be either auth open o by having catch policy, what you can do in any case is to apply a rule only allow communications with the ISE and a access-accept instead of the permit ip any any and have in this instance the auth closed, what it happens here is that the ISE sometimes does not get enough information to profile the endpoint and when this occurs and the port is sent to auth failure ,the ISE cannot longer get more attributes about what you are connecting, if you allow communications with ISE to these kind of devices categorized as unknown you will ensure that the NAD has enough time to send information probes on ISE and when the ISE has determined a profile for the endpoint this will send a CoA ( you can see what you have configured in work centers> profiler > settings >profiler settings )  hence when the coa is being issued the device will be hitting a new rule that has higher precedence with the Cisco IP phone version you mention. 

Rate and comment if this is helping .

[MattMH]

OK, might be onto something here. I can get a phone to auth with the proper profile, but it takes ISE greater than 10 minutes to figure out the device was a profiled phone. I'll have to re-read your reply a few times. However, I can see in the logs there is def a COA occurring between "Cisco-Device" and "Cisco-IP-Phone-8845"

Can you elaborate on your comment, "apply a rule only allow communications with the ISE and a access-accept instead of the permit ip any any and have in this instance the auth closed"?

[Rodrigo Diaz · Accepted solution]

sure , when configuring this catch policy you need to assign it to an authorization profile , within the authorization profile there will be an Access-Accept Radius that the PSN will be sending to the NAD session, also within this authorization profile you can place a DACL/ACL where you will only allow communication to ISE (Then due to the CoA for profiler, you will be hitting another rule once the profiler has completed the device identification), this will replace the authentication open that you mentioned you have or any authorization profile where you are allowing a permit ip any any.