0

I am running an OpenLDAP service using the slapd.d/ configuration style. I am testing creating users and authenticating as user. Here's my test script, which ends with a fail: ldap_bind: Invalid credentials (49).

ldapsearch -H ldapi:/// -Y EXTERNAL -b "dc=foo,dc=bar,dc=nl"

provides me with the user in question (among others)

dn: uid=testuser,ou=people,dc=foo,dc=bar,dc=nl
givenName: Test
sn: User
uid: testuser
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
uidNumber: 2002
gidNumber: 2003
loginShell: /bin/bash
homeDirectory: /home/testuser
cn: TestUser
userPassword:: e1NTSEF9eGI2Y3ZrbVByd2lPT01HT0RQWFUyZitEYm5xdy9JaHE=

As a sanity check, I change the password using

result=$(slappasswd -s tree)

echo "dn: uid=testuser,ou=people,dc=foo,dc=bar,dc=nl" > test.ldif
echo "changetype: modify" >> test.ldif
echo "replace: userPassword" >> test.ldif
echo "userPassword: $result" >> test.ldif

ldapmodify -Y EXTERNAL -H ldapi:/// -f test.ldif

ldapsearch -H ldapi:/// -Y EXTERNAL -b "dc=foo,dc=bar,dc=nl"

again, and indeed shows me the password successfully changed:

dn: uid=testuser,ou=people,dc=foo,dc=bar,dc=nl
...
userPassword:: e1NTSEF9RTBnNDkxR0FPSzg0ZUt6M2dleWl1TWI3VHk1SURzekY=

ldapwhoami -x -D "uid=testuser,ou=people,dc=foo,dc=bar,dc=nl" -w tree -H ldapi:///

returns

ldap_bind: Invalid credentials (49)

What am I misunderstanding? If more details are necessary, I can provide.

For example, my olcAccess attributes are:

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
olcAccess: {1}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {2}to attrs=shadowLastChange by self write by * read
olcAccess: {3}to * by * read

2 Answers 2

1

Your ACL rules deny 'auth' access to anonymous clients, because your {0} rule is not fall-through:

to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage

If the request matches to * but does not match any by entry, then it will reach an implicit final by * none stop entry (sort of like iptables chain policy) which will deny all other access to *. That is, if all defaults were specified explicitly, the same rule would look like this:

to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage [stop]
  [by * none stop]

To make the entire rule fall-through, you need an explicit by * none entry with the break option instead of the default stop, like this:

to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
  by * break

(For comparison, the {1} rule with userPassword is deliberately non-fallthrough, therefore it has a by * none at the end that expands to by * none stop.)


There are three modes for each by entry:

  • stop (the default) ends the check completely.
  • break exits from the current 'to' section, but keeps trying other 'to' sections.
  • continue keeps trying also other 'by' entries in the same section. (They can be additive, e.g. granting read to one 'by' and write to another 'by'.)
1
  • It works, and this also solved a number of other confusing errors that I declined to understand at the time. Thank you.
    – XGDragon
    Commented Mar 29 at 12:49
0

I think you have to put the type of hash algorithm used to generate the password, in front of the password value inside the ldif (to let openldap know that you already hashed the password). If not specified, slappasswd should use {SSHA}, hence you should set your ldif in the following way

result=$(slappasswd -s tree)

echo "dn: uid=testuser,ou=people,dc=foo,dc=bar,dc=nl" > test.ldif
echo "changetype: modify" >> test.ldif
echo "replace: userPassword" >> test.ldif
echo "userPassword: {SSHA}$result" >> test.ldif

ldapmodify -Y EXTERNAL -H ldapi:/// -f test.ldif

ref. Set already hashed password for user against open ldap

4
  • 1
    The output of slappasswd already contains the hashing algorithm. Commented Mar 27 at 14:47
  • This did not work. This inspired me to also try ldappasswd -s tree -Y EXTERNAL -H ldapi:/// uid=testuser,ou=people,dc=foo,dc=bar,dc=nl, rather than an ldapmodify. This also succesfully changed the userPassword, but still ldap_bind: Invalid credentials (49).
    – XGDragon
    Commented Mar 27 at 15:36
  • @Gerald Schneider, you're right, my bad...
    – sqrt-1
    Commented Mar 28 at 9:34
  • @XGDragon, your steps sounds good to me. Even the ACLs. Have you already increased slapd loglevel to see whether any ACLs are in the way denying auth-level access to attribute userPassword?
    – sqrt-1
    Commented Mar 28 at 9:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .