Re: [ldapext] [x500standard] Password policy PDAM

[Howard Chu <hyc@highlandsun.com>]

Howard Chu wrote:
> I'll followup later with another review in terms of the current LDAP ppolicy
> draft.

As David Chadwick suggested, it would be a good idea to align the names and 
OIDs of the policy elements that are semantically the same. Here's a 
comparison of where things stand right now.

X.500			LDAP
pwdAdminSubentryList/
pwdPolicySubentry	pwdPolicySubentry

   The LDAP definition is single-valued; only one policy is allowed to apply
   to the password attribute of an entry. (But if multiple password
   attributes are in use, then each can have its own policy.) In LDAP if
   multiple policies have overlapping coverage the behavior is undefined.

pwdAdminSubentry	pwdPolicy

myPwdAttribute		pwdAttribute

passwordHistory		pwdHistory

   Currently it looks like these two are not compatible.

recentlyExpiredPassword

   No analogue in LDAP spec. Could be added I guess.

passwordHistoryMatch

   No analogue in LDAP, history just uses octetStringMatch.

pwdStartTime		pwdStartTime

   Basically the same, but X.500 pwdStartTime is also set whenever a
   password is changed. LDAP uses pwdChangedTime for this purpose. The
   reason for the distinction: an admin may decide to set a password
   on an account, but leave it disabled until some time in the future.

   The most common example use-case is in schools/universities - hundreds
   or thousands of accounts may be created in advance for an incoming
   class of students. Their pwdStartTime will be set to the first day of
   class, while their pwdChangedTime will reflect the time their password
   was actually created.

pwdExpiryTime

   No analogue in LDAP. Could be added.

pwdEndTime		pwdEndTime
	
   Basically the same. We should adopt the X.500 description for the
   LDAP spec.

pwdFails

   LDAP uses pwdFailureTime which records the timestamps of the failures,
   not just a count of the failures.

gracesUsed

   LDAP uses pwdGraceUseTime which records the timestamps of each
   usage, not just a count.

The LDAP spec has 3 more operational attributes that appear to be missing from 
the X.500 spec:
	pwdAccountLockedTime - the time that an account was locked.
	pwdReset - a boolean that indicates a user must change their password (e.g. 
because it was set by an administrator).
	pwdLastSuccess - the timestamp of the last successful authentication


Policy schema:

X.500			LDAP

modifyEntryPwdAllowed

    No analogue in LDAP

changePwdAllowed	pwdAllowUserChange

    Basically the same

pwdMaxAge

    Missing in LDAP. Adding it will be tricky since we already use a 
pwdMaxAge attribute, for expiration.

pwdExpiryAge		pwdMaxAge

    Basically the same meaning; LDAP is missing the ordering rule.

minPwdLength		pwdMinLength

    Basically the same. LDAP also has pwdMaxLength, as some systems only work
    with some small length (e.g. 8 or 16 on some legacy platforms).

pwdVocabulary
pwdAlphabet
pwdDictionaries

    Missing in LDAP. Should consider adding them.

pwdExpiryWarning	pwdExpireWarning
pwdGraces		pwdGraceAuthNLimit
pwdLockoutDuration	pwdLockoutDuration
pwdMaxFailures		pwdMaxFailure

    Basically the same, besides choice of spelling. LDAP is missing the
    ordering rule.

pwdFailureDuration	pwdMinDelay

    LDAP also requires pwdMaxDelay if pwdMinDelay is set.

pwdMaxTimeInHistory
pwdMinTimeInHistory

    No analogue in LDAP, should consider adding it.

pwdHistorySlots		pwdInHistory

    Similar; LDAP doesn't specify a minimum value. Absence / 0 implies no
    history tracking.

recentlyExpiredPwdDuration

    No analogue in LDAP.

pwdEncryptionAlg

    No analogue in LDAP. Password hashing is implementation-specific.

The LDAP spec also defines pwdMinAge, pwdCheckQuality, pwdGraceExpiry,
pwdLockout, pwdFailureCountInterval, pwdMustChange, pwdSafeModify, pwdMaxIdle.

Kurt Zeilenga's draft makes an argument against using pwdMinAge, we should 
consider dropping it from the LDAP spec and augmenting the history policy 
attributes instead. pwdCheckQuality would be superseded by pwdVocabulary,
pwdAlphabet and pwdDictionaries.

pwdGraceExpiry should probably be added to the X.500 spec; i.e. there should 
be some provision for aging out grace logins.

pwdLockout simply controls whether failure-based lockouts will be enforced or not.

pwdFailureCountInterval defines the number of seconds after which password
failures are automatically purged, even though no successful authentication
occurred. It's a bit of a bandaid to allow recovering from a failure lockout.

pwdMustChange controls whether administrative password changes will require 
the user to change their password immediately on next login.

pwdSafeModify controls whether the old password is required or not in a 
PasswordModify operation.

pwdMaxIdle disables an account if it has not been logged into within the 
specified interval. It may be a good idea to add this to the X.500 spec.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext