Security

You need to make sure you modify your policy (Configuration » Enforcement » Policies » Edit - [Admin Network Login Policy]) and add your AD group settings in to the corresponding privilege level.

 

Just make it a copy of the original policy and modify the copy...

I am having exactly the same problem with the mismatched privilege levels.

 

However, I am not sure how to solve this.. I have copied the original [Admin Network Login Policy] but how do I set the corresponding privilege level within the policy?

That is configured in the Enforcement Profile.  Create a new TACACS enforcement profile and reference it in the enforcement policy.

Thanks for the post guys this was helpful at getting this issue resolved. I did things a bit differently and instad of putting my Authorization in the Enforcement I used a Role for Authorization and associate a TACACS role that was created with elevated  permissions. In the enforcement section I just used the TIPS to associate the role that was determined and it applys the Super Admin TACACS profile. 

 

Once completed everything worked as necessary, and I just cloned the default service and appened my Roles / Enforcement policies to the cloned profile so everything was retained. 

I read through the previous responses and found another cause.   In my case, I had everything right, except in the Role Mapping > Mapping Rules, I had an operator of EQUALS rather than CONTAINS.   I fail to understand why EQUALS doesn't work, as the AD group name I specified is exactly as I wrote it: Network Admins.  I even tried quotes around the group name.

 

So my whole Mapping Rule looks like this:

(Authorization:ITLAB-ROOT:memberOf CONTAINS Network Admins) [TACACS Super Admin]     

(where ITLAB-ROOT is my AD source).

 

Thanks!

You’d need to use the Groups attribute instead of memberOf to use EQUALS.

Thanks, Tim.  Tried Group and it works.  I still don't understand why... Maybe that requires the LDAP string "CN=..."? Guess I need to learn the format requirements of each type.  

 

Also, is there somewhere one can review the actual results of role mappings after an authentication event?  It's disappointing to me that in the tracker logs of a given authentication, there's no mention of my AD group, even when successful.

Yes, it’s based on how the data is parsed.

You can see the authorization data under the Input tab.

Is there any restriction on the characters that can make up a username ? I've got things set up here so that if a userid is a member of an AD group I assign a particular role and then act upon thgat role in the Enforcement policy.

 

Works just fine for usernames made up of alphanumeric charcters.

 

We have special "dollar" accounts here  ( normal username terminated by a $ with admin rights) and try as I might even though this format of username is in an AD group clearpass 6.8 comes back saying that the account doesn't exist in an AD group

Account details attached 

Hi alexsuoy,

 

Its probably not the right thread, but I didn't have any issues with having a $ in the end of the username.

 

I could also only find permitted characters for user/pass when binding clearpass to AD. I was not able to find anything obvious that involved LDAP authorizaiton with AD. 

 

I was able to perform a manual ldap query in the AD server, this worked as expected. I could also see the memberOf info. 

 

 

I have also included TACACS Policy Manager authorization info for the same user account. 

 

 

You may want to check the LDAP servers to ensure they have the correct data and are syncing. Not sure if you are defining them as FQDN / IP / or domain in the address section for the LDAP server. 

 

I would also recommend try a manual query.

Auth Server => Attributes => "Select" Authentication => "Select" Attributes "tab" => Enter Username.  

 

Thanks for the above. the priv level missmatch seems to have morph'd into a being unable to assign a user role based upon checking for username membership of an AD group . Works for lot of other groups ... works on my dev server .... doesnt work on my prodn one .... Must be something thats staring me in the face  but cxanl;t see it at the moment :-(

 

A

Your welcome.

 

I did not have theprivledge level mismatch issue on 6.8.0 with custom admin rights. In the past I had only seen this when you create custom admin privledges, in combination to AD users. 

 

If you had used the default admin privledges and AD users. I never seemed to obtain this error with previous releases. 

Interestingly, when I now (6.10) try Group EQUALS (even as _IGNORE_CASE) for an AD UserDN it doesn't work.  CONTAINS is not adequate, because there exist variations of the UserDN which are too similar and allow access by some others ("Gary" should allow access, but "Gary2" should not).

------------------------------
Gary Hahn
------------------------------

Original Message:
Sent: Sep 26, 2017 11:30 AM
From: Tim Cappalli
Subject: TACACS on Clear Pass -Authentication privilege level mismatch

Yes, it's based on how the data is parsed.

You can see the authorization data under the Input tab.

Thanks

 

That helped