3.1.5.10 Change Password Pattern

The "change password" methods enable a client to change the password of a user object. All these methods require that the client has knowledge of the current password in order for the message to be processed successfully.

It is important to note that SamrChangePasswordUser requires a handle to a user object (obtained through an "open" or a "create" method, sections 3.1.5.1 and 3.1.5.4) and therefore requires an authentication connect. SamrUnicodeChangePasswordUser2 and SamrOemChangePasswordUser2 do not require any handle and can be sent directly to the targeted server using no security or by authenticating as anonymous. This characteristic allows end users, whose passwords have expired and therefore cannot logon, to change their passwords without an authenticated connection. See section 1.3 for a description of the "change password" pattern of methods.

In the following descriptions, when a value is said to be "presented by the client", that value is provided by the client side of the protocol. In a canonical password-change scenario, an end user enters his or her old and new passwords into a password-change application. That application acts as a client for this method.

To encrypt password data, these methods use the fact that the client (an end user in the canonical scenario) and the server (a DC in the canonical scenario) share a common secret: the user's existing password. The LM and/or NT hash (specified in the following sections) of the existing password's cleartext value is used as an encryption key. Because the DC stores the existing password as well, the DC is able to decrypt the data sent by the client. Of course, if the end user did not enter the correct existing password, the decryption does not result in meaningful data, and an error is returned.

SamrUnicodeChangePasswordUser2 is preferred if the Unicode-encoded cleartext password is available to the client.