Created 11-03-2015 01:05 AM
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'
Created 11-03-2015 06:53 PM
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.
Created 11-03-2015 01:08 AM
@rtummuri@hortonworks.com Please remove the customer reference in the output
Created 11-03-2015 01:20 AM
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
Created 11-03-2015 02:10 AM
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;
Created 11-03-2015 01:37 PM
this is the same issue I am having. I can customize if it is out side of Ambari. But not sure customizing in ambari.
Created 11-03-2015 02:28 PM
@Paul Codding ideas? Thanks!
Created 11-03-2015 05:12 PM
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...
Created 11-03-2015 06:53 PM
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.
Created 11-03-2015 10:42 PM
@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.