02-03-2014 06:42 AM
My Guest SSID currently serves two purposes. Firstly it allows guest users to access the captive portal on my controllers to login and get guest access. Secondly it serves as an open network for AppleTV devices in our organization to connect to and MAC authenticate and gain access to the network.
I have created two services in ClearPass, one for the layer 2 MAC auth and the other for the Layer 3 auths on the captive portal. The layer 3 service works perfectly but the layer 2 MAC auth service is a bit of a concern. While it works, the great majority of authentications are in fact failures. Any device that is not registered as an Apple TV using ClearPass Guest has a drop access policy applied. The Wireless controller assigns a guest-logon role and the client is directed to the portal's normal.
The problem I have with this is that it fills the Access Tracker with failed layer 2 auths which I would rather not see. All that red ink in the logs is difficult to explain to colleagues who may not understand what is actually happening.
The only option I can see is to apply an allow all policy to every layer two authentication. Apple TV will get the correct Apple TV vsa and all other layer 2 auths will be accepted and sent back to the controller with a guest-logon vsa. The problem with this is that every device that hits this open SSID is now counted against my licensing.
Ideally what I would like to be able to do is have the allow all access policy assign the guest-logon role but not count against the licensing until the client has completed a layer 3 authentication in the captive portal.
Anyone have any thoughts on this? Is there a better way?
Thanks in advance.
Solved! Go to Solution.
02-03-2014 07:08 AM
Interesting, I am on the same boat. My explaination to my colleagues is I can not “ACCEPT” any guest users just show up at my door, so they are all “REJECT” to the Captive Portal.
Hopefuly the next update of CPPM, another login category like “IGNORE” will be added
02-03-2014 08:48 AM
As I understand things that is the difference between a RADIUS Reject and a RADIUS Drop. A drop simply means that RADIUS Server is supposed to just ignore the request. When These dropped requests show up in access tracker as a REJECT it is misleading for sure.
What I am doing works but it sure makes the access tracker messy!
02-13-2014 09:30 PM
One note on this is you can use a data filter to not show those fails. Then you can select that filter in your access tracker.
For example: I'm using TACACS on my controller to CPPM. My controller is on the web and I would get a lot of dictionary atacks so I created a fileter to surpress any Failed TACACS auths.
--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.