.\" $OpenLDAP$
-.\" Copyright 2004-2005 The OpenLDAP Foundation All Rights Reserved.
+.\" Copyright 2004-2008 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.TH SLAPO_PPOLICY 5 "RELEASEDATE" "OpenLDAP LDVERSION"
.SH NAME
-slapo-ppolicy \- Password Policy overlay
+slapo-ppolicy \- Password Policy overlay to slapd
.SH SYNOPSIS
ETCDIR/slapd.conf
.SH DESCRIPTION
Different groups of users may be associated with different password
policies, and there is no limit to the number of password policies
that may be created.
+.P
+Note that some of the policies do not take effect when the operation
+is performed with the
+.B rootdn
+identity; all the operations, when performed with any other identity,
+may be subjected to constraints, like access control.
+.P
+Note that the IETF Password Policy proposal for LDAP makes sense
+when considering a single-valued password attribute, while
+the userPassword attribute allows multiple values. This implementation
+enforces a single value for the userPassword attribute, despite
+its specification.
.SH CONFIGURATION
These
.TP
.B ppolicy_hash_cleartext
Specify that cleartext passwords present in Add and Modify requests should
-be hashed before being stored in the database. This violates the X.500
+be hashed before being stored in the database. This violates the X.500/LDAP
information model, but may be needed to compensate for LDAP clients that
-don't use the Password Modify exop to manage passwords.
+don't use the Password Modify extended operation to manage passwords. It
+is recommended that when this option is used that compare, search, and
+read access be denied to all directory users.
.TP
.B ppolicy_use_lockout
A client will always receive an LDAP
MUST ( pwdAttribute )
MAY (
pwdMinAge $ pwdMaxAge $ pwdInHistory $
- pwdCheckSyntax $ pwdMinLength $
+ pwdCheckQuality $ pwdMinLength $
pwdExpireWarning $ pwdGraceAuthnLimit $
pwdLockout $ pwdLockoutDuration $
pwdMaxFailure $ pwdFailureCountInterval $
value accepted for
.B pwdAttribute
is
-.RI " userPassword ".
+.IR " userPassword ".
.LP
.RS 4
( 1.3.6.1.4.1.42.2.27.8.1.1
zero (0), used passwords will not be stored in
.B pwdHistory
and thus any previously-used password may be reused.
+No history checking occurs if the password is being modified by the
+.BR rootdn ,
+although the password is saved in the history.
.LP
.RS 4
( 1.3.6.1.4.1.42.2.27.8.1.4
.P
When syntax checking is enabled
(see also the
-.B pwdCheckSyntax
+.B pwdCheckQuality
attribute), this attribute contains the minimum
number of characters that will be accepted in a password. If this
attribute is not present, minimum password length is not
whether due to a client-side hashed password or some other reason,
the server will, depending on the
value of
-.BR pwdCheckSyntax ,
+.BR pwdCheckQuality ,
either accept the password
without checking it (if
-.B pwdCheckSyntax
+.B pwdCheckQuality
is zero (0) or one (1)) or refuse it (if
-.B pwdCheckSyntax
+.B pwdCheckQuality
is two (2)).
.LP
.RS 4
.SH OPERATIONAL ATTRIBUTES
.P
The operational attributes used by the
-.B passwd_policy
+.B ppolicy
module are stored in the user's entry. Most of these attributes
are not intended to be changed directly by users; they are there
to track user activity. They have been detailed here so that
.B ppolicy
module.
+.P
+Note that the current IETF Password Policy proposal does not define
+how these operational attributes are expected to behave in a
+replication environment. In general, authentication attempts on
+a slave server only affect the copy of the operational attributes
+on that slave and will not affect any attributes for
+a user's entry on the master server. Operational attribute changes
+resulting from authentication attempts on a master server
+will usually replicate to the slaves (and also overwrite
+any changes that originated on the slave).
+These behaviors are not guaranteed and are subject to change
+when a formal specification emerges.
+
.B userPassword
.P
The
-.b userPassword
+.B userPassword
attribute is not strictly part of the
.B ppolicy
module. It is, however, the attribute that is tracked and controlled
If the account has been locked, the password may no longer be used to
authenticate the user to the directory. If
.B pwdAccountLockedTime
-is set to zero (0), the user's account has been permanently locked
+is set to 000001010000Z, the user's account has been permanently locked
and may only be unlocked by an administrator.
.LP
.RS 4
time=
.RS 4
-generalizedTimeString as specified in section 6.14 of [RFC2252]
+GeneralizedTime as specified in section 3.3.13 of [RFC4517]
.RE
.P
.RS 4
This is the string representation of the dotted-decimal OID that
defines the syntax used to store the password. numericoid is
-described in section 4.1 of [RFC2252].
+described in section 1.4 of [RFC4512].
.RE
-length = numericstring
+length = NumericString
.RS 4
-The number of octets in the data. numericstring is described in
-section 4.1 of [RFC2252].
+The number of octets in the data. NumericString is described in
+section 3.3.23 of [RFC4517].
.RE
data =
.B pwdGraceUseTime
This attribute contains the list of timestamps of logins made after
the user password in the DN has expired. These post-expiration
-logins are known as
-.RI " "grace logins" ."
+logins are known as "\fIgrace logins\fP".
If too many
.I grace logins
have been used (please refer to the
IETF document named draft-behera-ldap-password-policy-09.txt,
written in July of 2005.
.P
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
projects / openldap / blobdiff