I have a new OpenLDAP server. I am also using it as a Ldap Client.
I have added a user but cannot authenticate.
I have spent a lot of time researching this issue. All the suggestions are very different - ACL issues, slapd pointing the incorrect config files,
Ldap.conf file is incorrect, nsswitch is incorrect, incorrect password.
Is there a straight forward way to troubleshoot this issue. What are the configs files that are involved with this failure?
Your help is greatly appreciated.
This user works
[root@ldapservrer]# ldapwhoami -x -D cn=ldapadmin,dc=group1,dc=ldap -W
Enter LDAP Password:
dn:cn=ldapadmin,dc=group1,dc=ldap
This user fails
[root@ldapserver]# ldapwhoami -x -D cn=lou,dc=group1,dc=ldap -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
5612e45a conn=1051 fd=12 ACCEPT from IP=192.168.0.101:59308 (IP=192.168.0.a0a:389)
5612e45a conn=1051 op=0 BIND dn="cn=lou,dc=group1,dc=ldap" method=128
5612e45a conn=1051 op=0 RESULT tag=97 err=49 text=
5612e45a conn=1051 op=1 UNBIND
5612e45a conn=1051 fd=12 closed
Oct 5 16:03:32 ldapserver sshd[1432]: Received disconnect from 9.9.9.9: 11: disconnected by user
Oct 5 16:03:36 ldapserver sshd[1528]: Invalid user lou from 9.9.9.9
Oct 5 16:03:36 ldapserver sshd[1529]: input_userauth_request: invalid user lou
Oct 5 16:03:53 ldapserver sshd[1528]: Failed password for invalid user lou from 9.9.9.9 port 33968 ssh2
_______________________________
[root@ldapserver man1]# su - lou
su: user lou does not exis
5612ebc3 conn=1053 fd=12 ACCEPT from IP=192.168.0.101:59310 (IP=192.168.0.101:389)
5612ebc3 conn=1053 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
5612ebc3 conn=1053 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
5612ebc3 conn=1053 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
5612ebc3 conn=1053 op=1 SRCH base="dc=group1,dc=ldap" scope=2 deref=0 filter="(&(uid=lou)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNum ber=0))))"
5612ebc3 conn=1053 op=1 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey
5612ebc3 conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=
5612ebc3 conn=1053 op=2 UNBIND
5612ebc3 conn=1053 fd=12 closed
__________________________
ssh lou@192.168.101
5612ed15 conn=1107 fd=12 ACCEPT from IP=192.168.0.101:59364 (IP=192.168.0.101:389)
5612ed15 conn=1107 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
5612ed15 conn=1107 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
5612ed15 conn=1107 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
5612ed15 conn=1107 op=1 SRCH base="dc=group1,dc=ldap" scope=2 deref=0 filter="(&(uid=lou)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNum ber=0))))"
5612ed15 conn=1107 op=1 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey
5612ed15 conn=1107 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=
5612ed15 conn=1107 op=2 UNBIND
5612ed15 conn=1107 fd=12 closed
[root@ldapserver ]# ldapsearch -H ldap://ldapserver.group1.ldap -d 256 -D cn=ldapadmin,dc=group1,dc=ldap -W -b ou=Users,dc=group1,dc=ldap
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=group1,dc=ldap> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# Users, group1.ldap
dn: ou=Users,dc=group1,dc=ldap
ou: Users
objectClass: organizationalUnit
# lou, Users, group.ldap
dn: uid=lou,ou=Users,dc=group1,dc=ldap
uid: lou
mail: louxxxxxxxxxxx
sn: xxxx
pwdAttribute: xxxxxxx
telephoneNumber: xxxxxxxxxx
roomNumber: xxxx
uidNumber: xxxx
gidNumber: xxxxx
employeeNumber: xxxxx
cn: Louis xxxxx
loginShell: /bin/bash
gecos: Lou xxxx
homeDirectory: /home/xxxx
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: pwdPolicy
objectClass: shadowAccount
userPassword:: xxxxxxx
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
On Mon, Oct 05, 2015 at 09:56:25PM +0000, Varadi, Louis - 0442 - MITLL wrote:
I have added a user but cannot authenticate.
This user fails
[root@ldapserver]# ldapwhoami -x -D cn=lou,dc=group1,dc=ldap -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
No surprise there, as your later search shows the user has a different DN:
# lou, Users, group.ldap dn: uid=lou,ou=Users,dc=group1,dc=ldap uid: lou mail: louxxxxxxxxxxx sn: xxxx pwdAttribute: xxxxxxx telephoneNumber: xxxxxxxxxx roomNumber: xxxx uidNumber: xxxx gidNumber: xxxxx employeeNumber: xxxxx cn: Louis xxxxx loginShell: /bin/bash gecos: Lou xxxx homeDirectory: /home/xxxx objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: pwdPolicy objectClass: shadowAccount userPassword:: xxxxxxx
[root@ldapserver man1]# su - lou
su: user lou does not exis
5612ebc3 conn=1053 fd=12 ACCEPT from IP=192.168.0.101:59310 (IP= 192.168.0.101:389)
5612ebc3 conn=1053 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
5612ebc3 conn=1053 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
This session is anonymous (no BIND operation).
5612ebc3 conn=1053 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
5612ebc3 conn=1053 op=1 SRCH base="dc=group1,dc=ldap" scope=2 deref=0 filter=" (&(uid=lou)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))"
5612ebc3 conn=1053 op=1 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey
5612ebc3 conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=
err=50
If you look that up you find:
insufficientAccessRights (50)
Indicates that the client does not have sufficient access rights to perform the operation.
So the anon user does not have the right to do a search from the base "dc=group1,dc=ldap" (this says nothing about the right to read the uid=lou entry).
You have an ACL problem. I suggest removing all ACLs and starting with this:
access to attrs="userPassword" by self =w by * auth
access to * by * read
Once you have the basic service working you can start thinking about ACLs. You may then want to define an account for your Linux client machines to use when accessing LDAP so that you don't have to give anon access to your data.
Andrew
Thank you Andrew for you quick reply.
Last week I removed the ACL for olcAccess, which did not help.
I will follow up on your suggestions. Thank you - Lou
-----Original Message----- From: Andrew Findlay [mailto:andrew.findlay@skills-1st.co.uk] Sent: Tuesday, October 06, 2015 4:17 AM To: Varadi, Louis - 0442 - MITLL Cc: openldap-technical@openldap.org Subject: Re: New User unable to authenticate on new client
On Mon, Oct 05, 2015 at 09:56:25PM +0000, Varadi, Louis - 0442 - MITLL wrote:
I have added a user but cannot authenticate.
This user fails
[root@ldapserver]# ldapwhoami -x -D cn=lou,dc=group1,dc=ldap -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
No surprise there, as your later search shows the user has a different DN:
# lou, Users, group.ldap dn: uid=lou,ou=Users,dc=group1,dc=ldap uid: lou mail: louxxxxxxxxxxx sn: xxxx pwdAttribute: xxxxxxx telephoneNumber: xxxxxxxxxx roomNumber: xxxx uidNumber: xxxx gidNumber: xxxxx employeeNumber: xxxxx cn: Louis xxxxx loginShell: /bin/bash gecos: Lou xxxx homeDirectory: /home/xxxx objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: pwdPolicy objectClass: shadowAccount userPassword:: xxxxxxx
[root@ldapserver man1]# su - lou
su: user lou does not exis
5612ebc3 conn=1053 fd=12 ACCEPT from IP=192.168.0.101:59310 (IP= 192.168.0.101:389)
5612ebc3 conn=1053 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
5612ebc3 conn=1053 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
This session is anonymous (no BIND operation).
5612ebc3 conn=1053 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text=
5612ebc3 conn=1053 op=1 SRCH base="dc=group1,dc=ldap" scope=2 deref=0
filter="
(&(uid=lou)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))) )"
5612ebc3 conn=1053 op=1 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey
5612ebc3 conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=
err=50
If you look that up you find:
insufficientAccessRights (50)
Indicates that the client does not have sufficient access rights to perform the operation.
So the anon user does not have the right to do a search from the base "dc=group1,dc=ldap" (this says nothing about the right to read the uid=lou entry).
You have an ACL problem. I suggest removing all ACLs and starting with this:
access to attrs="userPassword" by self =w by * auth
access to * by * read
Once you have the basic service working you can start thinking about ACLs. You may then want to define an account for your Linux client machines to use when accessing LDAP so that you don't have to give anon access to your data.
Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
openldap-technical@openldap.org
-
Andrew Findlay -
Varadi, Louis - 0442 - MITLL