skip to content

Why does LDAP define a Password Modify extended operation instead of a Modify replacing userPassword?

level: middleimportance: should knowfreq 42%

answer

  1. a new verb, not a modifier
  2. three fields, all optional
  3. omission is the interface
  4. server owns the stored form
  5. genPasswd comes back in the response

basics

~20 s

A Modify with replace on userPassword makes the client decide the stored form and cannot express 'check the old value first' or 'server, choose a new one'. Password Modify puts both in the protocol and leaves the storage form to the server.

solid answer

~40 s

Password Modify is an extended operation — `requestName` 1.3.6.1.4.1.4203.1.11.1, specified in `RFC 3062` — whose `requestValue` carries three optional fields: `userIdentity`, `oldPasswd` and `newPasswd`. Omitting `userIdentity` targets the identity the connection's LDAP Bind established, which is what makes it a self-service change; supplying it makes the same operation an administrative reset on another directory entry. Supplying `oldPasswd` lets the server verify the current value before accepting the change. Omitting `newPasswd` asks the server to generate one, returned in the response as `genPasswd`. A `ModifyRequest` with `replace (2)` on the `userPassword` attribute can express none of that: the client chooses the bytes and the storage form, and the server has no hook for its own quality or history policy.

code

asn1 · 7 lines
asn1
PasswdModifyRequestValue ::= SEQUENCE {
    userIdentity    [0] OCTET STRING OPTIONAL,
    oldPasswd       [1] OCTET STRING OPTIONAL,
    newPasswd       [2] OCTET STRING OPTIONAL }

PasswdModifyResponseValue ::= SEQUENCE {
    genPasswd       [0] OCTET STRING OPTIONAL }

go deeper

for a junior

Recall that changing a stored credential has its own operation rather than being an ordinary attribute write, and that the server rather than the client decides the form the value is stored in.

for a middle

Explain the three optional fields and what each omission means — no userIdentity is the bound identity, no newPasswd asks the server to generate one and return genPasswd.

for a senior

Show the operational consequences: it runs on the connection's authorization state, a server may refuse it on an unprotected connection, and an unsupported extended operation fails loudly because there is no criticality to fall back on.

for a principal

Frame the boundary — the protocol owns the directory-side write and its authorization, while when a credential should be reset, and what else must happen when it is, belongs to whatever drives the account lifecycle.

## What a plain Modify can and cannot say The base operation set can change a `userPassword` attribute: a `ModifyRequest` with a `replace (2)` change writes a new value onto the directory entry. Four things are wrong with using that as the way to change a credential. 1. **The client picks the storage form.** Whatever bytes the client sends are the bytes the entry holds, unless the server quietly rewrites them. Two clients written by two teams will disagree about the form, and neither is authoritative. 2. **There is no place for the old value.** A self-service change is meant to prove the caller already knows the current credential. A Modify has nowhere to carry it, so the check either does not happen or is bolted on outside the protocol. 3. **The server cannot be asked to choose.** "Reset this and tell me what you set" is a common administrative need and a Modify cannot express it. 4. **Policy has no hook.** Quality rules, history checks and age limits belong to the server, and a bare attribute write gives it no signal that this write is a credential change at all. ## What the extended operation carries Password Modify is an `ExtendedRequest` with `requestName` 1.3.6.1.4.1.4203.1.11.1. Its `requestValue` holds three fields, **all optional**, and the meaning of each omission is part of the design: - `userIdentity` — whose credential to change. Omit it and the operation applies to the identity the connection currently holds from its LDAP Bind. Supply it and you are acting on another directory entry, which the server will allow only if the bound identity has the access to do so. - `oldPasswd` — the current value. Supplying it is how a self-service change proves the caller is not simply someone sitting at an unlocked session; a server may require it for a change where `userIdentity` was omitted. - `newPasswd` — the value to set. Omit it and the server may generate one and return it in the response as `genPasswd`. ## The two shapes of the same operation | | self-service change | administrative reset | |---|---|---| | `userIdentity` | omitted — the bound identity | supplied — the target entry | | `oldPasswd` | supplied | typically omitted | | `newPasswd` | supplied by the user | supplied, or omitted to get `genPasswd` | | what authorises it | knowledge of the current value | the access rights of the bound identity | This is why the operation runs on the connection's existing authorization state rather than carrying credentials of its own. A helpdesk tool performs the LDAP Bind operation as an account with the right access and then supplies `userIdentity`; a researcher changing their own credential binds as themselves and omits it. ## Confidentiality The values travel in the request. The specification expects the operation to run over a protected connection, and a server may refuse it otherwise — `confidentialityRequired (13)` is the result code for that refusal. In practice a directory that accepts credential changes on an unprotected connection has a far larger problem than the shape of this request. ## Why an extended operation and not another control A Control modifies an operation that already exists. There is no existing operation whose meaning is "change a credential" — a Modify's meaning is "write these attribute values", which is precisely the framing this operation is trying to get away from. When the behaviour is a new verb rather than a modifier, the extension shape is an `ExtendedRequest`. It also has a consequence the control shape does not have: **there is no criticality flag to fall back on.** A server that does not implement the operation refuses the request outright rather than performing something reduced. That is the right failure mode here — a credential reset that silently did nothing would be far worse than one that failed. ## Finding out whether the server has it The OID appears among the values of `supportedExtension` in the root DSE, alongside other extended operations such as "Who am I?" (1.3.6.1.4.1.4203.1.11.3) and Cancel (1.3.6.1.1.8). Check it per server, not per estate: replicas behind one address can differ, and a directory that accepts the operation on one node and refuses it on another produces an intermittent failure that is miserable to chase. ## What this is not The operation changes a stored value on a directory entry. It says nothing about when an account should be disabled, how a joiner or leaver process is sequenced, or what an application does when someone's access ends — those are lifecycle decisions in whatever system drives them. The directory-side write is the whole of what this operation owns.

  • What does omitting userIdentity in a Password Modify request mean?
    The operation applies to the identity the connection already holds from its LDAP Bind operation — the self-service case. Supplying `userIdentity` is what turns the same request into an administrative reset on another directory entry, and the server will only allow it if the bound identity has the access.
  • How does a client know whether a directory server offers this operation, and what happens if it does not?
    Its OID appears among the root DSE's `supportedExtension` values. If the server does not implement it, the request is refused — unlike a control, an extended operation has no criticality flag, so there is no path where the server silently does something smaller instead.
  • Why would a client ever omit newPasswd?
    To ask the server to generate the value, which comes back as `genPasswd` in the response. That is the shape an administrative reset wants: the operator never chooses the value, and the one the server produces is handed over once rather than being invented by a tool.

saying these in an interview costs you the question

  • Says Password Modify is just a Modify under another name
  • Believes the client chooses the credential's storage form
  • Thinks userIdentity must always be supplied
  • Expects an extended operation to be ignorable like a non-critical control
  • Assumes a credential change is safe on an unprotected connection