Compartir a través de

3.1.1.3.1.5.1 unicodePwd

  • Artículo

Active Directory stores the password on a user object or inetOrgPerson object in the unicodePwd attribute. This attribute is written by an LDAP Modify under the following restricted conditions. Windows 2000 operating system servers require that the client have a 128-bit (or better) SSL/TLS-encrypted connection to the DC in order to modify this attribute. On Windows Server 2003 operating system and later, the DC also permits modification of the unicodePwd attribute on a connection protected by 128-bit (or better) Simple Authentication and Security Layer (SASL)-layer encryption instead of SSL/TLS. In Windows Server 2008 operating system and later, if the fAllowPasswordOperationsOverNonSecureConnection heuristic of the dSHeuristics attribute (section 6.1.1.2.4.1.2) is TRUE and Active Directory is operating as AD LDS, then the DC permits modification of the unicodePwd attribute over a connection that is neither SSL/TLS-encrypted nor SASL-encrypted. The unicodePwd attribute is never returned by an LDAP search.

When a DC receives an LDAP Modify request to modify this attribute, it follows the following procedure:

  • If the Modify request contains a delete operation containing a value Vdel for unicodePwd followed by an add operation containing a value Vadd for unicodePwd, the server considers the request to be a request to change the password. The server decodes Vadd and Vdel using the password decoding procedure documented later in this section. Vdel is the old password, while Vadd is the new password.

  • If the Modify request contains a single replace operation containing a value Vrep for unicodePwd, the server considers the request to be an administrative reset of the password, that is, a password modification without knowledge of the old password. The server decodes Vrep using the password decoding procedure documented later in this section and uses it as the new password.

For the password change operation to succeed, the server enforces the requirement that the user or inetOrgPerson object whose password is being changed MUST possess the "User-Change-Password" control access right on itself, and that Vdel MUST be the current password on the object. For the password reset to succeed, the server enforces the requirement that the client possess the "User-Force-Change-Password" control access right on the user or inetOrgPerson object whose password is to be reset.

The syntax of the unicodePwd attribute is Object(Replica-Link). However, the DC requires that the password value be specified in a UTF-16 encoded Unicode string containing the password surrounded by quotation marks, which has been BER-encoded as an octet string per the Object(Replica-Link) syntax. BER encoding and decoding is defined in [ITUX690]. To decode such a value V, the server follows this password decoding procedure:

  • If V is not a valid BER-encoding of an octet string, reject the password operation with the error protocolError / ERROR_DS_DECODING_ERROR.

  • BER-decode V to produce Vdecoded.

  • If the first and last characters of Vdecoded are not the UTF-16 Unicode representation of quotation marks, reject the password operation with the error constraintViolation/ ERROR_DS_UNICODEPWD_NOT_IN_QUOTES.

  • Remove the first and last characters from Vdecoded to produce Vpassword.

Vpassword is the value the DC uses for the password—the actual password, not a password hash. This encoding is used for both the old and the new passwords in a password change request.

Following is an example of the first steps of password encoding. Suppose the implementer wants to set unicodePwd to the string "new".

 ASCII "new":     0x6E 0x65 0x77
 UTF-16 "new":    0x6E 0x00 0x65 0x00 0x77 0x00
 UTF-16 "new"
     with quotes: 0x22 0x00 0x6E 0x00 0x65 0x00 0x77 0x00 0x22 0x00

The 10-byte octet string is then BER-encoded and sent in an LDAP Modify request as described previously.