私たちには、ユーザーが新しいパスワードを作成するためのパスワードシステムがあります。 LDAPSを介してActive Directoryに対抗しています。今すぐユーザーが新しいパスワードを作成すると、管理者としてバインドし、パスワードをランダムな文字列に変更してから、そのランダムな文字列でユーザーアカウントにバインドし、パスワードを変更してパスワードに変更する必要があります。これは、過去5回使用されたパスワードのパスワード履歴ポリシーがあるためです。パスワードなしのユーザーとしてLDAPをバインドしますか？
これで問題はありませんが、パスワード履歴には以前のパスワードの1つとしてランダムな文字列が含まれています。パスワードなしでユーザーとバインドする方法はありますか？ユーザーはセキュリティに関する質問によってこれより前に認証されます。
ADのリセットと変更には2つのパスワード変更操作があります。リセットは管理操作（これはあなたがここでやっていることです）です。リセットを行うと、現在のパスワードを入力する必要はありません。パスワードの変更はエンドユーザーの操作で、ユーザーは新しいパスワードに加えて現在のパスワードを入力する必要があります。
パスワードを変更してをにリセットし、パスワードをリセットする権限を持つユーザーのコンテキストで実行すると、良い結果が得られます。リセット時にパスワードポリシーを守る必要がある場合は、特殊なLDAPコントロールを使ってパスワードポリシーを実行する方法があります。
あなたは、パスワードをパスワードでリセットするようにするLDAPコントロールがあると言っていますか？コントロールは何ですか？ – Brandon
はい - このブログでは、その使用例をご覧くださいhttp://blog.msresource.net/2011/05/30/resetting-an-ad-ds-password-and-honouring-password-history-and-age- ldap_server_policy_hints-control /を使用します。サポート技術情報の記事http://support.microsoft.com/?id=2386717 –
私は別のやり方をしています。私は生成されたuid属性を使って、数日後に失効する、ユーザのエントリの下に動的オブジェクトを作成します。そのuidを含むリンクをそれらに送信します。パスワードの変更ページが表示されますが、UIDパラメータを参照する別のLoginModuleを介してログインし、それをチェックし、存在していれば正しくログインします。つまり、チケットのログインのようなものです。
ルックアップを行ったコード自体はアプリケーション自体としてバインド/再接続されていましたが、実際にアプリケーションの他のすべてのLDAP接続と同様に、ログインがすぐに終了するため、実際には問題ありませんでした。ユーザー自身のエントリに何かが行われた場合（例：パスワードの変更、プロファイルの更新、セッションで保存したパスワードを使用してそのユーザーとして再接続が行われます。ユーザーがLDAPに何か他のことをした場合、それは本当にアプリケーションがそれをやっているので、アプリケーションのバインド/再接続が上記のように行われます。 IOWは、アプリケーション自体がユーザ（または異なるレベルの権限を持つ複数の異なるユーザ）でもあります。
UIDはパスワードよりはるかに長く、エントリを含むエントリが1日か2日後に失効するため、一時的なパスワードを生成して出荷するよりも安全です。パスワードの変更ページには、チケットのログインからアクセスするとセキュリティに関する質問が表示されることもあります。
パスワード履歴に表示されるパスワードにはどのような問題がありますか？それがそれのためのものです。 – EJP