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 |
-----------------------------------------------------------------------
Attachment:
smime.p7s
Description: S/MIME cryptographic signature