slapd ACLs: user password change, by self write not working as expected

[cense@dictatornet.cjb.net]

Hello list and list members,

I am at the end of my rope. I have searched several mailing list archives
(including this one). I have read all the documentation and FAQs on the
openldap.org site. I have search google and other indexes. I have modified my
slapd.conf file (and restarted slapd!) numerous times. I have tried several
syntaxes and command line argument options. I have found people with similar
problems to mine, but none identical and none with a solution that worked for me.

Here is my problem:

I have slapd running quite nicely serving user/pass information to Linux, IRIX,
Mac OS X and Windows clients (through samba). What I cannot do is have users be
able to change their own passwords. Better put, the "by self write" ACL doesn't
seem to work. Users cannot bind to slapd and modify their password attributes.

As a side note: I have hacked up a 'passwd' replacement for the Linux, IRIX and
Mac OS X machines derived from the PADL software (www.padl.com) smbldap-tools
package. This hack uses ldappasswd and ldapmodify to simultaneously change the
userPassword and lmPassword/ntPassword. I have determined that the problem is
not within my hacked script as I can pull out the ldapmodify/ldappasswd
statements, use them on the command line and recieve the same results: failure.
I have tried many command line variants for the ldapmodify statement, none have
worked. It doens't matter how I try and use ldapmodify or ldappasswd, they
simply do not achieve the desired outcome.

The problem I am currently having is this:

ldapmodify returns code 50: "Insufficient access" when ever I try and
update/modify the lmPassword/ntPassword attribute. Now, I know what some of you
may be thinking: "I bet he didn't bind to slapd as the user he is trying to
change the password for"... but I did:

ldapmodify -x -H ldaps://<ip>/ -D 'uid=tuser,ou=People,dc=bio,dc=<snip>,dc=ca'
-w 'test22' -f /tmp/tmp.ldapmodify

I assure everyone that I am not binding anonymously. I am specifically binding
(and binding successfully) as the user whos password(s) I wish to change.

/tmp/tmp.ldapmodify contains the following:

dn: uid=tuser,ou=People, dc=bio,dc=ucalgary,dc=ca
changetype: modify
replace: lmpassword
lmpassword: 86859AF790F<snip>
-
changetype: modify
replace: ntpassword
ntpassword: 0C6AE10552<snip>
-

I am only using the above file as a test bed for ldapmodify. I don't believe
that there is anything wrong with it, but please do tell if there is. I
certainly hope this isn't the source of my problem... as this is the exact
output (minus the snipped hashes) the hacked up smbldap-tools script generates
for changing the password.

The exact error output I am getting is this:

ldap_modify: Insufficient access
ldif_record() = 50

I have tried many ACL variants during my trek for a solution. Currently, I am
using a slightly modified one from the openldap FAQ:

## slapd.conf snippet ##

access to attrs=userPassword,lmPassword,ntPassword
  by self write
  by anonymous auth
  by dn.base="cn=main,dc=bio,dc=ucalgary,dc=ca" write
  by * none

access to *
 by self write
 by dn.base="cn=maint,dc=bio,dc=ucalgary,dc=ca" write
 by * read

## end slapd.conf snippet ##

I am not certain whether the location of the ACL statement within the slapd.conf
file (in relation to other directives) is important, mine is at the bottom.

Is there anything wrong with my ACLs? Am I using ldapmodify incorrectly? If I
have bound to the directory as "tuser" successfully, why do I not have write
access to lmPassword, ntPassword or userPassword as the ACLs listed above are
explicitly configured to allow?

Also, as side note: I configured loglevel in slapd.conf to 128 so that I could
see what was going on with the ACLs but I don't get any ACL information... what
gives? I check my syslog and the log output isn't any different that if I don't
set loglevel at all. Here is a sample of the only relavent log output I can get:

Nov  5 19:44:16 <edited> slapd[5438]: conn=2585785 op=1 MOD
dn="uid=tuser,ou=People, dc=bio,dc=ucalgary,dc=ca"

Now, I am quite sure I am doing something wrong with the loglevel or syslog, or
looking in the wrong place for the log files because I am fairly sure there
should be *some* output regarding ACLs when the loglevel is set to 128...

My greatest appologies if I was too stupid to find a thread with the answer to
this question. Any help that can be provided is also greatly appreciated.

--
cense