Ranger UI Authentication
Reference information on Ranger UI authentication, when configuring Ranger AD integration.
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
ranger_ug_ldap_bind_dn. These properties are
provided at runtime only with the value of another property by that
The configuration for it is on Ambari > Ranger > Configs > Advanced:
ranger.ldap.ad.base.dn determines the base of any search, so
users not on this OU tree path can not be authenticated.
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
ranger.ldap.ad.user.searchfilter even further to :
This does NOT work with the ACTIVE_DIRECTORY option.
The other LDAP related properties do allow for more fine tuning:
There is 1 catch though; the
evaluated first, so usually putting a value like:
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:
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.