Anyone? I'll rephrase the question, having been looking at the source code:

Is there an ACL that allows EXOP_MODIFY_PASSWD to succeed, that DOES NOT allow userPassword to be directly modified?

I suspect if it exists (and it must exist to my mind, because otherwise it's trivial to bypass password policies), it's either got to be a special ACL subject or a special verb (if that's the right term).

From: aclparse.c the available verbs seem to be:

none disclose auth compare search read write add delete manage

and only "write" looks like the closest match.

Subjects:

well, if we are allowing "write", userPassword is out as that's exactly what we do not want.

OK - stumped again...

Cheers,

Tim

On 21/02/13 12:04, Tim Watts wrote:

Hi,

I've been through google and the man pages - no avail. If anyone can help, I'd be very grateful :)

slapd.conf acl:

access to attrs=userPassword by peername.path="/var/run/slapd/ldapi" manage by dn="cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk" manage by self write by * auth

This allows ldappasswd to work, but of course, it also allows anybody to issue an ldapmodify against their own record and store a weak hash (eg {crypt} ) or worse, bypass my check_password plugin policy enforcer.

Removing the "self write" line kills ldapmodify, but also seems to break the password modify exop issues by ldappasswd.

So - how do I allow ldappasswd to work (which respects the policies and allows the server to hash the password using its default hash - SSHA1 in my case) whilst disallowing *direct* modify access to the userPassword: entry?

Answers on a postcard, or a wet herring as appropriate :-|

Many thanks!

Tim