This is an extra AD level filter option on top of Kerberos authentication that maps to:

For working with AD there are 2 options for defining who can access the Ranger UI; LDAP or ACTIVE_DIRECTORY. There is not much difference between them, just another set of properties.

Some of the configuration is in fact shared with the configuration of Ranger usersync as can be seen by the property with formats like ranger_ug_ldap_bind_dn. These properties are provided at runtime only with the value of another property by that name.

ACTIVE_DIRECTORY

The configuration for it is on Ambari > Ranger > Configs > Advanced:

The ranger.ldap.ad.base.dn determines the base of any search, so users not on this OU tree path can not be authenticated.

The ranger.ldap.ad.user.searchfilter is a dynamic filter that maps the user name in the Ranger Web UI login screen to sAMAccountName. For example, the AD sAMAccountName property has example values like k.reshi and d.alora so make sure to enter a matching value for ‘Username’ in the logon dialogue.

With ACTIVE_DIRECTORY it is not possible to limit the scope of users that can access Ranger UI any further by refining the ranger.ldap.ad.user.searchfilter even further to :

(&(memberOf=CN=Hdp_admins,OU=Company,OU=User Accounts,OU=CorpUsers,DC=field,DC=hortonworks,DC=com)(sAMAccountName={0}))

This does NOT work with the ACTIVE_DIRECTORY option.

LDAP

The other LDAP related properties do allow for more fine tuning:

There is 1 catch though; the ranger.ldap.user.dnpattern is evaluated first, so usually putting a value like:

CN={0},OU=London,OU=Company,OU=User Accounts,OU=CorpUsers,DC=field,DC=hortonworks,DC=com

Would work, but has 2 by-effects; first users would have to log on with their ‘long username’ (like ‘Kvothe Reshi / Denna Alora') which would also mean that policies would have to be updated using that long name in stead of the k.reshi short name variant.

Second traversing AD by DN patterns does not allow for applying group filters at all. In the syntax above only users directly in OU=London would be able to log on.

That adverse behavior can be worked around by intentionally putting a DN pattern (DC=intentionally,DC=wrong) in the ranger.ldap.user.dnpattern property AND a valid filter in User Search Filter:

(&(objectclass=user)(memberOf=CN=Hdp_admins,OU=Company,OU=User Accounts,OU=CorpUsers,DC=field,DC=hortonworks,DC=com)(sAMAccountName={0}))

This works because the filter is only applied after the DN pattern query on AD does not return anything. If it does, then the User Search Filter is not applied.

Ranger has a very simple approach to the internal user list that is kept in a relational schema. That list contains all users that were synced with AD ever, and all those users can potentially log on to Ranger UI. But only admin users can really do anything policy related things on the Ranger UI (see next section).

Beware that all this is still only about authentication to Ranger. Someone from the ‘Hdp_admins’ group would still not have a Ranger admin role.