Summary

  • RFC 3062 made LDAP password change independent of a user's DN form and of whether the password was stored in a directory entry.
  • Its server had to leave the password unchanged on failure and could report success only after changing it; that response did not prove a later login or downstream replication.

A directory edit with nowhere to land

LDAP's familiar Modify operation changes attributes on a named directory entry. That is a clean fit when a person has a Distinguished Name and the password is a userPassword attribute there. But by 2001, LDAP was also being combined with external authentication services. Those services could recognize identities that were not DNs and keep their passwords outside the directory. An LDAP client could no longer assume that changing an entry changed the credential used at sign-in.

Kurt Zeilenga's RFC 3062, published in February 2001, answered with a different operation rather than pretending every password was an attribute. It assigned an OID, 1.3.6.1.4.1.4203.1.11.1, to a Password Modify Extended Operation. A request could name userIdentity, supply oldPasswd, and supply newPasswd; each field was optional. The protocol therefore described a password-change request, not a universal storage layout.

Two ways to identify the target

If userIdentity is supplied, its octet string may be an LDAP DN, but RFC 3062 does not require that form. If it is omitted, the request acts on the user associated with the current LDAP session. The operation can thus use an already-bound session or carry an identity in a representation the server understands. Neither choice tells the client where the password is stored or how the server maps that identity to the credential it controls.

That is the historical move: LDAP supplied a common request boundary while leaving the password's home outside the model. The directory server might use an attribute, another store, or an external authentication service. RFC 3062 allows those arrangements; it does not document any particular one or promise that all servers resolve identities alike.

A narrow, useful success rule

The strongest part of the design is its outcome rule. A server may return success only after successfully changing the user's password. Otherwise it must leave the password unmodified and return a non-success result. A supplied but incorrect old password also must not change it. If the client omits newPasswd, the server must either generate a password and return it as genPasswd on success, or fail. When oldPasswd is absent, other server policy may decide whether the change is allowed; administrators may restrict the operation.

This gives the protocol a meaningful commit boundary: the response code is supposed to distinguish a completed change from a failed attempt. But it is not an end-to-end authentication receipt. It does not say that a later Bind succeeded, that every replica of an external service has received the new value, that the user learned a generated password, or that the identity belongs to a particular real-world person. Those facts require separate evidence.

Discovery depends on the session

RFC 3062 recommends advertising the OID in the server's supportedExtension attribute in the Root DSE, and recommends that clients check before sending the operation. The qualification matters: a server may choose to advertise support only when the client is authorized and/or adequate security has been established. Capability discovery can therefore depend on the session. An absent OID is evidence about that response in that context, not necessarily a timeless statement about every server path or principal.

The operation itself provides no privacy or integrity. RFC 3062 says it must not be used anonymously and requires confidentiality protection, such as TLS. That warning follows directly from the payload: old and new passwords may travel in the request, and a generated password may travel back in the response. A protocol path that reaches a remote credential store is useful only if it does not expose the credential while carrying the change.

From RFC 2251 to the later LDAP envelope

RFC 3062 was defined as an LDAPv3 Extended Operation under RFC 2251. RFC 4511 later obsoleted RFC 2251 and describes the general ExtendedRequest/ExtendedResponse framework. That succession clarifies the envelope in which extensions fit; it does not establish that a given server implemented Password Modify, nor that two implementations behaved identically.

The RFC Editor's verified errata record is modest but worth keeping straight. Erratum 340 corrects “where” to “were” in the background sentence. Erratum 4899 adds commas to the ASN.1 request's field list. The punctuation correction helps make the formal sequence acceptable to ASN.1 tooling; it does not change the identity or storage boundary the article examines.

RFC 3062 is best read as a small bridge across an architectural seam. LDAP could carry a request to change a password without requiring that the password be a directory attribute or the identity be a DN. The server still had to connect that request to its actual credential authority—and the standard's reply described only the result promised at that operation boundary.

Sources