[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ppolicy and Access Control to operational Attributes
This is also ITS#3573. Yes, I believe those operational attributes need
to be marked NO-USER-MODIFICATION but since the draft 7 spec doesn't
define them this way, I haven't made the change. The same problem still
remains in the draft 8 spec. I haven't had time to read through the
current draft (8) to see what other problems remain, been too busy with
back-config. Anyone else who feels like investigating is welcome to jump
in. You could start by looking at the draft 8 spec:
http://www.watersprings.org/pub/id/draft-behera-ldap-password-policy-08.txt
I believe making this change may cause other problems in a replication
environment, but I don't remember the details. At any rate, there are
lots of undefined/unspecified behaviors wrt replication here.
Ralf Haferkamp wrote:
Hi,
I had a look at the ppolicy-overlay (version from HEAD) and I am
wondering now how access controls have to be setup in order to make it
work.
In order to allow a user to change his own password it seems that I need
to give him "write" access to some of the operational Attributes that
hold the Password Policy State (e.g. pwdChangedTime, pwdHistory and
maybe some others). Otherwise I get "Insufficient access (50)" when the
user tries to modify his "userPassword". But if I give him "write"
access the user can just circumvent password policies be directly
modifying e.g. "pwdChangedTime" without changing the password.
Did I overlook something? Shouldn't these operational Attributes be
flagged with "NO-USER-MODIFCATION" in the Schema? That seems at least
to fix the above issue.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support