[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:


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:


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