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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 24 Feb 2005 19:48:23 -0700

If the use case is that one needs to differentiate between local last
login time, and global last login time, I agree, two attributes would be
appropriate.
 
But if the use case is that some deployments might prefer no
replication, and others might prefer loosely or tightly consistent
replication, then I think a single attribute is appropriate. Otherwise,
one has to wonder how many attributes being defined (not just in this
I-D) fall into the same use case and should also have semi-duplicates
defined.
 
Jim

>>> John McMeeking <[email-masked]> 2/24/05 6:47:37 PM >>>

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

_______________________________________________
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: Howard Chu <[email-masked]>
Date: Thu, 24 Feb 2005 19:57:08 -0800

> I-D) fall into the same use case and should also have semi-duplicates 

That's a good point. Perhaps instead of a second set of attribute 
definitions, there should just be a subentry devoted to carrying the 
global state.

> I still think single directory first after all these years :-( So I hadn't
> I see the potential for the replication side of this becoming a significant
> 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
> 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
> 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
> 
> 
>  > >>> Ludovic Poitou <_ [email-masked] 
> <mailto:[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
>  > administrator) decide if it'll be replicated or not is actually messing
>  > > Regarding replication, I favor allowing implementations to solve their
>  > > own consistency problems. A highly usable implementation would allow
>  > > 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
>  > > >>> Howard Chu < [email-masked] <mailto:[email-masked]>_ 
>  > 2/23/05 9:11:53 PM >>>
>  > > John McMeeking wrote:
>  > >
>  > > > 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
>  > > 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,
>  > > 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
>  > > _http://www.symas.com < _http://www.symas.com/_ >_
>  > > [email-masked] <mailto:[email-masked]>_ < 
> _mailto:[email-masked] >_
>  > > [email-masked] <mailto:[email-masked]>_

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