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