Subject: [ldapext] Password Policy operational attributes

From: Howard Chu <[email-masked]>
Date: Mon, 22 Nov 2004 02:07:42 -0800

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: Ludovic Poitou <[email-masked]>
Date: Mon, 22 Nov 2004 14:18:34 +0100

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.

Ludovic

-- 
Ludovic Poitou
Directory Architect.
Directory Server Group, Grenoble, France
Sun Microsystems Inc.

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: John McMeeking <[email-masked]>
Date: Mon, 22 Nov 2004 08:16:03 -0600

I only see two operational attributes that arguably should be modifiable:
pwdReset and pwdAccountLockedTime.  And pwdAccountLockedTime might be
modifiable only certain conditions:

pwdAccountLockedTime - arguably could be set to 000001010000Z to lock the
account, or the attribute deleted to unlock an account.  I see no reason
why a server should allow it to be set to other values.

So, should a server allow pwdReset and pwdAccountLockedTime values to be
changed via a modify request?  Or should this be an extended operation?  It
doesn't matter much to me, but the document probably ought to state that
these values can be modified if that is the intent.  I think its leaving to
much to the imagination of the implementer to expect interoperability when
two of the attributes might possibly require different behavior than the
others.

I don't see a reason why pwdChangedTime, pwdFailureTime, pwdHistory or
pwdGraceUseTime (and definitely not pwdPolicySubentry) should be user (or
administrator) modifiable under any conditions.

John  McMeeking

---

From: Howard Chu <[email-masked]>
Date: Mon, 22 Nov 2004 06:18:57 -0800

> need a little bit of work for clarification of the security issues and 

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.

---

From: Neil Dunbar <[email-masked]>
Date: Mon, 22 Nov 2004 15:24:17 +0000

> modifiable only certain conditions:

Agreed.

> administrator) modifiable under any conditions.

Recognising that I'm now into abstruse corner cases here - but the only
one I could see is that, given some out of band alternative
credentialling process, the password could be artificially limited
("clipped") to the lifetime of the alternative credential.

For example - if the user could apply for a certificate, and the system
architect prefers that all credentials expire together, he might want
the pwdChangedTime modified such that expiry of password will take place
at the same time of expiry of certificate. In other words - "give the
user a password lasting for 6 months or the lifetime of his current
certificate, whichever is shorter".

The desirability of such a scheme is a whole different argument...

As I said - real corner case stuff, but it seems to me that fiddling
with the record is sometimes needed, as long as audit trail exists to
demonstrate the alteration. So, I'd tend to allow these attributes to be
modified, even if I can't think of any good reason for them - and leave
the ACI system to restrict modification to the highest levels of
authority.

Cheers,

Neil