[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

John McMeeking wrote:

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.

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

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 <Ludovic.Poitou@Sun.COM> 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 < hyc@highlandsun.com > 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
_Ldapext@ietf.org < mailto:Ldapext@ietf.org >_
_https://www1.ietf.org/mailman/listinfo/ldapext_

------------------------------------------------------------------------

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext




_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext



--
  -- 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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext