Security

Hello,

 

I am attempting to configure ClearPass to authenticate users using AD credentials or certificates. If a user provides AD credentials or a certificate that's accepted, then I would like that user to be placed on the Network Access VLAN. If a user fails to authenticate, then I would like to put them on a Guest VLAN. The RADIUS connection between my aruba wireless controller and ClearPass appears to be working properly because AD users are permitted to use the wireless network. I used the Aruba 802.1X Wireless setup wizard under "Start Here" in ClearPass, but that just ends up authenticating all AD users. Is there a way to distinguish between AD users? I currently have a rule in the enforcement policy that states only an AD user that CONTAINS the string "exampleUser" should get the enforcement profile that permits them to use the network. Otherwise, I have a default enforcement profile called Guest VLAN, which is supposed to put them on VLAN 20. However, this setup doesn't appear to work the way that I intended. Everyone in the domain is just automatically admitted to use the network. Any idea what I am doing wrong?

You would use role mapping to map AD attributes to ClearPass (TIPS) roles. THen you can reference those roles in your enforcement policy to take action.

 

For example:

ROLE MAP

AD:Groups EQUAL IT-Staff        TIPS role USER_IT

 

ENFORCEMENT

TIPS       Role     EQUALS     USER_IT               ROLE_IT

I just want to reiterate what you said to make sure I understand. You're saying that there isn't a way to authenticate AD users differently. If they exist in AD then they will be permitted to use the network.

Please see the edited post above. You edited your original post which added more detail.

Under roles I have a role mapping policy that has a condition that says if the AD name CONTAINS "exampleUser" then assign them the role of [Employee] and the default role is set to [Guest]. Under Enforcement I have two conditions. If Tips:Role equals [Employee] then the user is assigned the [Allow Access Profile]. However, if the Tips:Role equals [Guest] then they get the Guest VLAN profile, which is supposed to assign them to a dead VLAN 20. Everyone appears to just get the default role of [Guest] and the enforcement profile Guest VLAN. This happens even for "exampleUser". Do you know why this would be the case?

It seems like it is hitting your default enforcement policy, which might be resulting in an allow all. When you look at the access tracker, it will tell you all of the computed attributes that you can review to see if you matched them.

I found out the issue. It appears that if you're using the memberOf AD attribute on a user that is in two or more AD groups ClearPass only sees the highest priviledge AD group for that user. In other words, if you have exampleUser in Domain Users and Enterprise Admins and your Role Mapping Policy only deals with Domain Users then exampleUser wont get properly mapped until a Role Mapping Poliy deals with Enterprise Admins.

Try using groups instead of memberof


Thanks, 
Tim

Same result believe it or not.

Add a new "Nested Group" attribute to your AD authentication source and then use that for your role mapping.

 

 

(member:1.2.840.113556.1.4.1941:=%{UserDN})

 

---

@cmwillis wrote:

I found out the issue. It appears that if you're using the memberOf AD attribute on a user that is in two or more AD groups ClearPass only sees the highest priviledge AD group for that user. In other words, if you have exampleUser in Domain Users and Enterprise Admins and your Role Mapping Policy only deals with Domain Users then exampleUser wont get properly mapped until a Role Mapping Poliy deals with Enterprise Admins.

---

With regards to this comment.    The "primary group" membership of an AD user (as listed on the Member Of tab of an account) does not show up in the memberOf attribute.   This usually means that Domain Users does not show up in the memberOf attribute.    This primary group shows up under the primaryGroupID attribute if you need to use "Domain Users".

 

Your option is to either use a non primary group for role mappings or use the primaryGroupID (EQUALS 513) instead.

 

 

Found this article here on the Community that explains this.

 

http://community.arubanetworks.com/t5/tkb/articleprintpage/tkb-id/AAANACGuestAccessBYOD/article-id/79