{"id":427,"date":"2012-03-05T22:15:28","date_gmt":"2012-03-05T14:15:28","guid":{"rendered":"http:\/\/cowman-chiang.no-ip.org\/wordpress\/?p=427"},"modified":"2023-10-31T15:52:05","modified_gmt":"2023-10-31T07:52:05","slug":"man-slapo_ppolicy","status":"publish","type":"post","link":"https:\/\/cowmanchiang.me\/wp\/?p=427","title":{"rendered":"man slapo_ppolicy"},"content":{"rendered":"<p>SLAPO_PPOLICY(5)                                              SLAPO_PPOLICY(5)<!--more--><\/p>\n<p>NAME<br \/>\n       slapo-ppolicy &#8211; Password Policy overlay to slapd<\/p>\n<p>SYNOPSIS<br \/>\n       \/etc\/openldap\/slapd.conf<\/p>\n<p>DESCRIPTION<br \/>\n       The  ppolicy  overlay  is  an  implementation  of  the most recent IETF Password Policy proposal for LDAP.   When<br \/>\n       instantiated, it intercepts, decodes and applies specific password policy controls to overall use  of  a  backend<br \/>\n       database, changes to user password fields, etc.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">   The  overlay  provides a variety of password control mechanisms.  They include password aging -- both minimum and\n   maximum ages, password reuse and duplication control, account time-outs, mandatory  password  resets,  acceptable\n   password  content,  and  even  grace logins.  Different groups of users may be associated with different password\n   policies, and there is no limit to the number of password policies that may be created.\n\n   Note that some of the policies do not take effect when the operation is performed with the rootdn  identity;  all\n   the operations, when performed with any other identity, may be subjected to constraints, like access control.\n\n   Note  that  the  IETF  Password  Policy  proposal  for LDAP makes sense when considering a single-valued password\n   attribute, while the userPassword attribute allows multiple values.  This implementation enforces a single  value\n   for the userPassword attribute, despite its specification.<\/pre>\n<p>CONFIGURATION<br \/>\n       These  slapd.conf configuration options apply to the ppolicy overlay. They should appear after the overlay direc-<br \/>\n       tive.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">   &lt;strong&gt;ppolicy_default &lt;policyDN&gt;&lt;\/strong&gt;\n          Specify the DN of the pwdPolicy object to use when no specific policy is set on a given user\u2019s  entry.  If\n          there is no specific policy for an entry and no default is given, then no policies will be enforced.\n\n   ppolicy_forward_updates\n          Specify  that  policy state changes that result from Bind operations (such as recording failures, lockout,\n          etc.) on a consumer should be forwarded to a master instead of being written directly into the  consumer\u2019s\n          local  database.  This  setting  is only useful on a replication consumer, and also requires the updateref\n          setting and chain overlay to be appropriately configured.\n\n   ppolicy_hash_cleartext\n          Specify that cleartext passwords present in Add and Modify requests should be hashed before  being  stored\n          in  the database. This violates the X.500\/LDAP information model, but may be needed to compensate for LDAP\n          clients that don\u2019t use the Password Modify extended operation to manage passwords.  It is recommended that\n          when this option is used that compare, search, and read access be denied to all directory users.\n\n   ppolicy_use_lockout\n          A  client  will  always  receive  an LDAP InvalidCredentials response when Binding to a locked account. By\n          default, when a Password Policy control was provided on the Bind request, a Password Policy response  will\n          be  included  with  no special error code set. This option changes the Password Policy response to include\n          the AccountLocked error code. Note that sending the AccountLocked error code provides  useful  information\n          to an attacker; sites that are sensitive to security issues should not enable this option.<\/pre>\n<p>OBJECT CLASS<br \/>\n       The ppolicy overlay depends on the pwdPolicy object class.  The definition of that class is as follows:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">       (  1.3.6.1.4.1.42.2.27.8.2.1\n           NAME \u2019pwdPolicy\u2019\n           AUXILIARY\n           SUP top\n           MUST ( pwdAttribute )\n           MAY (\n               pwdMinAge $ pwdMaxAge $ pwdInHistory $\n               pwdCheckQuality $ pwdMinLength $\n               pwdExpireWarning $ pwdGraceAuthnLimit $\n               pwdLockout $ pwdLockoutDuration $\n               pwdMaxFailure $ pwdFailureCountInterval $\n               pwdMustChange $ pwdAllowUserChange $\n               pwdSafeModify ) )\n\n   This  implementation also provides an additional pwdPolicyChecker objectclass, used for password quality checking\n   (see below).\n\n       (  1.3.6.1.4.1.4754.2.99.1\n           NAME \u2019pwdPolicyChecker\u2019\n           AUXILIARY\n           SUP top\n           MAY ( pwdCheckModule ) )\n\n   Every account that should be subject to password policy control should have a  pwdPolicySubentry  attribute  con-\n   taining  the DN of a valid pwdPolicy entry, or they can simply use the configured default.  In this way different\n   users may be managed according to different policies.<\/pre>\n<p>OBJECT CLASS ATTRIBUTES<br \/>\n       Each one of the sections below details the meaning and use of a particular attribute  of  this  pwdPolicy  object<br \/>\n       class.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">   &lt;strong&gt;pwdAttribute&lt;\/strong&gt;\n\n   This attribute contains the name of the attribute to which the password policy is applied. For example, the pass-\n   word policy may be applied to the userPassword attribute.\n\n   Note: in this implementation, the only value accepted for pwdAttribute is  userPassword .\n\n       (  1.3.6.1.4.1.42.2.27.8.1.1\n          NAME \u2019pwdAttribute\u2019\n          EQUALITY objectIdentifierMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )\n\n   &lt;strong&gt;pwdMinAge&lt;\/strong&gt;\n\n   This attribute contains &lt;strong&gt;the number of seconds that must elapse between modifications allowed to the password.&lt;\/strong&gt;  If\n   this  attribute  is  not present, zero seconds is assumed (i.e. the password may be modified whenever and however\n   often is desired).\n\n       (  1.3.6.1.4.1.42.2.27.8.1.2\n          NAME \u2019pwdMinAge\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdMaxAge&lt;\/strong&gt;\n\n   This attribute contains &lt;strong&gt;the number of seconds after which a modified password will expire.&lt;\/strong&gt;  If this attribute  is\n   not present, or if its value is zero (0), then passwords will not expire.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.3\n          NAME \u2019pwdMaxAge\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdInHistory&lt;\/strong&gt;\n\n   This  attribute  is  used  &lt;strong&gt;to  specify the maximum number of used passwords that will be stored in the pwdHistory\n   attribute.&lt;\/strong&gt;  If the pwdInHistory attribute is not present, or if its value is zero (0), used passwords will not be\n   stored  in  pwdHistory  and  thus  any previously-used password may be reused.  No history checking occurs if the\n   password is being modified by the rootdn, although the password is saved in the history.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.4\n          NAME \u2019pwdInHistory\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdCheckQuality&lt;\/strong&gt;\n\n   This attribute indicates if and how password syntax &lt;strong&gt;will be checked while a password is being modified or  added.\n   If  this attribute is not present, or its value is zero (0), no syntax checking will be done. If its value is one\n   (1), the server will check the syntax, and if the server is unable to check the syntax, whether due to a  client-\n   side  hashed  password  or some other reason, it will be accepted. If its value is two (2), the server will check\n   the syntax, and if the server is unable to check the syntax it will return an error refusing the password.&lt;\/strong&gt;\n\n       (  1.3.6.1.4.1.42.2.27.8.1.5\n          NAME \u2019pwdCheckQuality\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdMinLength&lt;\/strong&gt;\n\n   When syntax checking is enabled (see also the pwdCheckQuality attribute), this  attribute  contains  &lt;strong&gt;the  minimum\n   number  of  characters  that  will  be accepted in a password.&lt;\/strong&gt; If this attribute is not present, minimum password\n   length is not enforced. If the server is unable to check the length of the password, whether due to a client-side\n   hashed  password  or some other reason, the server will, depending on the value of pwdCheckQuality, either accept\n   the password without checking it (if pwdCheckQuality is zero (0) or one (1)) or refuse it (if pwdCheckQuality  is\n   two (2)).\n\n       (  1.3.6.1.4.1.42.2.27.8.1.6\n          NAME \u2019pwdMinLength\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdExpireWarning&lt;\/strong&gt;\n\n   This  attribute contains &lt;strong&gt;the maximum number of seconds before a password is due to expire that expiration warning\n   messages will be returned to a user who is authenticating to the directory.&lt;\/strong&gt;  If this attribute is not present, or\n   if the value is zero (0), no warnings will be sent.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.7\n          NAME \u2019pwdExpireWarning\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   pwdGraceAuthnLimit\n\n   This  attribute  contains  the number of times that an expired password may be used to authenticate a user to the\n   directory. If this attribute is not present or if its value is zero (0), users with expired passwords will not be\n   allowed to authenticate to the directory.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.8\n          NAME \u2019pwdGraceAuthnLimit\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdLockout&lt;\/strong&gt;\n\n   This attribute specifies the action that should be taken by the directory when a user has made a number of failed\n   attempts to authenticate to the directory.  If pwdLockout is set (its value is &quot;TRUE&quot;),  the  user  will  not  be\n   allowed  to  attempt  to  authenticate  to  the directory after there have been a specified number of consecutive\n   failed bind attempts.  The maximum number of consecutive failed bind attempts allowed is specified by the pwdMax-\n   Failure attribute.  If pwdLockout is not present, or if its value is &quot;FALSE&quot;, the password may be used to authen-\n   ticate no matter how many consecutive failed bind attempts have been made.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.9\n          NAME \u2019pwdLockout\u2019\n          EQUALITY booleanMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.7\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdLockoutDuration&lt;\/strong&gt;\n\n   This attribute contains the number of seconds during which the password cannot be used to authenticate  the  user\n   to  the directory due to too many consecutive failed bind attempts.  (See also pwdLockout and pwdMaxFailure.)  If\n   pwdLockoutDuration is not present, or if its value is zero (0), the password cannot be used to  authenticate  the\n   user to the directory again until it is reset by an administrator.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.10\n          NAME \u2019pwdLockoutDuration\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   pwdMaxFailure\n\n   This  attribute  contains the number of consecutive failed bind attempts after which the password may not be used\n   to authenticate a user to the directory.  If pwdMaxFailure is not present, or its value is zero (0), then a  user\n   will  be  allowed  to continue to attempt to authenticate to the directory, no matter how many consecutive failed\n   bind attempts have occurred with that user\u2019s DN.  (See also pwdLockout and pwdLockoutDuration.)\n\n       (  1.3.6.1.4.1.42.2.27.8.1.11\n          NAME \u2019pwdMaxFailure\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   pwdFailureCountInterval\n\n   This attribute contains the number of seconds after which old consecutive failed bind attempts  are  purged  from\n   the  failure  counter,  even though no successful authentication has occurred.  If pwdFailureCountInterval is not\n   present, or its value is zero (0), the failure counter will only be reset by a successful authentication.\n       (  1.3.6.1.4.1.42.2.27.8.1.12\n          NAME \u2019pwdFailureCountInterval\u2019\n          EQUALITY integerMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdMustChange&lt;\/strong&gt;\n\n   This attribute specifies whether users must change their passwords when they first bind to the directory after  a\n   password is set or reset by the administrator, or not.  If pwdMustChange has a value of &quot;TRUE&quot;, users must change\n   their passwords when they first bind to the directory after a password is set or reset by the administrator.   If\n   pwdMustChange is not present, or its value is &quot;FALSE&quot;, users are not required to change their password upon bind-\n   ing after the administrator sets or resets the password.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.13\n         NAME \u2019pwdMustChange\u2019\n         EQUALITY booleanMatch\n         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7\n         SINGLE-VALUE )\n\n   &lt;strong&gt;pwdAllowUserChange&lt;\/strong&gt;\n\n   This attribute specifies whether users are &lt;strong&gt;allowed to change their own passwords or not.&lt;\/strong&gt;   If  pwdAllowUserChange\n   is  set  to  &quot;TRUE&quot;, or if the attribute is not present, users will be allowed to change their own passwords.  If\n   its value is &quot;FALSE&quot;, users will not be allowed to change their own passwords.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.14\n          NAME \u2019pwdAllowUserChange\u2019\n          EQUALITY booleanMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.7\n          SINGLE-VALUE )\n\n   &lt;strong&gt;pwdSafeModify&lt;\/strong&gt;\n\n   This attribute denotes whether&lt;strong&gt; the user\u2019s existing password must be sent  along  with  their  new  password  when\n   changing  a  password.&lt;\/strong&gt;   If pwdSafeModify is set to &quot;TRUE&quot;, the existing password must be sent along with the new\n   password.  If the attribute is not present, or its value is &quot;FALSE&quot;, the existing password need not be sent along\n   with the new password.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.15\n          NAME \u2019pwdSafeModify\u2019\n          EQUALITY booleanMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.7\n          SINGLE-VALUE )\n\n   pwdCheckModule\n\n   This  attribute  names  a user-defined loadable module that must instantiate the check_password() function.  This\n   function will be called to further check a new password if pwdCheckQuality is set to one (1) or  two  (2),  after\n   all  of the built-in password compliance checks have been passed.  This function will be called according to this\n   function prototype:\n       int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry);\n   The pPasswd parameter contains the clear-text user password, the ppErrStr parameter  contains  a  double  pointer\n   that  allows  the  function  to return human-readable details about any error it encounters.  The optional pEntry\n   parameter, if non-NULL, carries a pointer to the entry whose password is being checked.   If  ppErrStr  is  NULL,\n   then funcName must NOT attempt to use it\/them.  A return value of LDAP_SUCCESS from the called function indicates\n   that the password is ok, any other value indicates that the password is unacceptable.  If the password  is  unac-\n   ceptable, the server will return an error to the client, and ppErrStr may be used to return a human-readable tex-\n   tual explanation of the error. The error string must be dynamically allocated as it will be free()\u2019d by slapd.\n\n       (  1.3.6.1.4.1.4754.1.99.1\n          NAME \u2019pwdCheckModule\u2019\n          EQUALITY caseExactIA5Match\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26\n          SINGLE-VALUE )\n\n   Note: The user-defined loadable module named by pwdCheckModule must be  in  slapd\u2019s  standard  executable  search\n   PATH.\n\n   Note: pwdCheckModule is a non-standard extension to the LDAP password policy proposal.<\/pre>\n<p>OPERATIONAL ATTRIBUTES<br \/>\n       The  operational  attributes used by the ppolicy module are stored in the user\u2019s entry.  Most of these attributes<br \/>\n       are not intended to be changed directly by users; they are there to track user activity.  They have been detailed<br \/>\n       here so that administrators and users can both understand the workings of the ppolicy module.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">   Note that the current IETF Password Policy proposal does not define how these operational attributes are expected\n   to behave in a replication environment. In general, authentication attempts on a slave  server  only  affect  the\n   copy  of  the  operational  attributes on that slave and will not affect any attributes for a user\u2019s entry on the\n   master server. Operational attribute changes resulting from authentication attempts on a master server will  usu-\n   ally  replicate to the slaves (and also overwrite any changes that originated on the slave).  These behaviors are\n   not guaranteed and are subject to change when a formal specification emerges.\n\n   userPassword\n\n   The userPassword attribute is not strictly part of the ppolicy module.  It is, however,  the  attribute  that  is\n   tracked and controlled by the module.  Please refer to the standard OpenLDAP schema for its definition.\n\n   pwdPolicySubentry\n\n   This  attribute  refers directly to the pwdPolicy subentry that is to be used for this particular directory user.\n   If pwdPolicySubentry exists, it must contain the DN of a valid pwdPolicy object.  If it does not exist, the ppol-\n   icy  module will enforce the default password policy rules on the user associated with this authenticating DN. If\n   there is no default, or the referenced subentry does not exist, then no policy rules will be enforced.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.23\n          NAME \u2019pwdPolicySubentry\u2019\n          DESC \u2019The pwdPolicy subentry in effect for\n              this object\u2019\n          EQUALITY distinguishedNameMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.12\n          SINGLE-VALUE\n          NO-USER-MODIFICATION\n          USAGE directoryOperation)\n\n   pwdChangedTime\n\n   This attribute denotes the last time that the entry\u2019s password was changed.  This value is used by  the  password\n   expiration  policy to determine whether the password is too old to be allowed to be used for user authentication.\n   If pwdChangedTime does not exist, the user\u2019s password will not expire.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.16\n          NAME \u2019pwdChangedTime\u2019\n          DESC \u2019The time the password was last changed\u2019\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24\n          EQUALITY generalizedTimeMatch\n          ORDERING generalizedTimeOrderingMatch\n          SINGLE-VALUE\n          NO-USER-MODIFICATION\n          USAGE directoryOperation)\n\n   pwdAccountLockedTime\n\n   This attribute contains the time that the user\u2019s account was locked.  If the account has been locked,  the  pass-\n   word  may  no  longer  be  used  to  authenticate  the  user to the directory.  If pwdAccountLockedTime is set to\n   000001010000Z, the user\u2019s account has been permanently locked and may only be unlocked by an administrator.  Note\n   that account locking only takes effect when the pwdLockout password policy attribute is set to &quot;TRUE&quot;.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.17\n          NAME \u2019pwdAccountLockedTime\u2019\n          DESC \u2019The time an user account was locked\u2019\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24\n          EQUALITY generalizedTimeMatch\n          ORDERING generalizedTimeOrderingMatch\n          SINGLE-VALUE\n          NO-USER-MODIFICATION\n          USAGE directoryOperation)\n\n   pwdFailureTime\n\n   This  attribute  contains  the  timestamps of each of the consecutive authentication failures made upon attempted\n   authentication to this DN (i.e. account).  If too many timestamps accumulate here  (refer  to  the  pwdMaxFailure\n   password  policy  attribute  for  details),  and  the  pwdLockout password policy attribute is set to &quot;TRUE&quot;, the\n   account may be locked.  (Please also refer to the  pwdLockout  password  policy  attribute.)   Excess  timestamps\n   beyond  those  allowed  by  pwdMaxFailure  may also be purged.  If a successful authentication is made to this DN\n   (i.e. to this user account), then pwdFailureTime will be cleansed of entries.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.19\n          NAME \u2019pwdFailureTime\u2019\n          DESC \u2019The timestamps of the last consecutive\n              authentication failures\u2019\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24\n          EQUALITY generalizedTimeMatch\n          ORDERING generalizedTimeOrderingMatch\n          NO-USER-MODIFICATION\n          USAGE directoryOperation )\n\n   &lt;strong&gt;pwdHistory&lt;\/strong&gt;\n\n   This attribute contains the history of previously used passwords for this DN (i.e. for this user  account).   The\n   values of this attribute are stored in string format as follows:\n\n       pwdHistory=\n           time &quot;#&quot; syntaxOID &quot;#&quot; length &quot;#&quot; data\n\n       time=\n           GeneralizedTime as specified in section 3.3.13 of [RFC4517]\n\n       syntaxOID = numericoid\n           This  is  the  string  representation of the dotted-decimal OID that defines the syntax used to store the\n           password.  numericoid is described in section 1.4 of [RFC4512].\n\n       length = NumericString\n           The number of octets in the data.  NumericString is described in section 3.3.23 of [RFC4517].\n\n       data =\n           Octets representing the password in the format specified by syntaxOID.\n\n   This format allows the server to store and transmit a history of passwords that have been  used.   In  order  for\n   equality matching on the values in this attribute to function properly, the time field is in GMT format.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.20\n          NAME \u2019pwdHistory\u2019\n          DESC \u2019The history of user passwords\u2019\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40\n          EQUALITY octetStringMatch\n          NO-USER-MODIFICATION\n          USAGE directoryOperation)\n\n   pwdGraceUseTime  This  attribute contains the list of timestamps of logins made after the user password in the DN\n   has expired.  These post-expiration logins are known as &quot;grace logins&quot;.  If too many grace logins have been  used\n   (please  refer  to the pwdGraceLoginLimit password policy attribute), then the DN will no longer be allowed to be\n   used to authenticate the user to the directory until the administrator changes the DN\u2019s userPassword attribute.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.21\n          NAME \u2019pwdGraceUseTime\u2019\n          DESC \u2019The timestamps of the grace login once the password has expired\u2019\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24\n          EQUALITY generalizedTimeMatch\n          NO-USER-MODIFICATION\n          USAGE directoryOperation)\n\n   pwdReset\n\n   This attribute indicates whether the user\u2019s password has been reset by the administrator and thus must be changed\n   upon  first  use of this DN for authentication to the directory.  If pwdReset is set to &quot;TRUE&quot;, then the password\n   was reset and the user must change it upon first authentication.  If the attribute does not exist, or is  set  to\n   &quot;FALSE&quot;, the user need not change their password due to administrative reset.\n\n       (  1.3.6.1.4.1.42.2.27.8.1.22\n          NAME \u2019pwdReset\u2019\n          DESC \u2019The indication that the password has\n              been reset\u2019\n          EQUALITY booleanMatch\n          SYNTAX 1.3.6.1.4.1.1466.115.121.1.7\n          SINGLE-VALUE\n          USAGE directoryOperation)<\/pre>\n<p>EXAMPLES<br \/>\n              database bdb<br \/>\n              suffix dc=example,dc=com<br \/>\n              &#8230;<br \/>\n              overlay ppolicy<br \/>\n              ppolicy_default &#8220;cn=Standard,ou=Policies,dc=example,dc=com&#8221;<\/p>\n<p>SEE ALSO<br \/>\n       ldap(3), slapd.conf(5), slapd-config(5), slapo-chain(5).<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">   &quot;OpenLDAP Administrator\u2019s Guide&quot; (http:\/\/www.OpenLDAP.org\/doc\/admin\/)\n\n   IETF  LDAP  password  policy  proposal by P. Behera, L.  Poitou and J.  Sermersheim:  documented in IETF document\n   &quot;draft-behera-ldap-password-policy-09.txt&quot;.<\/pre>\n<p>BUGS<br \/>\n       The LDAP Password Policy specification is not yet an approved standard, and it is still evolving. This code  will<br \/>\n       continue to be in flux until the specification is finalized.<\/p>\n<p>ACKNOWLEDGEMENTS<br \/>\n       This  module  was  written in 2004 by Howard Chu of Symas Corporation with significant input from Neil Dunbar and<br \/>\n       Kartik Subbarao of Hewlett-Packard.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"\">   This manual page borrows heavily and shamelessly from the specification upon which the password policy module  it\n   describes  is based.  This source is the IETF LDAP password policy proposal by P. Behera, L.  Poitou and J. Serm-\n   ersheim.  The proposal is fully documented in the IETF document  named  draft-behera-ldap-password-policy-09.txt,\n   written in July of 2005.\n\n   OpenLDAP Software is developed and maintained by The OpenLDAP Project &lt;http:\/\/www.openldap.org\/&gt;.  OpenLDAP Soft-\n   ware is derived from University of Michigan LDAP 3.3 Release.<\/pre>\n<p>OpenLDAP 2.4.23                   2010\/06\/30                  SLAPO_PPOLICY(5)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>SLAPO_PPOLICY(5) SLAPO_PPOLICY(5)<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[68],"tags":[],"class_list":["post-427","post","type-post","status-publish","format-standard","hentry","category-openldap"],"_links":{"self":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts\/427","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=427"}],"version-history":[{"count":1,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts\/427\/revisions"}],"predecessor-version":[{"id":2146,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts\/427\/revisions\/2146"}],"wp:attachment":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=427"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=427"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=427"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}