I found problems trying to validate the information in this article, and after doing my own research I have to say that it's inaccurate and in some aspects simply wrong. First of all it must be clear that the "ranger.ldap.*" set of parameters which should be configured under Ambari under "Ranger >> Config >> Advanced >> Ldap Settings" and "Advanced ranger-admin-site" are related only to Ranger Admin UI authentication and this has nothing to do with Ranger Usersync (different properties, different code, different daemon) which must be configured completely in the "Ranger >> Config >> Ranger User Info" section. This article mix the two set of LDAP related configurations for two different components in Ranger and this is confusing and not correct. All that I state here may be verified by looking at the source code of the following classes from the "ranger" and "spring-ldap" projects in GitHub: apache.ranger.security.handler.RangerAuthenticationProvider
org.springframework.security.ldap.authentication.BindAuthenticator
org.springframework.security.ldap.authentication.LdapAuthenticationProvider/AbstractLdapAuthenticationProvider Talking about "Ranger Admin LDAP authentication" the only two parameters you will need are the following: ranger.ldap.url = http://ldap-host:389
ranger.ldap.user.dnpattern = uid={0},ou=users,dc=example,dc=com<br> This is because the RangerAuthenticationProvider class first uses the method "getLdapAuthentication()" which in place will use the Spring's BindAuthenticator class with default parameters except from the previous properties. This will try to do a BIND as the DN obtained from "ldapDNPattern" replacing "{0}" with the username, and if this succeeds, the authentication will be granted to the user and nothing else is used!! The only case were the remaining "ranger.ldap.*" parameters are used is when "getLdapAuthentication()" fails, for example by setting the wrong value for "ldap.user.dnpattern" as in the example above, where the LDAP manager's DN will be used to do the Bind with the username's provided password. When the call to "getLdapAuthentication()" fails, Ranger will next try a call to the more specialized method "getLdapBindAuthentication()" and is this method that will use all the other "ranger.ldap.{bind|user|group}.*" properties! This time BindAuthenticator will be configured to bind with the provided "ranger.ldap.bind.dn/password" and will search for the user entry and their groups with the other properties, etc ... But even in this case there is another IMPORTANT error in the article above:
the pattern in "ranger.ldap.group.searchfilter" is wrong, because this is handled by the class DefaultLdapAuthoritiesPopulator and this will replace the '{0}' with the DistinguishedName (DN) of the user (NOT the username) and instead ist the '{1}' that will be replaced with the username. So, if you want to use the configuration above, you should replace {0} with {1} or even better just use "member={0}' as your group searchfilter. Regarding the "authorization" phase, in both the previous methods, if the authorization succeeds, then the group/role authorities for the user will be searched from LDAP (using Spring's DefaultLdapAuthoritiesPopulator class), but ONLY if both
rangerLdapGroupSearchBase AND rangerLdapGroupSearchFilter are defined
and not empty. But even in this case (I have still not tested this, but looking at the code It seems clear) I'm almost sure that the list of "grantedAuths"
obtained from LDAP are never used by Ranger because at the
end of both "getLDAP*Authentication()" methods the grantedAuths list is overwritten using the chain of calls to the following methods: authentication = getAuthenticationWithGrantedAuthority(authentication) >> List<GrantedAuthority> grantedAuths = getAuthorities(authentition.getName()); // pass username only >>>> roleList = (org.apache.ranger.biz.UserMgr)userMgr.getRolesByLoginId(username); //overwrite from Ranger DB I don't know if this is the desired behavior or it's a bug in the current RangerAuthenticationProvider that will be changed in the future (otherwise is not clear why to use the LdapAuthoritiesPopulator upstream), but it's the way it seems to be done right now. In conclusion, for Ranger Admin authentication, IF you just provides the right value for the "ranger.ldap.url" and "ranger.ldap.user.dnpattern" property, none
of the remaining "ranger.ldap.group.*" parameters will be used and the user roles
will be managed by Ranger from the "Admin UI -> Users" interface.
... View more
