現在、ユーザーが LDAP 呼び出しによって認証されるユーザー ログインを作成する必要があるいくつかの Web アプリケーションを実装しています。LDAP サーバーとユーザー アカウントはすべてのアプリケーションで共有され、ユーザーの資格情報はすべてのアプリケーションで同じになります。
私の質問は、クライアント側の標準的な LDAP シナリオでハッシュがどこで行われるのか、または LDAP サーバーがそれを処理するのかということです。LDAPサーバーは、作成時にユーザーパスワードを取得し、それをハッシュして保存することを理解していました。(それまでに、ソルト化された SHA512 ハッシュと、クライアント > Web サーバー > LDAp サーバー間の SSL 接続を使用する予定です)
ハッシュ操作は LDAP サーバーで集中的に行われ、クライアントのトラブルを軽減し、クライアント側での破損を回避して他のアプリに影響を与えることを理解していました。
最新のプロ品質のサーバーは、サーバー上でハッシュを実行することを含むパスワード属性（通常userPasswordおよび）にストレージスキームを使用します。authPasswordサーバーは通常、パスワードに一意の値（ソルトと呼ばれる）を追加または追加してから、ハッシュ関数を実行します。「ソルト」は、辞書攻撃の効果を最小限に抑えます。つまり、ソルトされたハッシュ化されたパスワードに対して辞書を作成するのはより困難です。
SSL（セキュア接続）を使用するか、StartTLS拡張要求を使用して非セキュア接続をプロモートする必要があります。暗号化された接続を使用して、BIND要求でパスワードを平文で送信できるようにする必要があります。安全な接続を介して平文で送信されるパスワードは、サーバーのパスワードポリシー適用メカニズムによって履歴と品質をチェックできます。パスワード履歴と品質チェックを実施するサーバーの場合、パスワードは事前にエンコードされた状態で送信しないでください。したがって、サーバーが組織全体で合意されたパスワードの品質と履歴のチェックを中央の場所で実施できるという事実は、LDAPクライアントにとってそれほど「問題」ではありません。