その LDAP パスワードエラーは、ユーザーのパスワードではないかもしれません
bind の失敗はサービスアカウントや検索スコープに由来することがあり、ユーザーとは限りません。誰かのパスワードをリセットする前に、bind を切り分けてください。
ログが「bind が拒否された」とだけ告げているとき、ユーザーのパスワードをリセットするのは誤った第一手です。ディレクトリプラグインでは、一回のログインに複数の bind があり、拒否が検索を実行するサービスアカウントのものであることもあります。その場合にユーザーの資格情報をリセットしても何も変わりません。問題ですらなかった人を締め出すことにもなります。
一回のログインに複数の bind
専用のディレクトリアカウントを持つ構成では、通常四つの手順を順に実行し、そのどれもがログインを終わらせることができます。
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groupsプラグインはユーザー認証用の接続を、最初の接続を扱うのと同じヘルパーで構築するため、そのヘルパーは接続時、TLS のネゴシエーション時、またはサービスアカウントとしての bind 時に失敗することがあります。パスワードに関する高レベルのメッセージは後から生成され、どの ID が関与したかを伝えません。だからこそ、エラーテキストだけでは、ユーザーとサービスアカウントのどちらが拒否されたのか分かりません。
メッセージより前の行を読み、失敗が起きた瞬間を記録します。起動時、まだ誰もユーザーが来ていない段階での拒否は、構成されたアカウントかエンドポイントを指します。検索が成功した後に、ある一人だけに現れる拒否は、その人のエントリかアカウント状態を指します。
エラーを ID と結びつける
実務的な原則は、次の三つを一緒に記録することです：いつ失敗したか、どの操作が実行中だったか、どの ID が提示されたか。この三点セットがなければ、最後の一文だけを残すログでは、まったく異なる二つの障害が同じに見えます。
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
構成されたアカウントが失敗したら、ユーザーレコードに触れる前に、そのアカウントと接続を調べます。検索が成功した後にユーザーの bind が失敗したら、返ってくるはずだと思っていたエントリではなく、検索が実際に返したエントリを調べます。二つの経路が共有するのはメッセージだけです。次の担当者が必ずそれを尋ねるので、どちらを除外したかを書き留めてください。
識別名はデータであって、推測ではない
見慣れないからという理由で名前の構成要素を変えるのは、動作している構成を壊すよくある方法です。Active Directory のユーザーオブジェクトの既定の場所は Users というコンテナであり、コンテナは似た名前の組織単位と同じ種類のオブジェクトではありません。
アカウントの実際の識別名は、ディレクトリ管理者に尋ねるか、オブジェクト自体から読み取ってください。次のどちらもそれぞれのディレクトリでは正しいことがあるため、どちらも記憶から入力すべきではありません。
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example移動や名前の変更は、アカウントとパスワードが有効なままその値を変えるため、前四半期に動いていた構成が、誰も資格情報に触れないまま今四半期に失敗することがあります。再編成の後はいつでも、構成された文字列をディレクトリの現在の属性と比較してください。静かな移行の後にも行い、報告された障害の後だけにしないでください。
検索ベースはサービスアカウントではない
bind の ID と検索ベースは別の問いに答えます：プラグインが誰として認証するか、そして人をどこで探すかです。bind が成功したのに一致するユーザーがいないのは、スコープ、フィルタ、読み取り権限の問題であり、アカウントの識別名をユーザーのベースに置き換えてもそれは変わりません。
サービスが編集した構成を読み込んだこと、およびその エンドポイント、TLS 信頼、認証モード が動作する管理テストと一致することを確認してください。別のアカウントや別のドメインコントローラに対する手動の検索は、同等の実験ではありません。
保存されたシークレットを確認し、アカウントが有効か、期限切れか、ロックアウトされていないかを、パスワードをどこにも出力せずに確認してください。期限切れは見落としやすく、アカウントは動かなくなる日まで動き続けます。無関係なサービスから引き継いだロックアウトも同じくらい静かです。どちらの状態も、サービスアカウントを名指しするメッセージを出しません。
グループのルールは最後に来る
認可は bind が成功した後に実行されるため、グループのチェックが bind の失敗の原因になることはなく、グループ要件を外しても修復できません。ログインが今グループの段階に達しているなら、残る問題はメンバーシップであり、資格情報ではありません。
エラーを消すためにサービスアカウントへ広範なディレクトリ権限を与えることは、デプロイ全体のアクセス方針を変えます。それは、まだ ID に帰属させていないメッセージへの修正ではなく、独自のレビューを伴うセキュリティ上の決定として扱ってください。