要約

  • RFC 3062は、利用者がDNで表されること、またパスワードがLDAPの項目に保存されていることの両方を前提から外した。
  • サーバーは実際に変更できた場合にだけ成功を返し、失敗ならパスワードを変更してはならない。ただし、その応答は次回のログイン成功や外部サービス全体への反映を証明しない。

変更先の属性が見つからない

LDAPのModify操作は、指定されたディレクトリー項目の属性を変更する。利用者に識別名（DN）があり、userPassword属性にパスワードが置かれているなら自然な設計だ。しかし外部認証サービスとの連携が進むと、利用者がDNでは表されない場合や、パスワードをディレクトリー外で管理する場合が出てくる。LDAP項目を書き換えても、ログインで検証される秘密が変わるとは限らない。

Kurt Zeilengaは2001年2月、すべてのパスワードを属性に押し込まずに済む別の操作として、RFC 3062を公開した。Password Modify拡張操作のOIDは 1.3.6.1.4.1.4203.1.11.1。要求には userIdentity、oldPasswd、newPasswdを含められるが、いずれも任意だ。RFCが定めたのは変更要求の境界であり、パスワード保存方式の統一ではない。

セッションに任せるか、IDを渡すか

userIdentityがあれば、そのオクテット列はLDAP DNでもよいが、DNである必要はない。省略すると、現在のLDAPセッションに関連付けられた利用者が対象になる。クライアントは認証済みセッションのIDを使うことも、サーバーが解釈できる別の表現を送ることもできる。どちらを選んでも、パスワードの保存場所や、サーバーがそのIDを変更対象の資格情報へ対応させる方法は示されない。

ここに設計上の転換がある。LDAPは共通の要求窓口を提供するが、パスワードをディレクトリー属性にするよう求めない。サーバーは属性、別の保存先、外部認証サービスのいずれにも接続し得る。RFC 3062はそれらを許容する一方、特定の実装を記述せず、各サーバーが同じ方法でIDを解決するとも保証しない。

成功応答が引き受ける範囲

サーバーが成功を返せるのは、パスワードの変更を実際に完了した場合だけだ。それ以外では値を変更せず、非成功を返さなければならない。提示された古いパスワードを検証できない、または誤っている場合も変更は禁止される。クライアントが newPasswdを省けば、サーバーは新しい値を生成して成功応答の genPasswdに返すか、要求を失敗させなければならない。oldPasswdがなければ、変更を許可するかはサーバーの別のポリシーに委ねられ、管理者が操作を制限することもできる。

この規則は有用な確定点を作る。完了した変更と失敗した試行は応答コードで分けられる。しかし、端から端までの認証完了通知ではない。後続のBindが成功すること、外部サービスのすべての複製に新しい値が届くこと、利用者が生成パスワードを安全に受け取ること、あるIDが特定の実在人物を指すことまでは証明しない。それぞれ別の証拠が要る。

能力発見はセッション次第

RFC 3062はRoot DSEの supportedExtension属性でOIDを広告し、クライアントが送信前に確認することを推奨する。ただし、サーバーはクライアントの認可状態や必要なセキュリティ保護が整った場合に限って広告してもよい。つまり、能力の見え方はセッションの文脈で変わり得る。ある応答にOIDがないという事実だけから、あらゆる利用者や接続経路で未対応だとは断定できない。

操作そのものは機密性も完全性も提供しない。RFCは匿名利用を認めず、TLSなどによる機密性保護を求める。要求には古い値と新しい値が、応答には生成された値が入ることがあるからだ。外部の資格情報ストアへ届く経路が秘密を漏らすなら、その接続性自体が弱点になる。

RFC 3062はRFC 2251のLDAPv3拡張操作として定義された。その後RFC 4511がRFC 2251を置き換え、汎用のExtendedRequest／ExtendedResponseの枠組みを記述した。これは拡張がプロトコルに収まる仕組みの変遷であり、特定サーバーがPassword Modifyを実装した証拠でも、複数実装が同じ動作をする証拠でもない。

RFC Editorが検証済みとして記録する正誤表は二つある。Erratum 340は背景の “where” を “were” に直し、Erratum 4899はASN.1のフィールド列にカンマを補う。形式表記の修正であり、ID形式とパスワード保存先の境界は変わらない。

RFC 3062により、LDAPはパスワードが項目に置かれていなくても、利用者がDNで表されていなくても、変更要求を運べるようになった。要求を実際の資格情報の管理者へ結び付ける役割はサーバーに残る。プロトコルの応答が語るのは、その操作境界で約束された結果だけだ。

出典