Subject: Re: [ldapext] Password Policy operational attributes

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 22 Nov 2004 09:05:31 -0700

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 <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Tue, 23 Nov 2004 07:57:14 +0100

Jim Sermersheim wrote:
> 
> I also prefer that when these attributes are updates, that the 
> modification tracking attributes (modifyTimeStamp, modifyCSN, version, 
> whatever) are updated,

I disagree strongly here. You'd loose very valuable information about 
who did the last administrative changes to an entry.

IMO modification of password policy state information SHOULD NOT update 
'modifyTimeStamp' and 'modifiersName'. Attributes used for replication 
SHOULD be updated off course ('modifyCSN' looks like such an attribute).

> Likely we could remind server 
> implementors to do whatever is needed to cause replication to properly 
> happen.

+1

Ciao, Michael.

---

From: John McMeeking <[email-masked]>
Date: Tue, 23 Nov 2004 06:39:15 -0600

> SHOULD be updated off course ('modifyCSN' looks like such an attribute).

I took Jim's comment as meaning that when the password policy attributes
are directly modified by a client (e.g. the attributes are part of a modify
request), modifyTimestamp, etc. should be updated.  I don't think he was
suggesting that modifyTimestamp should be set as a result of a bind
failure, and my first reaction is that a failed bind should not update
modifyTimestamp.

> > implementors to do whatever is needed to cause replication to properly

John  McMeeking