Re: slapd ACL to allow Password Modify exop by ldappasswd - but deny direct modification via ldapmodify

[Tim Watts <tw@dionic.net>]

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


--
Tim Watts
Personal Blog: 
http://www.dionic.net/tim/

"History will be kind to me for I intend to write it."