Subject: Re: [ldapext] draft-behera-ldap-password-policy - last login time

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 23 Feb 2005 23:11:05 -0700

Regarding replication, I favor allowing implementations to solve their own consistency problems. A highly usable implementation would allow for any state attribute to be configured for different levels of replication consistency (from "never replicated", to whatever the highest level of consistency available is). This way the admin can decide how consistently the state data is replicated.
 
I guess what I'm saying is that I see this as a replication problem in general, and would rather not solve this level of replication problems in the password policy I-D by defining multiple sets of attributes and specifying different grades of replication requirements for each. I do think it's reasonable to address problems of loose consistency * which is what caused the use of time to be used for things like failure count.
 
Jim

>>> Howard Chu <[email-masked]> 2/23/05 9:11:53 PM >>>
John McMeeking wrote:

> I've had some recent requests for some sort of "last login time" attribute
> or a "unused account" policy so that accounts can be disabled if they have
> not been used for 6 months. Would either of these be appropriate for the
> password policy draft?

Both of those sound like good things to have, and it does seem to tie in 
to the rest of the password policy features. There would still be 
replication issues here.

It seems to me that one solution to these replicated state attributes 
may be to define a second set of attributes - one that is DSA-specific, 
never implicitly replicated, and another one that serves as an aggregate 
for a collection of servers. Then one can specify policies for each set 
independently, e.g., "number of failed attempts" on a single DSA vs 
across the network. Sites that require total accountability could set a 
policy implementing counts across all replicas, other sites that want to 
avoid the overhead of maintaining centralized counts could set a policy 
using only dsa-specific attributes.

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

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 24 Feb 2005 15:25:29 +0100

Jim,

I tend to agree with you. But I also see the point of Howard. X.500 and 
LDAP both define different types of Operational Attributes: DSA Specific 
and Directory Operation with specific semantic with regards to the 
consistence of the attribute value in replicated systems.
Defining an operational attribute and letting implementation (or 
administrator) decide if it'll be replicated or not is actually messing 
with the distinctions between the various operational types.

Ludovic.

Jim Sermersheim wrote:

> Regarding replication, I favor allowing implementations to solve their 
> own consistency problems. A highly usable implementation would allow 
> for any state attribute to be configured for different levels of 
> replication consistency (from "never replicated", to whatever the 
> highest level of consistency available is). This way the admin can 
> decide how consistently the state data is replicated.
> I guess what I'm saying is that I see this as a replication problem in 
> general, and would rather not solve this level of replication problems 
> in the password policy I-D by defining multiple sets of attributes and 
> specifying different grades of replication requirements for each. I do 
> think it's reasonable to address problems of loose consistency — which 
> is what caused the use of time to be used for things like failure count.
> Jim
>
> _http://www.symas.com <http://www.symas.com/>_ 
> _http://highlandsun.com/hyc_
> [email-masked] <mailto:[email-masked]>_
> _https://www1.ietf.org/mailman/listinfo/ldapext_
>
>------------------------------------------------------------------------
>

-- 
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~