Overview #The default password attribute for Microsoft Active Directory.
Microsoft Active Directory stores the password on a user object or inetOrgPerson object in the UnicodePwd attribute. UnicodePwd attribute is written by an LDAP Modify under the following restricted conditions. Microsoft 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.
Encryption Required #Microsoft requires a minimum level of LDAP encryption of one of the following:
- 128 bit SSL
- kerberos session encryption on 2K and on K3
- NTLM session encryption.
- 128-bit (or better) SASL-layer encryption instead of SSL/TLS. (2003, 2008, 2012)
In Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, if the fAllowPasswordOperationsOverNonSecureConnection heuristic of the dsHeuristics attribute 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.
LDAP Queries #The UnicodePwd attribute is never returned by an LDAP search.
Process for a UnicodePwd Change #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 a 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 #Microsoft requires the password be enclosed in double quotes, and then each character (including the quotes) must be converted to its unicode equivalent.
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.
Example #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.