OpenLDAP ACL to allow users to change their password
772
What ACL should be added slapd.conf to allow users to change their password. We are now having the default ACL allowing only rootdn the rights to modify while allowing reading by everyone including anonymous.
access to attrs=userPassword
by self write
by anonymous auth
by users none
access to * by * read
(Note that for security reasons you DON'T want everyone able to read the UserPassword attribute -- that would allow people to skim your shadow/encrypted passwords & run a crack program against them easily.)
Edit to add requested explanation of the access to attrs=userPassword ACL above
by self write
The logged in user can write (change) their own userPassword attribute -- this is what lets you change your password.
by anonymous auth
Anonymous users (ones who bound to the directory anonymously - that is, without specifying a DN & password) may access userPassword for the sole purpose of authentication (they don't have access to it for any other purposes, like searching or browsing).
by users none
This denies logged in users access to anyone else's userPassword attribute. Theoretically this could be auth as well, but normally (At least in my environment) a logged-in user shouldn't need to authenticate/bind as another user.
Try something along the lines of:
(Note that for security reasons you DON'T want everyone able to read the
UserPasswordattribute -- that would allow people to skim your shadow/encrypted passwords & run a crack program against them easily.)Edit to add requested explanation of the
access to attrs=userPasswordACL aboveby self writeThe logged in user can write (change) their own userPassword attribute -- this is what lets you change your password.
by anonymous authAnonymous users (ones who bound to the directory anonymously - that is, without specifying a DN & password) may access userPassword for the sole purpose of authentication (they don't have access to it for any other purposes, like searching or browsing).
by users noneThis denies logged in users access to anyone else's userPassword attribute. Theoretically this could be
authas well, but normally (At least in my environment) a logged-in user shouldn't need to authenticate/bind as another user.