Hi. We are a K-12 school district in NC that has had ClearPass recently setup by our Aruba vendor. A big reason we purchased ClearPass was to block student phones from our network. Rules and roles were created by our vendors engineer to accomplish this with DHCP fingerprinting. The device type is profiled (Smart Device; Apple iPhone, Samsung Android, etc) and rules are created to send these devices to a blocked phone role. A Deny_Device role is setup on the IAP virtual controller to deny all services to any iPhone or Android phone. In our testing lab we saw this successfully work and saw that phones from multiple vendors were in fact blocked. We began rolling this out to one of our middle schools this week and are finding that some iPhone and Android phones can connect, get a valid IP and get out to the internet and get a role that allows them on the network while other phones get the deny_device role, get an invalid IP and are blocked like they should be. Can anyone lend any assistance as to why some phones are blocked and some are not? Thank you.
@cappalli wrote:Please post some screenshots of your enforcement policy and also please showus an access tracker request for one of the devices that was allowed on.
@timcappalli I will post some screenshots of the the enforcement policy ASAP. For now, here are two screenshots. One is from a iPhone that was blocked and one was from an iPhone that was allowed on. Thanks!
The device being allowed on is profile as "iOS Device" not iPhone. Once we see your enforcement policy (and also post your role map), we can make a recommendation.
@cappalli wrote:The device being allowed on is profile as "iOS Device" not iPhone. Once we see your enforcement policy (and also post your role map), we can make a recommendation.
Attached are screenshots of our enforcement policy and role mappings. I've also included a screenshot of two different Samsung Android phones. One gets blocked and one gets through. You can see one gets the blocked_phone_role and the other gets the HCS-Teacher role and allowed on the network. Both have the same profile of SmartDevice / Android / Android. Thanks for any assistance.
Couple of comments.
1) You should do one combined role map for your 802.1X service that is a match any and then reference the TIPS roles in your enforcement policy. This role map would include identity portions from AD as well as your device tagging. You want to avoid doing this in your enforcement policy. Here's a quick example:
Your enforcement would then simply say:
Tips Role EQUALS DEVICE_SMARTPHONE
Connection: Client-Mac-Address NOT_BELONGS_TO_GROUP HCS-AllowedPhones
Deny Role enforcement profile
2) Since you're using device type as a critical decision maker, you need to enable profiling in the service and create a new enforcement rule for something that isn't profiled.
- In your service, click the Profile Endpoints check box, then go to the Profiler tab, select SmartDevice from the drop down and then click Save.
- On your controller create a new role called PROFILE. This role should only allow DHCP. Create a new enforcement profile referencing that role name using the Aruba-User-Role VSA. Now in your enforcement policy, create a new rule at the top that reads:
Authorization:[Endpoints Repository] Category NOT_EXISTS, <your-"PROFILE"-enforcement-profile>
3) Just curious, are all 3 of your DCs in the same domain? If so, why are you checking group membership for each DC? You should have just one AD auth source per domain.
I am working with Jeremy to resolve this issue. I think I follow what you are trying to do but I have some questions about how to go about it with what is already built.
1. There is already a role mapping policy in place that defines roles based on user groups in AD. How would I add the additional conditions for defining all the smartphones as DEVICE_SMARTPHONE? Can I just add the conditions to the existing policy?
2. Endpoint profiling is enabled in the service and user VLANs have added the CPPM server as an IP helper to assist with the profiling of the devices. However, I am at a loss as to why in one instance the same iPhone can be profiled as a SmartDevice\Apple\Apple iOS device yesterday and today it is profiled as SmartDevice\Apple\ Apple iPhone. This is what is causing the most havoc right now.
3. I followed suggestion #2 and changed the Endpoint Classification setting to SmartDevice, created the Profile role on the Instant VC and allowed only DHCP. I have added an Enforcement Profile called HCS_Profile-Device and edited the Enforcement Policy to include a top line condition that states Authorization:[Endpoints Repository] Category: NOT_EXISTS and then added the HCS_Profile_Device enforcment profile.
Thanks for your input on this.
It is confusing in that the conditions worked in a test environment but now that it is live we are seeing conflicting situations. In one instance two devices get profiled as SmartDevice\Android\Android and appear to be identical but one gets blocked and the other is allowed on. The same with iPhones where they both get SmartDevice\Apple\Apple iPhone and one gets blocked but the other is allowed. on.
Also a little bit of background on what the customer is trying to achieve;
1 - They want to allow whitelisted SmartDevices (teacher and staff mobile phones) but block any that are not whitelisted.
2 - They are a primarily an all Chromebook environment which appear to be profiled as SmartDevice\Linux\ChromeOS. However, they do have iPads and iPod Touch devices in some schools that need to be allowed.
3 - For their Windows and Mac domain joined machines they want to auth and derive user roles from AD group membership.
4 - They are using Instant APs in their middle schools and controllers at their high schools.
5 - They are currently on CPPM version 126.96.36.199015
Thanks again for the input and suggestions.
1) Yes, just add them into the policy. Be sure to chagne the rules evaluation to Any. Also, why are you checking groups to individual domain controllers instead of just the AD auth source?2) I don't have an answer for that but you can leverage the Aruba-Device-Type attribute on top of the ClearPass profile to get more granualar. Take a look at my screenshot above.In regards to the faculty/staff devices, why are you maintaining a MAC list instead of just using the user's identity? You should already know that they are faculty/staff based on AD information, so checking the device shouldn't matter. You can then condense your enforcement policy down to only a few rules: Rule 1: stays the same (profile check) Rule 2: [ TIPS Role MATCHES_ANY USER_TEACHER, USER_STAFF ] AND [ TIPS Role EQUALS DEVICE_SMARTDEVICE ] >> HCS-WIFI Delete rules 3-6 New rule 3: [ TIPS Role MATCHES_ALL USER_STUDENT, DEVICE_SMARTDEVICE ] >> Blocked_Phone_Role Rules 12 - 16 stay (Machine auth, user auth, etc)
Thanks for the response.
I had the conditions set for each role derived based on the authorization source (each DC). Is there a way to refer to an alias of all three servers like in the controller where you build a server group?
The reason for using the MAC whitelist (static hosts list) is because the customer wants to allow staff/faculty phones on per user basis. Not all teachers, staff will be allowed to use their phones on the wireless. All students are denied phone use but they know they are going to have make exceptions for staff/faculty because that is just the way it is.
I'll work with Jeremy to implement the changes and post back the results.
Thanks again for the guidance.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.