Ranger UI Authentication
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.