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 | -----------------------------------------------------------------------