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