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

[ldapext] password policy: pwdChangedTIme, pwdLastSuccess



Section 7.1 says:

   o  The current time is greater than or equal to the value of the
      pwdLastSuccess attribute added to the value of the pwdMaxIdle
      attribute.

but pwdLastSuccess may not exist as the user might never have successfully authenticated.

I would suggest,

   o  If pwdLastSuccess attribute exists, the current time is greater than or equal to the
      value of the pwdLastSuccess attribute added to the value of the pwdMaxIdle
      attribute.  
   o  Otherwise, the current time is greater than or equal to the
      value of the pwdChangedTime attribute added to the value of the pwdMaxIdle
      attribute.

But, of course, pwdChangedTime might not exist.

First, if one has an governing password policy, I think both pwdLastSuccess and pwdChangedTime MUST always be maintained.  This allows, for instance, a pwdMaxIdle or pwdMaxAge restriction to be establish subsequently to the initial policy being set.

Second, the specification should detail what should happen if a particular state attribute is missing.  For instance, even if the above MUST was in place, one still the issue of handling an initial policy with pwdMaxIdle and pwdMaxAge yet neither of these state attributes yet present.

If both attribute are absent, I suggest using createTimestamp of the password policy subentry as substitute.   That is, in absence of these state attributes, an account would not be idled until the policy was pwdMaxIdle old, and password not be aged until the policy was pwdMaxAge old.

(pwdMinAge has a similar problem, but here I recommend axing pwdMinAge as it's a really bad idea to begin with.)

-- Kurt

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