Subject: [ldapext] Re: draft-behera-ldap-password-policy-07.txt

From: "Howard Chu" <[email-masked]>
Date: Mon, 15 Mar 2004 17:06:27 -0800

> -----Original Message-----
> >Section 4.3.3, 6.1.1
> >A 0 value for generalizedTime is mentioned. This is
> >impossible as 0 is not a valid value.
> >We use 0000010100Z.

> Nice catch. We use 000001010000Z which is another
> representation of the same value.
> I'll change the wording to specific the generalizedTime 1st
> of Jan 0000, 00h00mn and give a representation of the value.

While testing our implementation for OpenLDAP I tripped over a minor
problem - if multiple Bind requests for a user are made in rapid succession,
there may not be fine enough resolution in the timestamps to distinguish each
attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime (for
expired password) attributes will not have an accurate count because the
server refuses to store duplicate values in an attribute.

It seems that, audit aspects aside, these attributes would be more useful as
single-valued integer counters instead of a list of timestamps.

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

---

From: Mark Ennis <[email-masked]>
Date: Wed, 17 Mar 2004 10:58:05 +1100

We ran into a similar problem when implementing X.500 replication 
protocols. Our solution was to increase the resolution of the timestamps 
we generate to millisecond resolution. This solved immediate problems 
and, as machines speed up, we can increase the resolution as required. I 
am not aware of any limit on the resolution of fractional seconds which 
can be represented in the GeneralizedTime representation.

The pwdFailureTime can be used to identify how many failed logins 
occurred in a particular period of time, replacing it with a counter 
will be an insufficient alternative.

- Mark.