Security

We have a Clearpass 6.3.4.64924 environment that we are authenticating 802.1x users against, primarily a hodge podge of different clients. One of the enforcement policy rules we have setup for one of our Corp SSIDs is Authorization:Endpoints Repository Category equals SmartDevice then Deny Access, primarily because we want to keep devices like SmartPhones and Tablets off of this SSID. This has been working great however we are noticing an anomaly with the rule, we use RADIUS acct packets to profile devices. Occasionally there will be an iPhone or other SmartDevice that slips thru the cracks and gets on our corp SSID where the enforement rule applied, after trending data and comparison of Access Tracker entries we are starting to notice that these SmartDevices that are getting on have no RADIUS acct logs therefore arent getting profiled, and the SmartDevices that are getting denied as they should do have accounting logs associated and are getting profiled correctly. I am wondering if there is anyone else out there having this same issue and if so what the root cause / fix is? The WLCs involved are a mixture of Cisco 2504/5508 Controllers in a large distributed deployment that is geopraphically disperse.We have seen the issue present pretty much at random across many different locations. Any insight on this would be greatly appreciated.

 

Thanks,

 

Mark

So you're not using ClearPass profiling? 

 

Does the accounting data contain a profile that the wireless controller determines?

Hi Tim,

 

From what I understand Clearpass is using the RADIUS accounting packet information it recieves from the WLC to determine a profile for the device. If the device is catagorized as a SmartDevice, we want to keep it off of our Corp SSID. As I mentioned, this works as expected however there are a few devices (iPhones for example) that are connecting and should not be based on the enforcement policy rule, a common factor here is that there are no accounting logs for these sessions therefore our theory is they are not getting profiled at all and are skipping over the rule we have defined to keep them off. So, my question would be if this is a known issue is there something that can be addressed on the Clearpass side of this equation to improve things. Right now DHCP profiling isn't going to be an option, given the complexity of our environment and limitation of the Cisco WLC only being able to support 2 IP Helper addresses for DHCP relay.

Can you confirm that the controller is sending the accounting packet?

 

You also have another option for profiling. You can span a port off of your DHCP server into the second NIC on ClearPass to allow for DHCP profiling. You can create a span filter to only send DHCP/BootP packets.

Update on this, we ended up figuring out this was an issue with the way we do our ACLs for this environment and the profiling methods we are using. The users who have a more eleveted access level are getting profiled correctly because of the ability to open a browser and get to webpages successfully, the others who cant browse at all are not getting profiled correctly. The WLAN controllers are Cisco, and the WLAN profiles are setup to send HTTP profiling information to Clearpass. So, profiling is enabled via HTTP and RADIUS acct packets. DHCP profiling is not an option in our environment due to lack of SPAN capabilities and no room to enable DHCP helper on the L3 interface or the Cisco WLAN profiles (2 helper addresses is the limit). Our Aruba enviornment is more flexible and works a lot better with the Clearpass profiling engine.