any LDAP experts around

[James McDonald]

Lonni J Friedman wrote:
> I have a Linux server running OpenLDAP-2.4.10, which a number of
> client systems (Linux & Mac) use for ssh/shell account authentication.
>   I'm hitting the frustrating problem where all attempts by any user
> to change their LDAP password with 'passwd' fail with:
> LDAP password information update failed: Insufficient access
> passwd: Permission denied
>
> I strongly suspect this is due to wrong ACLs in slapd.conf, but I've
> following the official doc (
> http://www.openldap.org/doc/admin23/slapdconfig.html#Configuration%20File%20Example
> ) without any improvement.
>
> I've got the following in /etc/openldap/slapd.conf :
> ####################
> database        bdb
> suffix          "dc=cuda-fs0,dc=foo,dc=com"
> rootdn          "cn=Manager,dc=cuda-fs0,dc=foo,dc=com"
> rootpw          {MD5}XXXXXXXXXXXXXXXXXX==
> access to attrs=userPassword
>       by self write
>       by anonymous auth
>       by dn.base="cn=Manager,dc=cuda-fs0,dc=foo,dc=com" write
>       by * none
> access to *
>       by * read
> ####################
>
> I kicked the LDAP server to debug level 256 to attempt to figure out
> exactly what is going wrong, and saw the following output at the time
> of an attempted (and failed) password change:
>
> conn=8 op=6 BIND
> dn="uid=lfriedman,ou=People,dc=cuda-fs0,dc=foo,dc=com" method=128
> conn=8 op=6 BIND
> dn="uid=lfriedman,ou=People,dc=cuda-fs0,dc=foo,dc=com" mech=SIMPLE ssf=0
> conn=8 op=6 RESULT tag=97 err=0 text=
> conn=8 op=7 MOD dn="uid=lfriedman,ou=People,dc=cuda-fs0,dc=foo,dc=com"
> conn=8 op=7 MOD attr=userPassword
> conn=8 op=7 RESULT tag=103 err=50 text=
>
> That "tag=103 err=50" seems to be the critical bit of info, however
> I've googled on it for a while, and the consensus seems to be that
> incorrect ACLs would cause it.  However since I'm using exactly what
> is suggested in the official dox, that seems unlikely.
>
> /etc/pam.d/passwd on the Linux client systems hasn't changed for ages,
> and contains:
> #########
> auth       include      system-auth
> account    include      system-auth
> password   include      system-auth
> #########
>
> /etc/pam.d/system-auth on the Linux client systems also hasn't changed
> recently, and contains:
> #########
> auth        required      pam_env.so
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        sufficient    pam_ldap.so use_first_pass
> auth        required      pam_deny.so
>
> account     required      pam_unix.so broken_shadow
> account     sufficient    pam_succeed_if.so uid < 500 quiet
> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account     required      pam_permit.so
>
> password    requisite     pam_cracklib.so try_first_pass retry=3
> password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
> use_authtok
> password    sufficient    pam_ldap.so use_authtok
> password    required      pam_deny.so
>
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> session     [success=1 default=ignore] pam_succeed_if.so service in
> crond quiet use_uid
> session     required      pam_unix.so
> session     optional      pam_ldap.so
> #########
>
> In an attempt to isolate this better, I figured I'd write up a PHP
> frontend to ldapmodify and see if it fared any better.  Sadly, it
> fails as well in all password change attempts:
> PHP Warning:  ldap_mod_replace() [<a
> href='function.ldap-mod-replace'>function.ldap-mod-replace</a>]:
> Modify: Strong(er) authentication required in
> /var/www/html/ldap/ldap.inc on line 56
>
> That error is coming out of here:
>
> $ldapconn = ldap_connect("cuda-fs0.nvidia.com", 389) ;
> $ldapbind = @ldap_bind($ldapconn,"uid=".$PHP_AUTH_USER.",dc=cuda-fs0,dc=nvidia,dc=com",$MPASSWD)
> ;
> if ( ldap_mod_replace ($ldapconn,
> "uid=".$PHP_AUTH_USER.",dc=cuda-fs0,dc=nvidia,dc=com",
> array('userpassword' =>
> "{MD5}".base64_encode(pack("H*",md5($PHP_NEWPASS)))))) {
> 			print "SUCCEDED" ;
> } else {
> 			print "PASSWORD CHANGE FAILED" ;
> }
>
> I'm at a complete loss at this point on what is wrong.
>
>   
Is userpassword or userPassword causing an issue?

You mentioned you can do this as manager so it's definately perms yes?

Weird!