0

I am trying to limit write access to users own userPassword attribute. But failing miserably for hours now. Here is what I've done so far:

  • Installed OpenLDAP 2.4 on Arch linux
  • Configured a base DN (dc=exmaple,dc=org) and a Manager to modify,add and delete via Apache Directory Studio
  • Added two organizationalUnit's people and group
  • Added two users under ou=people - uid=timo,ou=people,dc=example,dc=org and uid=heike,...

The next thing I am wanting to do is to be able to modify the users own userPassword. For that I created a changepw.ldif file.

dn: uid=timo,ou=people,dc=example,dc=org
changetype: modify
replace: userPassword
userPassword: newpw

and applied it like this

$ ldapmodify -x -D "uid=timo,ou=people,dc=example,dc=org" -W -f changepw.ldif
modifying entry "uid=timo,ou=people,dc=example,dc=org"
ldap_modify: Insufficient access (50)

I've set the userPassword for uid=timo with Apache Directory Studio first and verified that it's working correctly

To this point everything is working as it should (at least it meet my expectations :-P). So I've added an access control to /etc/openldap/slapd.conf like so:

[...]
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

access  to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=example,dc=org" write by * none

#######################################################################
# MDB database definitions

database        mdb
[...]

and did the usual things:

$ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
$ chown -R ldap:ldap /etc/openldap/slapd.d
$ systemctl restart slapd

and tried again.

$ ldapmodify -x -D "uid=timo,ou=people,dc=example,dc=org" -W -f changepw.ldif
modifying entry "uid=timo,ou=people,dc=example,dc=org"
ldap_modify: Insufficient access (50)

For some reason the access gets denied. I've turn on acl logging and got this:

5f12f36a => access_allowed: result not in cache (userPassword)
5f12f36a => access_allowed: auth access to "uid=timo,ou=people,dc=example,dc=org" "userPassword" requested
5f12f36a => slap_access_allowed: backend default auth access granted to "(anonymous)"
5f12f36a => access_allowed: auth access granted by read(=rscxd)
5f12f36a => access_allowed: backend default write access denied to "uid=timo,ou=people,dc=example,dc=org"

I would greatly appreciate any help!

tuna
  • 113
  • 3

1 Answers1

0

I came up with a solution after I found out that there is a tool called slapacl to test the ACL.

Let me show you what it looked like before any changes.

$ slapacl -F /etc/openldap/slapd.d/ -b "uid=timo,ou=people,dc=example,dc=org" -D "uid=timo,ou=people,dc=example,dc=org" -u userPassword
authcDN: "uid=timo,ou=people,dc=example,dc=org"
userPassword: read(=rscxd)

That is basically what I already figured and gave me enough evidence to question the config generation command (slaptest -f ... -F ...).

The actual problem was that the configuration directory (/etc/openldap/slapd.d) wasn't overriden

You have to remove that directory first and generate the configuration directory again.

$ rm -rf /etc/openldap/slapd.d/*
$ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
$ chown -R ldap:ldap /etc/openldap/slapd.d
$ systemctl restart slapd

And this is how the test should've looked like in the first place.

$ slapacl -F /etc/openldap/slapd.d/ -b "uid=timo,ou=people,dc=example,dc=org" -D "uid=timo,ou=people,dc=example,dc=org" -u userPassword
authcDN: "uid=timo,ou=people,dc=example,dc=org"
userPassword: write(=wrscxd)

I hope someone can benefit from my findings. Its still curious that this is not mentioned in the man pages and that there is no -f (force override) flag for that.

tuna
  • 113
  • 3