Steps: . Using default password policy: stored in SSHA . Give ACI to update all attributes including userpassword. aci: (targetattr ="*")(version 3.0;acl "allow all";allow (all) userdn="ldap:///anyone";) .Let uid=tuser0 replace other user uid=tuser1's userpassword as follows:
$ldapmodify ... -D "uid=tuser0,dc=example,dc=com" -w password << EOF dn: uid=Nuser1,dc=example,dc=com changetype: modify replace: userpassword userpassword: {CLEAR}newuser1 EOF
Then, the tuser1's password is stored as a clear text.
$ldapsearch ... userpassword dn: uid=Nuser1,dc=example,dc=com userpassword: newuser1
Expected result: Ordinary user should not be allowed to override the password policy.
Note: it occurs in 389-ds-base-1.2.11.
Creating 6.5 clone.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=975176
If you enable password syntax checking, then this operation is rejected. So the question is should we reject this operation if syntax checking is off?
Replying to [comment:6 mreynolds]:
Good point. I think it's been this way since we started checking for pre-hashed passwords. We should confirm this with some testing.
I think the ideal behavior would be to reject pre-hashed passwords by non-administrative users even when syntax checking is turned off. The password storage scheme is really a separate part of password policy than syntax checking, and we shouldn't allow it to be overridden by normal users. If our current behavior is not a new regression, we should look at fixing this in the 1.3.2 milestone.
Replying to [comment:7 nkinder]:
Replying to [comment:6 mreynolds]: If you enable password syntax checking, then this operation is rejected. So the question is should we reject this operation if syntax checking is off? Good point. I think it's been this way since we started checking for pre-hashed passwords. We should confirm this with some testing. I think the ideal behavior would be to reject pre-hashed passwords by non-administrative users even when syntax checking is turned off.
I think the ideal behavior would be to reject pre-hashed passwords by non-administrative users even when syntax checking is turned off.
I agree.
The password storage scheme is really a separate part of password policy than syntax checking, and we shouldn't allow it to be overridden by normal users. If our current behavior is not a new regression, we should look at fixing this in the 1.3.2 milestone.
Ok, I'll do some testing, and go from there.
Thanks! Mark
I verified 8.2 showed the same symptom. So, this is not a regression.
I'm changing the milestone of this ticket to 1.3.2 and updating the bz975176.
Thanks, Mark!
attachment 0001-Ticket-47389-Non-directory-manager-can-change-the-in.patch
git merge ticket47389 Updating e024b67..0a7ff4a Fast-forward ldap/servers/slapd/pw.c | 52 +++++++++++++++++++++++++--------------------- 1 files changed, 28 insertions(+), 24 deletions(-)
git push origin master e024b67..0a7ff4a master -> master
commit 0a7ff4a Author: Mark Reynolds mreynolds@redhat.com Date: Tue Jun 18 17:19:13 2013 -0400
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.2 - 07/13 (July)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/726
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.