Support Questions

Find answers, ask questions, and share your expertise

Ambari – AD LDS (LDAP) integration

avatar
Explorer
Hi,

I have setup Ambari integration with LDAP (AD LDS) and user & group sync working fine but I am not able to logging into ambari web using my AD LDS user and password. After further debugging, I have found that “Bind is success but User does not have read access on their own user object attributes from AD LDS”. After discussing with AD LDS admin team, they confirmed modifying the security on the AD LDS directory is not an option. Does ambari works if the logged in user not having read access on their own user object attributes? Can we customize ambari user web login (spring security) behaviour?

Ambari ldap configuration in ambari.properties
============================================== api.authenticate=true
authentication.ldap.baseDn=DC=jcs,DC=com
authentication.ldap.bindAnonymously=false authentication.ldap.dnAttribute=distinguishedName authentication.ldap.groupMembershipAttr=member; authentication.ldap.groupNamingAttr=cn authentication.ldap.groupObjectClass=group
authentication.ldap.managerDn=CN=<manager DN>,OU=ApplAccounts,OU=Applications,DC=jcs,DC=com
authentication.ldap.managerPassword=/etc/ambari-server/conf/ldap-password.dat
authentication.ldap.primaryUrl=adlds.jcs.com:636 authentication.ldap.referral=ignore
authentication.ldap.useSSL=true
authentication.ldap.userObjectClass=user authentication.ldap.usernameAttribute=cn bootstrap.dir=/var/run/ambari-server/bootstrap bootstrap.script=/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py
bootstrap.setup_agent.script=/usr/lib/python2.6/site-packages/ambari_server/setupAgent.py
client.security=ldap 

Error Log:

============

28 Oct 2015 12:16:51,900 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] AbstractContextSource:259 - Got Ldap context on server 'ldaps://adlds.jcs.com:636/dc=jcs,dc=com' 28 Oct 2015 12:16:51,904 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] SpringSecurityLdapTemplate:213 - Searching for entry under DN 'dc=jcs,dc=com', base = '', filter = '(cn={0})'

28 Oct 2015 12:16:51,905 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] SpringSecurityLdapTemplate:229 - Found DN: cn=cmmuriat,ou=JIPeople

28 Oct 2015 12:16:51,909 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] BindAuthenticator:108 - Attempting to bind as cn=cmmuriat,ou=JIPeople,dc=jcs,dc=com

28 Oct 2015 12:16:52,172 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] AbstractContextSource:259 - Got Ldap context on server 'ldaps://adlds.jcs.com:636/dc=jcs,dc=com'

28 Oct 2015 12:16:52,172 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] BindAuthenticator:116 - Retrieving attributes...

28 Oct 2015 12:16:52,180 DEBUG [qtp-client-22 - /api/v1/users/cmmuriat?fields=*,privileges/PrivilegeInfo/cluster_name,privileges/PrivilegeInfo/permission_name&_=1446052611633] AmbariLdapAuthenticationProvider:62 - Got exception during LDAP authentification attempt org.springframework.security.authentication.InternalAuthenticationServiceException: [LDAP: error code 32 - 0000208D: NameErr: DSID-031522C9, problem 2001 (NO_OBJECT), data 0, best match of: 'DC=jcs,DC=com' ^@]; nested exception is javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-031522C9, problem 2001 (NO_OBJECT), data 0, best match of: 'DC=jcs,DC=com' ^@]; remaining name 'cn=cmmuriat,ou=JIPeople'

1 ACCEPTED SOLUTION

avatar
Explorer

@Paul Codding

Thanks Paul. Yes. AD LDS team confirmed that modifying the configuration on the AD LDS directory is not an option. They are recommending "modify the code (do a BIND as the manager DN account to read attributes of the user right after the successful bind as the user).". Do Ambari actually required any user attributes? if not, I can try to rebuild spring security jar by commenting "Attributes attrs = ctx.getAttributes(userDn, getUserAttributes());" in BindAuthenticator.java.

Thanks Again.

View solution in original post

8 REPLIES 8

avatar
Master Mentor

@rtummuri@hortonworks.com Please remove the customer reference in the output

avatar
Master Mentor

@rtummuri@hortonworks.com

Any chance of using different DN who has atleast read access?

authentication.ldap.managerDn=CN=<manager DN>,OU=ApplAccounts,OU=Applications,DC=xxx,DC=com

avatar
Explorer

Hi Neeraj,

Manager DN has read access, that's how I can sync users and groups. But actual login user (for example: cmmuriat ) does't have read permissions on own user object attributes. Find below code, it is trying to get user attributes using logged-in bind DN not by using manager DN.

BindAuthenticator.java

private DirContextOperations bindWithDn(String userDnStr, String username, String password) { BaseLdapPathContextSource ctxSource = (BaseLdapPathContextSource) getContextSource(); DistinguishedName userDn = new DistinguishedName(userDnStr); DistinguishedName fullDn = new DistinguishedName(userDn); fullDn.prepend(ctxSource.getBaseLdapPath()); logger.debug("Attempting to bind as " + fullDn); DirContext ctx = null; try { ctx = getContextSource().getContext(fullDn.toString(), password); // Check for password policy control PasswordPolicyControl ppolicy = PasswordPolicyControlExtractor .extractControl(ctx); logger.debug("Retrieving attributes..."); Attributes attrs = ctx.getAttributes(userDn, getUserAttributes()); DirContextAdapter result = new DirContextAdapter(attrs, userDn, ctxSource.getBaseLdapPath()); if (ppolicy != null) { result.setAttributeValue(ppolicy.getID(), ppolicy); return result; catch (NamingException e) { // This will be thrown if an invalid user name is used and the method may // be called multiple times to try different names, so we trap the exception // unless a subclass wishes to implement more specialized behaviour. if ((e instanceof org.springframework.ldap.AuthenticationException) || (e instanceof org.springframework.ldap.OperationNotSupportedException)) { handleBindException(userDnStr, username, e); else { throw e; catch (javax.naming.NamingException e) { throw LdapUtils.convertLdapException(e); finally { LdapUtils.closeContext(ctx); return null;

avatar
Explorer

http://stackoverflow.com/questions/2831630/why-does-spring-securitys-bindauthenticator-require-read-...

this is the same issue I am having. I can customize if it is out side of Ambari. But not sure customizing in ambari.

avatar
Master Mentor

@Paul Codding ideas? Thanks!

avatar

So this is for AD Lightweight Directory Services and the customer cannot allow users read access to their own attributes? If this is the case, and they won't budge on making the permissions change, this would require a product change. That takes time...

avatar
Explorer

@Paul Codding

Thanks Paul. Yes. AD LDS team confirmed that modifying the configuration on the AD LDS directory is not an option. They are recommending "modify the code (do a BIND as the manager DN account to read attributes of the user right after the successful bind as the user).". Do Ambari actually required any user attributes? if not, I can try to rebuild spring security jar by commenting "Attributes attrs = ctx.getAttributes(userDn, getUserAttributes());" in BindAuthenticator.java.

Thanks Again.

avatar

@oszabo@hortonworks.com is in the process of troubleshooting some other LDAP related items at the moment and may be able to comment, but I will get an internal JIRA filed for this and we'll have to get it slated.