Community Articles
Find and share helpful community-sourced technical articles
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.
Labels (1)

slapd-conf.tar.gzEnvironment:

Hortonworks Sandbox “HDP_2.3.2_virtualbox"

Ranger Version: 0.5.0.2.3

LDAP Version: openldap-2.4.40-7.el6_7.x86_64

LDAP setup url : LDAP setup tutorial 
[Note: The ldap setup here does not have ssl implemented. Pls find working “slapd.conf”attached]

Steps:

1.Configure openldap server on sandbox as mentioned in the Ldap setup url above.

2.Login to Ambari console using “admin” user.

3.Click on “Ranger” service -> “Configs”

4.Go to “LDAP Settings” and set the below properties –

ranger.ldap.user.searchfilter=(uid={0})
ranger.ldap.user.dnpattern=cn=Manager,dc=hortonworks,dc=com
ranger.ldap.url=ldap://127.0.0.1:389
ranger.ldap.referral=ignore 
ranger.ldap.group.roleattribute=uid 
ranger.ldap.bind.password=*****
ranger.ldap.bind.dn=cn=Manager,dc=hortonworks,dc=com
ranger.ldap.base.dn=dc=hortonworks,dc=com

Note: ldap.bind.password=<Admin password of openldap>

5.Go to “Advanced ranger-admin-site” and set below properties -

ranger.ldap.group.searchfilter=(member=uid={0},ou=Users,dc=hortonworks,dc=com)
ranger.ldap.group.searchbase=dc=hortonworks,dc=com

6. Go to “Advanced ranger-ugsync-site” and set below properties -

ranger.usersync.ldap.username.caseconversion= none
ranger.usersync.group.memberattributename=member
ranger.usersync.group.nameattribute=cn
ranger.usersync.group.objectclass= groupofnames
ranger.usersync.group.searchbase=dc=hortonworks,dc=com
ranger.usersync.group.searchenabled= false
ranger.usersync.group.searchscope=sub
ranger.usersync.group.usermapsyncenabled=false
ranger.usersync.ldap.user.searchscope=sub
ranger.usersync.ldap.user.searchbase=ou=Users,dc=hortonworks,dc=com
ranger.usersync.ldap.user.objectclass=person
ranger.usersync.ldap.user.nameattribute=uid
ranger.usersync.ldap.url=ldap://127.0.0.1:389
ranger.usersync.ldap.searchBase=dc=hortonworks,dc=com
ranger.usersync.ldap.referral=ignore
ranger.usersync.ldap.ldapbindpassword=*****
ranger.usersync.ldap.groupname.caseconversion=none
ranger.usersync.ldap.binddn=cn=Manager,dc=hortonworks,dc=com
ranger.usersync.ldap.bindalias= ranger.usersync.ldap.bindalias
ranger.usersync.source.impl.class= org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder
ranger.usersync.sink.impl.class= org.apache.ranger.unixusersync.process.PolicyMgrUserGroupBuilder

7.Restart all affected components for “Ranger” service.

8.Browse “Ranger UI” on http://<ranger-host>:6080

9.Login to Ranger UI using “admin”

10.Make sure you have following entry in slap.conf

access to *
	by anonymous read
	by * none

11.Click on “Settings” -> “Users/Groups” and make sure you are able to see ldap users in “Users” section

12. Once you are able to view the users in Ranger UI, then logout from "admin" user.

13. Now try login in Ranger UI using ldap user.

8,437 Views
Comments
New Contributor

I follow all steps that whatever given in the link, but even so I can't view LDAP users on the Ranger why? I attach below Ldap conf on Ambari ldap-conf.tar.gz.

New Contributor

Very nice guide Sagar thank you!

Contributor

@Sagar Shimpi..i followed this and couple of more posts and able to sync up users but i am not able to sync groups..sample ldap configuration is attached , as in your case group search base is like member= but what should be mine memberUid as i tried with that but groups are not visible in Ranger UI.

12630-ldap.jpg

Expert Contributor

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.

Don't have an account?
Coming from Hortonworks? Activate your account here
Version history
Revision #:
1 of 1
Last update:
‎02-12-2016 07:01 PM
Updated by:
 
Contributors
Top Kudoed Authors