Subject: Re: comments on ldap password policy draft

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 27 Oct 1999 20:35:41 -0600

Aside from suggesting additional policy, I think we've come full circle on this.  Here's the original problem:

>If an administrator changes expiration policy, each pwdExpirationTime
>in that policy would need to be adjusted.  If an administrator
>didn't previously have an expiration policy, it not possible to
>establish an pwdExpirationTime specific to this entry and as
>until the administrator does add some pwdExpirationTime value,
>the current password will never expirse.  If a password expiration
>policy is in affect, no pwdExpirationTime should imply 'has expired'.

Let's say we leave the pwdExpirationTime as is.  If an administrator changes the expiration policy, the pwdExpirationTime for each object could be calculated by taking the difference between the old expiration policy and the new expiration policy and applying it to each pwdExpirationTime. The problem of a previous non existent policy could still be handled as you state below.

The implementation of your suggestion is easier to explain but adds an attribute (pwdPasswordTimeStamp) to every object.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/25/99 3:36:25 PM >>>
At 10:46 AM 10/25/99 -0600, Jim Sermersheim wrote:
>>If you want to avoid the policy fetch for each bind, you
>>could store both a timestamp of last password modification
>>and the expiration time.
>
>I'm not sure how that would help. Wouldn't we still need to look at the policy (in case it changed?)

No.  pwdExpirationTime would be computed on every policy change
based upon pwdPasswordTimeStamp.  The advantage of having
pwdPasswordTimeStamp is that you have a reference time to
use in computing pwdExpirationTime.

If pwdPasswordTimeStamp didn't exist for some reason when the
policy was changed, then you would have to fall back to either:
	1) expire now
	2) expire policy seconds from now.

The choice, of course, could be a matter of policy.

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 1999 22:32:53 -0700

The userPassword attribute type is not SINGLE-VALUED.
I am curious as to the whether this was intended and, if so, what
was the rational of this choice?
How should this be applied to the password policy work underway?
Should the policy be able to support multiple valued passwords?
Should the policy be able to limit users to single passwords?

Kurt

----