Security

Hi,

To give a bit of context, a clearpass has been up and running smoothly for a while (1Yr+). It uses AD as a source for authentication/authorization. 

Now, the privilege of the bind account declared in Clearpass has been reduced from Domain Admin, to just Domain User, which instantly broke the "auth".

Actually when looking at the logs it broke the Authorization process, I can see that Clearpass can not read the "memberOf" attribute anymore.

I'm confused by this behavior, The option "Use for Authorization" is check in the source settings.

As I understood the bind account is a "one-time use" to create the Clearpass computer object in the AD.

This object is then used to handle the authentication request, and I assumed authorization as well.

But it doesn't seem to be the case, as simply removing the Domain Admin rights on the bind account broke Authorization.

Adding this right back resolve this, meaning the object doesn't seem to be used for Authorization, or perhpas it's a fallback for missing rights.

As a workaround to remove Domain Admin rights, a delegation was setup to read all user info on the OU, which is better than before.

But it doesn't clarify the expected behavior, does anyone have insights on this ? The documentation isn't quite explicit for "Use for Authorization" :

"When Use for Authorization is enabled, ClearPass can use this authentication source to fetch role-mapping attributes. This option is enabled by default."

I mean this doesn't give me a clue on whether the computer account or bind account will be used.

Thanks,

Adrien.

Let's start with the bind account. For legacy authentication with PEAP-MSCHAPv2 (deprecated!) you would need to join the ClearPass server as member to to domain. This is done with the Join button in the Server manager, and this requires an administrator account with enough privileges to join computers to the domain. Once that is done, the account used during the join is no longer used, it's also not stored. The join is only used for the MSCHAPv2 authentication, which is why you don't need to join the domain if you use EAP-TLS.

The AD/LDAP Authentication source has a 'bind user' that is used to query authorization attributes from the AD domain. That account should have read permissions to all user and group objects, at least the attributes that are used during the authentication. With the default settings, any normal user account has these rights, unless your AD admins restricted access. A read-only service account with full read rights to users & group objects sounds like a perfect solution for the purpose.

Then the 'Use for authorization' tickbox. Documentation states: "Enable this check box to instruct Policy Manager to fetch role-mapping attributes (or authorization attributes) from this authentication source. If a user or device successfully authenticates against this authentication source, then Policy Manager also fetches role-mapping attributes from the same source if the Use for Authorization field is enabled. This check box is checked (enabled) by default.". And what this means is that when this authentication source is used in the authentication tab, and when that source is used for the authentication, the source will automatically be used for authorization as well. You can see this that the Authentication source is already pre-filled in the service's Authorization tab. I typically enter the authentication source also manually as authorization service, in which case it does not matter if the tickbox 'Use for Authorization' is enabled or not.

Both in the situation of PEAP-MSCHAPv2 and EAP-TLS (or TEAP), ClearPass does not know the user's password, so it can't bind to the LDAP on-behalf-of the user (or computer) authenticating, and the Bind account is used to fetch the authorization attributes. For other authentication methods, like captive portal, or PAP, ClearPass could use the User's password to bind to AD (option: Allow bind using user password in the Authentication Source).

Hope this made things a bit more clear?

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------