New User unable to authenticate on new client

[Varadi, Louis - 0442 - MITLL]

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

[***@ldapservrer]# ldapwhoami -x -D cn=ldapadmin,dc=group1,dc=ldap -W

Enter LDAP Password:

dn:cn=ldapadmin,dc=group1,dc=ldap



This user fails

[***@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



_______________________________



[***@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 ***@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





[***@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

[Andrew Findlay]

Content preview: 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 > > [***@ldapserver]# ldapwhoami -x -D cn=lou,dc=group1,dc=ldap
-W > > Enter LDAP Password: > > ldap_bind: Invalid credentials (49) [...]


Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: skills-1st.co.uk]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Varadi, Louis - 0442 - MITLL
I have added a user but cannot authenticate.
This user fails
ldap_bind: Invalid credentials (49)
# 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
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).

Post by Varadi, Louis - 0442 - MITLL
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

[Varadi, Louis - 0442 - MITLL]

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:***@skills-1st.co.uk]
Sent: Tuesday, October 06, 2015 4:17 AM
To: Varadi, Louis - 0442 - MITLL
Cc: openldap-***@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

Post by Varadi, Louis - 0442 - MITLL
I have added a user but cannot authenticate.
This user fails
ldap_bind: Invalid credentials (49)
# 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
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=*)"

Post by Varadi, Louis - 0442 - MITLL
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).

Post by Varadi, Louis - 0442 - MITLL
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)))
)"

Post by Varadi, Louis - 0442 - MITLL
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/ [phone] |
-----------------------------------------------------------------------