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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 24 Feb 2005 10:05:25 -0700

Sure, but I still don't want to define two attributes for the same state
information. If replicating it seems appropriate, then defining it as
not-DSA Specific is the right thing to do, but beyond that, it feels
like an implementation issue as to whether and how quickly it's
replicated.

>>> Ludovic Poitou <[email-masked]> 2/24/05 7:25:29 AM >>>
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
>
> >>> 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://www.symas.com/ >_ 
> _http://highlandsun.com/hyc_
> Symas: Premier OpenSource Development and Support
>
> _______________________________________________
> Ldapext mailing list
> [email-masked] < mailto:[email-masked] >_
> _https://www1.ietf.org/mailman/listinfo/ldapext_
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ldapext mailing list
> [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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

---

From: John McMeeking <[email-masked]>
Date: Thu, 24 Feb 2005 19:47:37 -0600

I still think single directory first after all these years :-(  So I hadn't
thought of the replication side.

I see the potential for the replication side of this becoming a significant
implementation and performance issue.  A directory used primarily for
authentication generate lots of updates that need to be propagated.
Actions on "read-only" replicas affect every server.  But if that what
someone really needs, they'll accept the price.

My first reaction to multiple attributes is to have only one attribute.
Then I think of times I have used something like a search for entries with
a modifytimestamp > x to find entries that have changed since I last
looked.  In a replicated environment that may not work.  Sometimes I want
to know when an entry was changed by a client, and sometimes I want to know
when this machine learned of the change.

I'll have to think it through some more, but I think it could be a problem
having a single attribute that might be the last local login, or might be
the last network-wide login.  You either need to define a single attribute
and say it should always mean X, or define two attributes.  It would be a
reasonable optimization for a non-replicating server to keep one value but
know it by both names.

John  McMeeking

Jim Sermersheim wrote on 02/24/2005 11:05:25 AM:

> Sure, but I still don't want to define two attributes for the same
> state information. If replicating it seems appropriate, then
> defining it as not-DSA Specific is the right thing to do, but beyond
> that, it feels like an implementation issue as to whether and how
> quickly it's replicated.
>
>
> LDAP both define different types of Operational Attributes: DSA Specific
> > Regarding replication, I favor allowing implementations to solve their
> > 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
count.
> > > not been used for 6 months. Would either of these be appropriate for
the
in
> > 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,
aggregate
> > for a collection of servers. Then one can specify policies for each set
> > across the network. Sites that require total accountability could set a
to
> > avoid the overhead of maintaining centralized counts could set a policy

---

From: Howard Chu <[email-masked]>
Date: Thu, 24 Feb 2005 19:55:02 -0800

> when this machine learned of the change.

The X.500 "dontUseCopy" control (and presumably 
draft-zeilenga-ldap-dontusecopy) would answer that need, if 
modifyTimestamp was always locally generated. But that solution doesn't 
solve the problem for last login time...

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support