Author |
Topic: LDAP Password Policy -- draft-behera-ldap-password-policy-10.txt |
|
SteveHB member offline |
|
posts: |
113 |
joined: |
05/31/2006 |
from: |
Mountain View, CA |
|
|
|
|
|
LDAP Password Policy -- draft-behera-ldap-password-policy-10.txt |
http://tools.ietf.org/html/draft-behera-ldap-password-policy-10
Password policy as described in this document is a set of rules that controls how passwords are used and administered in Lightweight Directory Access Protocol (LDAP) based directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and to deter password guessing attacks.
The older version of Password Policy can be found as below:
http://tools.ietf.org/html/draft-vchu-ldap-pwd-policy-00
where Netscape LDAP Password Policy Controls PasswordExpiredControl(OID:2.16.840.1.113730.3.4.4), and PasswordExpiringControl(OID:2.16.840.1.113730.3.4.5) are specified.
|
|
|
|
|
|
|
SteveHB member offline |
|
posts: |
113 |
joined: |
05/31/2006 |
from: |
Mountain View, CA |
|
|
|
|
|
Request Control |
This control MAY be sent with any LDAP request message (not just bindRequest) in order to convey to the server that this client is aware of, and can process the response control described in this document. When a server receives this control, it will return the response control when appropriate and with the proper data.
The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 The criticality may be TRUE or FALSE There is no controlValue
|
|
|
|
|
|
|
SteveHB member offline |
|
posts: |
113 |
joined: |
05/31/2006 |
from: |
Mountain View, CA |
|
|
|
|
|
Response Control |
If the client has sent a passwordPolicyRequest control, the server (when solicited by the inclusion of the request control) sends this control with the following operation responses: bindResponse, modifyResponse, addResponse, compareResponse and possibly extendedResponse, to inform of various conditions, and MAY be sent with other operations (in the case of the changeAfterReset error). The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 The criticality can be either TRUE or FALSE The controlValue is the BER encoding of the following type:
PasswordPolicyResponseValue ::= SEQUENCE {
warning [0] CHOICE {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
error [1] ENUMERATED {
passwordExpired (0),
accountLocked (1),
changeAfterReset (2),
passwordModNotAllowed (3),
mustSupplyOldPassword (4),
insufficientPasswordQuality (5),
passwordTooShort (6),
passwordTooYoung (7),
passwordInHistory (8) } OPTIONAL }
timeBeforeExpiration warning specifies the number of seconds before a password will expire. graceAuthNsRemaining warning specifies the remaining number of times a user will be allowed to authenticate with an expired password. passwordExpired error signifies that the password has expired and must be reset. changeAfterReset error signifies that the password must be changed before the user will be allowed to perform any operation other than bind and modify. passwordModNotAllowed error is set when a user is restricted from changing her password. insufficientPasswordQuality error is set when a password doesn't pass quality checking. passwordTooYoung error is set if the age of the password to be modified is not yet old enough.
Typically, only either a warning or an error will be encoded though there may be exceptions. For example, if the user is required to change a password after the password administrator set it, and the password will expire in a short amount of time, the control may include the timeBeforeExpiration warning and the changeAfterReset error.
|
|
|
|
|
|
|
SteveHB member offline |
|
posts: |
113 |
joined: |
05/31/2006 |
from: |
Mountain View, CA |
|
|
|
|
|
Client-Server Interaction -- Bind Operation |
(As in SunOne Directory or OpenDS)
Action #1 Client send bindRequest (wrong password) with NO control
Client: server:
bindRequest.name: <bindDn> -->
bindRequest.credential: <wrong password and expired>
pwdPolicyRequestControl: none
<== bindResponse.resultCode: 49
bindResponse.errorMessage: Invalid Credentials
PasswordExpiredControl: 2.16.840.1.113730.3.4.4
Action #2 Client send bindRequest (expired password) with NO control
Client: server:
bindRequest.name: <bindDn> -->
bindRequest.credential: <correct password but expired>
pwdPolicyRequestControl: none
<== bindResponse.resultCode: 49
bindResponse.errorMessage: Password has expired
PasswordExpiredControl: 2.16.840.1.113730.3.4.4
Action #3 Client send bindRequest (wrong password) with control
Client: server:
bindRequest.name: <bindDn> -->
bindRequest.credential: <wrong password and expired>
pwdPolicyRequestControl: 1.3.6.1.4.1.42.2.27.8.5.1
<== bindResponse.resultCode: 49
bindResponse.errorMessage: Invalid Credentials
PasswordPolicyResponseControl: 1.3.6.1.4.1.42.2.27.8.5.1
Action #4 Client send bindRequest (expired password) with control
Client: server:
bindRequest.name: <bindDn> -->
bindRequest.credential: <correct password but expired>
pwdPolicyRequestControl: 1.3.6.1.4.1.42.2.27.8.5.1
<== bindResponse.resultCode: 49
bindResponse.errorMessage: Password has expired
PasswordPolicyResponseControl: 1.3.6.1.4.1.42.2.27.8.5.1
|
|
|
|
|
|
|
|