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:
![](../images/security-ranger-console-login.png)
For AD there are two options for defining who can access the Ranger UI: LDAP or ACTIVE_DIRECTORY. There is not a huge amount of difference between them, but they are separate sets of properties.
![](../images/security-ranger-authentication-ad-properties.png)
The ranger.ldap.ad.base.dn
property determines the base of
any search, so users not on this OU tree path can not be
authenticated.
The ranger.ldap.ad.user.searchfilter
poperty 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 the Ranger UI any further by
refining the value of the ranger.ldap.ad.user.searchfilter
property 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 LDAP properties allow for more fine tuning.
![](../images/security-ranger-authentication-ldap-properties.png)
There is one catch: the ranger.ldap.user.dnpattern
is evaluated
first. Consider the following example value:
CN={0},OU=London,OU=Company,OU=User
Accounts,OU=CorpUsers,DC=field,DC=hortonworks,DC=com
This would work, but has two side effects:
- 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 instead of the k.reshi short name variant.
- 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.
This adverse behavior can be avoided 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, 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. This list contains all users that were synced with AD ever, and all those users can potentially log in to the Ranger UI. But only Admin users can really do any policy-related things in the Ranger UI (see next section).
Be aware that all of this is only about authentication to Ranger. Someone from the ‘Hdp_admins’ group would still not have a Ranger admin role.