Active Directory で一部のユーザーだけ LDAP バインドが失敗し、「Invalid Credentials (49) / AcceptSecurityContext error data 569」が出ると、ついパスワード誤りを疑いがちです。実は DC 側のユーザー権利の割り当てが原因で、ネットワークログオンが拒否されているケースがあります。
症状：Domain Admin など “一部だけ” が LDAP 認証に失敗する
代表的な相談パターンは次の通りです。
- 組み込みの Domain Administrator や 自分のドメイン管理者アカウント だけが、LDP.exe から SASL/Negotiate の Bind をすると失敗する
- FreeRADIUS、Cisco AnyConnect、VPN 装置、Proxy、ID 連携基盤などが AD へ LDAP bind したときに、特定ユーザーだけ認証が通らない
- Windows へのログオンはできる（＝パスワードは合っている）にもかかわらず、LDAP ではエラーになる
| 観測されるエラー | アプリ側の見え方 | 現場で起きがちな誤解 |
|---|---|---|
ldap_bind_s() failed: Invalid Credentials (49) | 資格情報が不正 | 「パスワードが違う」「アカウントがロックされた」と決め打ちしてしまう |
AcceptSecurityContext error, data 569 | AD へ SSPI（Kerberos/NTLM）で失敗 | data の意味を調べず、同じく「パスワード違い」と扱ってしまう |
なぜ “Invalid Credentials” なのにパスワードは正しいのか
LDAP の bind 失敗が Invalid Credentials (49) になるのは、実務では珍しくありません。LDAP クライアント（LDP.exe や RADIUS/VPN 装置）は、DC から返ってきた認証失敗を “資格情報エラー” としてまとめて表示することがあるためです。つまり、表示されている文字列が必ずしも原因そのものを表していない、というのが最初の落とし穴です。
AcceptSecurityContext error data 569 の意味
data 569 は 16 進数の 0x569 を示すことが多く、Windows のエラーメッセージとしては「ユーザーに要求されたログオンの種類がこのコンピューターで許可されていない（Logon Type Not Granted）」に相当します。つまり、本質は「パスワード誤り」ではなく「ログオン権利（User Rights Assignment）の拒否」です。
| data（例） | 意味（目安） | まず疑うべきポイント |
|---|---|---|
52e | ユーザー名またはパスワードが正しくない | 入力ミス、パスワード期限/変更直後のキャッシュ、アプリ側の保存情報 |
775 | アカウントがロックアウト | ロックアウトポリシー、誤った認証の多発元、サービスの設定 |
533 | アカウントが無効 | Disable の有無、条件付きアクセス、ID 管理側の同期 |
569 | 要求されたログオン種類が許可されていない | ユーザー権利の割り当て（特に拒否系）、GPO のハードニング |
LDAP バインドは「ネットワーク経由のログオン」として評価される
SASL/Negotiate（Kerberos/NTLM）での LDAP bind は、DC 側では概ね ネットワークログオン（Logon Type 3 相当）として扱われます。ここで「ネットワークからのアクセスを拒否」するポリシーが当たっていると、結果として LDAP は失敗し、アプリには Invalid Credentials に見えてしまいます。
ログオン種類（Logon Type）は、切り分けの精度を上げる強力な手掛かりです。LDAP 認証が絡むトラブルで頻出するログオン種類をまとめます。
| ログオン種類 | 意味 | 関連する「拒否」ポリシーの例 |
|---|---|---|
| 2 | 対話型（ローカル/コンソール） | ローカルでのログオンを拒否 |
| 3 | ネットワーク | ネットワークからこのコンピューターへのアクセスを拒否 |
| 4 | バッチ | バッチ ジョブとしてのログオンを拒否 |
| 5 | サービス | サービスとしてのログオンを拒否 |
| 10 | リモート デスクトップ | RDS によるログオンを拒否 |
原因の本命：DC の “ユーザー権利の割り当て” でネットワークログオンが拒否されている
結論から言うと、ドメインコントローラー上の次の設定に Administrators グループや対象ユーザーが入っていると、LDAP のようなネットワーク経由の認証が拒否されやすくなります。
ネットワークからこのコンピューターへのアクセスを拒否（Deny access to this computer from the network）
特に “一部だけ失敗” のときは、対象ユーザーが Domain Admins / Enterprise Admins / Builtin\Administrators など高権限グループのメンバーであるケースが多く、GPO のハードニングで Administrators を拒否に入れてしまったことが原因になりがちです。
| なぜ「一部だけ」になるのか | 現場でよくある例 |
|---|---|
| 特定アカウントだけが Administrators 系グループに所属している | Domain Admin だけ LDAP bind が失敗し、一般ユーザーは成功する |
| 拒否の権利（Deny）は許可（Allow）より優先される | 「ネットワークからアクセス」側に許可があっても、拒否に入っているとアウト |
| 管理者アカウントの運用が特殊 | 「普段は管理者でログオンしない」方針でも、VPN 認証だけ例外にしていて露見する |
切り分けの進め方：先に “DC 側の失敗理由” を見にいく
アプリが返すのは「認証失敗」という結果だけで、理由の解像度が低いことが多いです。最短で原因に到達するなら、DC 側のログを必ずセットで確認します。
LDP.exe で再現させる（SASL/Negotiate）
- DC 上、または管理端末で LDP.exe を起動
- 「Connection」→「Connect」で DC の FQDN と 389（LDAPS なら 636）を指定
- 「Connection」→「Bind」→「Bind type: SASL」→「SASL: Negotiate」を選択
- 該当ユーザー（例：domain\Administrator）で bind を実行
ここで Invalid Credentials (49) と AcceptSecurityContext error, data 569 が揃うなら、今回のテーマにかなり近い状況です。
DC の Security ログで “失敗理由” を拾う
DC のイベントビューアーで次を確認します。
- 「Windows ログ」→「セキュリティ」
- ログオン失敗（例：イベント ID 4625）
4625 の詳細に「失敗の理由」や「ログオンの種類（Logon Type）」が出ます。LDAP bind の場合、ログオン種類が 3 付近になっていることが多く、失敗の理由が「要求されたログオン種類が許可されていない」なら、ユーザー権利の割り当てが本命です。
「そのユーザーは何者か」を先に確認すると早い
“一部だけ失敗” の裏には、ほぼ必ず グループ所属の違いがあります。特に Domain Admins は DC 上で Administrators 権限を持つため、拒否設定の影響を受けやすいです。次のコマンドで所属グループを確認すると、原因に直結するヒントが出ます。
whoami /groups
net user ユーザー名 /domainもし「失敗するユーザーだけ Administrators / Domain Admins に所属している」なら、User Rights Assignment の拒否を最優先で疑うのが効率的です。
有効なユーザー権利を “文字として” 抜き出して検索する
GUI だけだと見落としが出やすい場合があります。DC で有効なローカルセキュリティ設定をエクスポートし、該当キーを検索すると機械的に確認できます。
secedit /export /cfg C:\temp\secpol.cfg
notepad C:\temp\secpol.cfgエクスポートしたファイルで SeDenyNetworkLogonRight を検索し、どの SID/アカウントが入っているかを確認します。GPO 由来でも “いま有効な値” を見られるので、切り分けの補助に使えます。
対処：拒否設定から Administrators / 対象ユーザーを外す
対処はシンプルですが、「どこで設定されているか（ローカルか GPO か）」を見誤ると再発します。現場向けの流れで整理します。
実務的な対処手順
- DC で
secpol.msc（ローカルセキュリティポリシー）を開く - 「ローカル ポリシー」→「ユーザー権利の割り当て」→「ネットワークからこのコンピューターへのアクセスを拒否」を開く
- Administrators や該当ユーザー／グループが入っていれば削除する
gpresult /zまたはrsop.mscで、設定が ローカル か GPO 由来かを特定する- GPO 由来なら、GPMC（グループ ポリシーの管理）で該当 GPO を修正（ここが重要）
gpupdate /force（または再起動）で反映させ、LDAP bind を再テストする
確認に使えるコマンド例です。
gpresult /z
gpupdate /forceGPO 由来のときに起きる “戻る問題”
ローカルの secpol.msc で直したつもりでも、原因が GPO なら次回のポリシー更新で元に戻ります。「戻った」「また同じユーザーだけ失敗する」といった再発はここが原因であることが非常に多いです。
| 症状 | 原因 | 対策 |
|---|---|---|
| 一度直ったが、数時間〜翌日に再発する | GPO で同じ設定が上書きされている | GPMC で該当 GPO の「ユーザー権利の割り当て」を修正する |
| DC を追加したら一部 DC だけで再発する | OU やリンクされる GPO が DC ごとに異なる | DC の配置 OU と GPO リンク、継承ブロックを見直す |
| 特定サイト/特定サブネットからだけ失敗する | 認証先 DC が変わり、ポリシー適用差分が露呈している | サイト/サブネット設計と DC 配置、複数 DC のポリシー整合を確認する |
Administrator だけまだ失敗する場合に見るべきポイント
「Administrators を拒否から外したのに、組み込み Administrator だけまだダメ」というケースもあります。RDP で「管理者がログオンの種類を制限…」と出る状況と同じで、別の “拒否系” に引っかかっている可能性があります。
次のポリシーも併せて確認してください。
| ポリシー名 | 影響するログオン種別（目安） | 確認ポイント |
|---|---|---|
| ローカルでのログオンを拒否（Deny log on locally） | 対話型（Type 2） | コンソール/対話ログオン制限が入っていないか |
| リモート デスクトップ サービスによるログオンを拒否（Deny log on through RDS） | RDP（Type 10） | RDP 接続の拒否に Administrators を入れていないか |
| サービスとしてのログオンを拒否（Deny log on as a service） | サービス（Type 5） | RADIUS 連携などでサービス実行アカウントに影響しないか |
| バッチ ジョブとしてのログオンを拒否（Deny log on as a batch job） | バッチ（Type 4） | 定期タスクやジョブ実行に影響しないか |
FreeRADIUS / AnyConnect など外部機器連携での注意点
LDAP bind 失敗が “パスワード違い” と見えると、外部機器側の実装によっては次の二次災害が起きます。
- 同じユーザーでリトライを繰り返し、アカウントロックアウトを誘発する
- 管理者が原因を切り分ける前に、不用意なパスワードリセットをしてしまう
- VPN で管理者アカウントを使っていて、復旧中に 管理者の遠隔アクセス手段が断たれる
外部機器連携では「検索用の bind アカウント（サービスアカウント）」と「利用者の認証（ユーザー自身の bind）」が混ざりやすいので、どちらが失敗しているのかを明確にしてください。特に検索用アカウントに Domain Admin を使っている場合は、今回の拒否設定に直撃します。
再発防止：Domain Admin を LDAP 認証に使わない設計にする
今回のような現象は「Domain Admin だけ失敗する」という形で顕在化しやすいのですが、そもそも Domain Admin を外部機器の LDAP 認証に使う設計自体が、セキュリティと運用の両面でおすすめできません。
- ハードニングやベースライン適用で、管理者のネットワークログオンが制限されることがある
- 高権限アカウントの認証情報が外部機器に保存されるリスクが増える
- 万一機器側が侵害されると、権限の大きい資格情報が横展開に使われやすい
実務では、次のような “割り切ったサービスアカウント” を用意すると事故が減ります。
| 推奨 | 内容 |
|---|---|
| 専用サービスアカウントを作る | LDAP 検索／参照に必要な最小限の権限だけを付与し、管理者グループに入れない |
| 利用範囲を絞る | VPN 認証用途なら、対象 OU やグループのユーザーだけに限定して検索・認証する |
| 拒否設定の意図を文書化 | 「なぜ Administrators を拒否に入れたのか」を残し、例外（必要な用途）を合意の上で設計する |
| 変更管理を徹底 | GPO のベースライン適用・セキュリティ強化の変更時に、LDAP 認証の回帰テストを入れる |
「誰が設定を変えたのか」を追跡する：監査ログの取り方
原因が分かった後に必ず話題になるのが「いつ・誰がその拒否設定を入れたのか」です。ここは 監査ポリシーを入れておくと追跡しやすくなります。
ユーザー権利の割り当て変更を記録する（4717 / 4718）
次の監査を有効化します。
gpedit.mscまたは GPMC- 「コンピューターの構成」→「Windows の設定」→「セキュリティの設定」
- 「詳細監査ポリシーの構成」→「ポリシーの変更」→「認証ポリシーの変更の監査」を成功/失敗で有効
この状態でユーザー権利の割り当て（User Rights Assignment）が変更されると、DC の Security ログに次のイベントが記録されます。
| イベント ID | 意味 | 見どころ |
|---|---|---|
| 4717 | ユーザー権利が付与された | どのアカウントに、どの権利が追加されたか／実行者 |
| 4718 | ユーザー権利が削除された | どのアカウントから、どの権利が削除されたか／実行者 |
GPO 自体の編集を追う場合の考え方
拒否設定の原因が「ローカル変更」ではなく「GPO の編集」だった場合、ローカルの監査だけでは追い切れないことがあります。実務では次の 2 段で考えると整理しやすいです。
- DC への適用結果としての変更（＝どの権利が変わったか）：4717/4718 など
- GPO の編集行為（＝誰が GPO を変更したか）：GPO オブジェクト変更の監査、変更管理ログ、運用手順
「編集者を確実に特定したい」運用なら、GPO 管理の権限を絞ったうえで、GPO 変更の監査（ディレクトリサービス変更の監査など）も併用するのが安全です。また、GPMC での変更チケット運用（いつ誰が何を変えるか）をセットにすると、技術的監査と運用監査が噛み合い、再発時の追跡が現実的になります。
現場で使えるチェックリスト（LDAP bind エラー 49 / data 569）
| チェック項目 | 確認方法 | 判断の目安 |
|---|---|---|
| 再現条件の固定 | LDP.exe で SASL/Negotiate bind を実施 | 特定ユーザーだけ失敗するなら権限・ポリシー差分を疑う |
| DC 側ログの確認 | Security ログ（4625 など） | 失敗理由がログオン種類の拒否なら User Rights Assignment が本命 |
| グループ所属差分 | whoami /groups、net user /domain | 失敗ユーザーだけが Administrators 系なら拒否権利の影響を強く疑う |
| 拒否系の権利 | secpol.msc → ユーザー権利の割り当て | 「ネットワークから…拒否」に Administrators が入っていないか |
| GPO 由来の切り分け | gpresult /z、rsop.msc | GPO 由来なら GPMC で直さないと再発する |
| 反映と再テスト | gpupdate /force または再起動 | 反映後に LDP.exe / アプリで再検証し、再発しないか監視する |
まとめ：data 569 は “資格情報” ではなく “ログオン権利” を疑う
Invalid Credentials (49) という表示だけでパスワードにフォーカスすると、無駄なリセットやロックアウトを誘発し、復旧が遠回りになります。AcceptSecurityContext error data 569 が見えた時点で、DC 側の ユーザー権利の割り当て（拒否系）と、設定元（ローカル/GPO）を最優先で確認してください。原因がそこにあれば、短時間で再現性を持って解決できます。
コメント