|
I prefer to use ACI over NO-USER-MODIFICATION when there is any need for a DUA to update values (whether the DSA also updates the same values on its own).
I also prefer that when these attributes are updates, that the modification tracking attributes (modifyTimeStamp, modifyCSN, version, whatever) are updated, but I'm not sure it needs to be stated in the draft — which attributes, and under what conditions are updated is probably implementation-specific. Likely we could remind server implementors to do whatever is needed to cause replication to properly happen.
Jim
>>> Howard Chu <hyc@highlandsun.com> 11/22/04 7:18:57 AM >>> Ludovic Poitou wrote: > Draft 9 has not been published yet. Still working on it. > > Adding the NO-USER-MODIFICATION keyword to the state information would > prevent administrators to update the attributes for unlocking a user for > example, and would probably require the introduction of a set of > administration procedures for password policy management, such as > unlocking a locked account ... > The security considerations mention that ACI should be used to restrict > access to the state attributes. I think that the security considerations > need a little bit of work for clarification of the security issues and > the recommandations. OK, I guess I can understand that. But I don't think it's surprising to require a special administration procedure to directly manipulate these attributes. After all, in their normal operation, they are set completely automatically by directory-internal operations, so direct manipulation of their values could be viewed as an unusual/extraordinary occurrence. There was also a question about whether a DSA should update an entry's modifiersName / modifyTimeStamp operational attributes whenever performing a Password Policy State Update. My opinion is no, since these are internal operations, but there's no explicit statement in the draft. The decision has some impact on replication, as some replication mechanisms might only propagate a change when they see a timestamp change. > Howard Chu wrote: > >> I vaguely recall someone mentioning that the policy schema would be >> updated again for draft 9, but I can't seem to find it in my mailbox >> now. (So was I just imagining it?) Anyway, it seems that the state >> information needs to be defined with NO-USER-MODIFICATION in order to >> serve its purpose, otherwise any user with write access to their own >> entry can circumvent most of the policies. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext