摘要

  • RFC 3062 把密码修改与两项假设分开：用户必须以 DN 表示，以及密码必须存放在 LDAP 目录条目中。
  • 服务器只有在确实改过密码后才能返回成功；失败时必须保持密码不变。但这不等于后续登录成功，也不证明外部服务的所有副本都已更新。

要改的密码可能不在这条目录记录里

LDAP 的 Modify 操作针对一个明确目录条目的属性。用户有区别名（DN），密码也保存在该条目的 userPassword 属性时，这种设计很直接。但 LDAP 与外部认证服务结合后，前提不再总是成立：身份可能不是 DN，密码也可能由目录以外的服务保存。此时改动 LDAP 条目，未必会改到真正用于登录的秘密。

Kurt Zeilenga 于 2001 年 2 月发布 RFC 3062，没有把所有密码硬塞回目录模型，而是另设 Password Modify 扩展操作，OID 为 1.3.6.1.4.1.4203.1.11.1。请求可以包含 userIdentity、oldPasswd 和 newPasswd，三者分别可选。协议描述的是一次改密请求，并未规定密码必须采用哪种存储布局。

会话身份，或另行提交的身份

如果提供 userIdentity，它是一个八位字节字符串，可以是 LDAP DN，也可以不是。若省略该字段，请求针对当前 LDAP 会话所关联的用户。客户端既可以依赖已建立的会话身份，也可以交给服务器一个由其识别的身份表示。无论哪种方式，协议都不揭示密码存在哪里，也不规定服务器怎样把身份对应到可修改的凭证。

关键变化在于：LDAP 提供了共同的请求边界，却不要求密码成为目录属性。服务器可能使用目录属性、独立存储或外部认证服务。RFC 3062 允许这些形态，但没有描述某个具体系统，也没有保证不同服务器以同一种方式解析身份。

成功响应的边界

服务器只有在成功修改密码后才能返回成功；否则必须保持原密码不变并返回非成功结果。客户端如果提交了错误的旧密码，服务器同样不得改动密码。如果省略 newPasswd，服务器必须自行生成新密码并在成功响应的 genPasswd 字段中返回，或者直接失败。若没有 oldPasswd，服务器可以依据其他策略判断是否允许修改；管理员也可以限制该操作。

这是一条有用的操作承诺：响应码区分已经完成的修改与失败尝试。但它不是端到端的登录回执。它不能证明随后一次 Bind 成功、外部认证服务的每个副本都拿到了新值、用户已安全收到生成的密码，也不能证明身份属于某个具体自然人。这些都需要不同的证据。

能力发现取决于当下会话

RFC 3062 建议服务器在 Root DSE 的 supportedExtension 属性中公布该 OID，也建议客户端先检查再发送请求。不过服务器可以只在客户端已获授权和／或必要安全保护已经建立时才公布扩展。因此，能力发现可能随会话上下文变化。一次响应里没有该 OID，只能说明这个上下文中的公布结果，不能必然推断所有主体、所有路径都不支持。

扩展本身不提供机密性或完整性。RFC 3062 禁止匿名使用，并要求使用 TLS 等机密性保护。请求里可能有旧密码和新密码，响应里也可能返回服务器生成的密码；如果承载改密的路径暴露凭证，访问外部密码库的便利就失去了意义。

RFC 3062 建立在 RFC 2251 的 LDAPv3 扩展操作框架上。RFC 4511 后来取代 RFC 2251，描述通用 ExtendedRequest／ExtendedResponse 机制。这段标准演进说明扩展如何装入 LDAP 协议，却不能证明某个服务器实现了 Password Modify，更不能证明各实现行为相同。

RFC Editor 记录了两项已核实勘误：第 340 号把背景段落中的 “where” 改为 “were”；第 4899 号为 ASN.1 字段列表补上逗号。后者让形式语法更明确，却没有改变本文关注的身份形式与密码存储边界。

RFC 3062 让 LDAP 无须假定密码是目录条目属性、身份是 DN，也能承载改密请求。服务器仍须把它连到真正控制凭证的权威系统；协议响应只描述在该操作边界上承诺的结果。

来源