LDAP password information update failed: Insufficient access (50)

ldapopenldap

This problem is similar to this, except that in this case, it is not working. 🙁

So far, I have this set as the ACL:

access to attrs=userPassword,shadowLastChange,shadowMin,shadowMax,shadowWarning,loginShell,shadowLastChange
    by anonymous auth
    by self write
    by users read 
    by * none

access to *
    by self write
    by users read
    by * none

I am able to change the password as the root:

[root@sl6 openldap]# ldappasswd -D 'cn=root,dc=monzell,dc=com' -W -S 'uid=monzell,ou=People,dc=monzell,dc=com'
New password: 
Re-enter new password: 
Enter LDAP Password: 
[root@sl6 openldap]#

But not as the user:

[root@sl6 openldap]# ldappasswd -D 'uid=monzell,ou=People,dc=monzell,dc=com' -W -S 'uid=monzell,ou=People,dc=monzell,dc=com'
New password: 
Re-enter new password: 
Enter LDAP Password: 
Result: Insufficient access (50)

Here is my schema of the user, BTW:

# monzell, People, monzell.com
dn: uid=monzell,ou=People,dc=monzell,dc=com
uid: monzell
cn: monzell
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 15192
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/users/monzell
userPassword:: (REDACTED)

As well as my base DN:

dn: dc=monzell,dc=com
dc: monzell
objectClass: top
objectClass: domain

dn: ou=People,dc=monzell,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=monzell,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit

I am running scientific linux 6.1, with OpenLDAP 2.4.23-15.

(Incidentally, the setup is based on the page here)

The log output from ldappasswd returns the following:

Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 fd=24 ACCEPT from IP=127.0.0.1:50252 (IP=0.0.0.0:389)
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=0 BIND dn="uid=monzell,ou=People,dc=monzell,dc=com" method=128
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=0 BIND dn="uid=monzell,ou=People,dc=monzell,dc=com" mech=SIMPLE ssf=0
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=0 RESULT tag=97 err=0 text=
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=1 PASSMOD id="uid=monzell,ou=People,dc=monzell,dc=com" new
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=1 RESULT oid= err=50 text=
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 op=2 UNBIND
Aug 20 08:45:18 sl6 slapd[4634]: conn=1019 fd=24 closed

Here is the conf file:

include     /etc/openldap/schema/corba.schema
include     /etc/openldap/schema/core.schema
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/duaconf.schema
include     /etc/openldap/schema/dyngroup.schema
include     /etc/openldap/schema/inetorgperson.schema
include     /etc/openldap/schema/java.schema
include     /etc/openldap/schema/misc.schema
include     /etc/openldap/schema/nis.schema
include     /etc/openldap/schema/openldap.schema
include     /etc/openldap/schema/ppolicy.schema
include     /etc/openldap/schema/collective.schema
pidfile     /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
TLSCertificateFile /etc/openldap/ssl/cert.crt
TLSCertificateKeyFile /etc/openldap/ssl/private.key
database    bdb
suffix "dc=monzell,dc=com"
checkpoint  1024 15
rootdn "cn=root,dc=monzell,dc=com"
rootpw <REDACTED
directory   /var/lib/ldap
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub
database monitor
access to attrs=userPassword 
 by self write
 by users read 
 by * none
access to *
 by self write
 by users read
 by * none

EDIT: Now this is interesting. When I set the log level to 128, I get this in the log file:

Aug 20 12:27:54 sl6 slapd[2692]: /etc/openldap/slapd.conf: line 139: warning: cannot assess the validity of the ACL scope within backend naming context
Aug 20 12:27:54 sl6 slapd[2692]: /etc/openldap/slapd.conf: line 144: warning: cannot assess the validity of the ACL scope within backend naming context
Aug 20 12:27:54 sl6 slapd[2693]: config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context
Aug 20 12:27:54 sl6 slapd[2693]: slapd starting

EDIT: And when I attempted to reset the password, I see this:

Aug 20 12:32:47 sl6 slapd[2868]: => access_allowed: result not in cache (userPassword)
Aug 20 12:32:47 sl6 slapd[2868]: => access_allowed: auth access to "uid=monzell,ou=People,dc=monzell,dc=com" "userPassword" requested
Aug 20 12:32:47 sl6 slapd[2868]: => slap_access_allowed: backend default auth access granted to "(anonymous)"
Aug 20 12:32:47 sl6 slapd[2868]: => access_allowed: auth access granted by read(=rscxd)
Aug 20 12:32:47 sl6 slapd[2868]: => access_allowed: backend default write access denied to "uid=monzell,ou=People,dc=monzell,dc=com"

Best Answer

I suggest you enable the LDAP log and take a look at this. On Red Hat based distros, you can do it by following steps:

Set a syslog facility:

cat /etc/sysconfig/ldap 
SLAPD_OPTIONS="-l local4"

Specify a log file for OpenLDAP in /etc/syslog.conf:

# OpenLDAP log
local4.*            /var/log/ldap.log

touch /var/log/ldap.log and restart syslogd

On other distros, at the step one, simply add the -l local4 into the start() function in your init script.

EDIT

Set loglevel to 128 (ACL processing) and try again.

EDIT 2

cannot assess the validity of the ACL scope within backend naming context

Put the ACLs before the backend context:

access to attrs=userPassword 
 by self write
 by users read 
 by * none
access to *
 by self write
 by users read
 by * none

database    bdb
suffix "dc=monzell,dc=com"
checkpoint  1024 15
rootdn "cn=root,dc=monzell,dc=com"
rootpw <REDACTED
directory   /var/lib/ldap
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub
database monitor

Related Solutions

Ldap – Securing userPassword access with OpenLDAP in RHEL

pam_ldap shouldn't be attempting to read the userPassword value to log you in -- It logs you in by doing an LDAP bind with the DN that it retrieves.

It's possible the search parameters pam_ldap uses are over-broad & it tries to pull userPassword as a result, but if your ACL is set up correctly (looks fine to me) it won't get that value in its results.

Just in case your ACLs aren't fine (I've been known to miss stupidly obvious stuff before), here's the working ACL list from my production LDAP environment :)

# Access and Security Restrictions
# (Most restrictive entries first)
access to attrs=userPassword
    by self write
    by dn.sub="ou=sync,dc=mydomain,dc=com" read
    by anonymous auth
by users none

access to * by * read

The trailing access to * by * read is important, I didn't see it in your examples so I'm not sure if it's missing or just omitted from your snippet.

The sync line is for my LDAP synchronization service and isn't necessary if you're not doing replication...

LDAP (slapd) – Authenticated User Cannot Modify Self

Lists  of  access  directives are evaluated in the order they appear in
slapd.conf.  When a <what> clause matches the  datum  whose  access  is
being evaluated, its <who> clause list is checked.  When a <who> clause
matches the accessor's properties, its <access> and  <control>  clauses
are evaluated.  Access control checking stops at the first match of the
<what> and <who> clause, unless otherwise  dictated  by  the  <control>
clause.

First matching <what> and <who> for attempt to change password is:

access to *
   by users read

If you move 'access to *' clause at end of list it should work fine. Or just swap order of "by users read" and "by self write".

ACLs is most tricky part of OpenLDAP configuration, so read slapd.access(5) carefully, and be sure that you completely understood how ACLs work before writing some non-trivial.

Best Answer

Related Solutions

Ldap – Securing userPassword access with OpenLDAP in RHEL

LDAP (slapd) – Authenticated User Cannot Modify Self

Related Topic