LDAP署名必須化で焦りやすいのは、「どのシステムが止まるのか分からない」ことです。結論から言うと、影響を受けやすいのは LDAP を使う全接続ではなく、未署名の SASL バインドとTLS なしの simple bindです。つまり、最初にやるべきことは「LDAP 利用製品の一覧化」より、「どの接続方式が残っているか」の把握です。
この記事では、LDAP署名必須化で影響を受ける接続を洗い出す考え方を、LDAP署名・LDAPS・チャネルバインドの違い、Event ID 2887/2889 の見方、優先順位の付け方、改修パターン別の現実的な対応策までまとめます。特に「GPOを入れれば全部直るのか」「LDAPSなら安全なのか」といった実務で迷いやすい点を、判断基準付きで整理します。
LDAP署名必須化で影響を受ける接続の結論
LDAP署名必須化の影響を考えるときは、bind 方式とTLS の有無で切り分けるのが最短です。Active Directory の LDAP server signing requirements は、非 SSL/TLS の simple bind と、署名を要求しない SASL bind を拒否対象にします。一方、TLS で保護された simple bind はこの要件の直接対象ではなく、SASL を TLS 上で使う場合はチャネルバインドの要否を別に確認します。
| 接続パターン | 影響の見立て | まず確認する点 | 現実的な対応 |
|---|---|---|---|
| SASL バインド（389/3268、署名/暗号化あり） | 影響は小さい | 署名・暗号化が有効か | 現状確認と継続監視 |
| SASL バインド（389/3268、署名/暗号化なし） | 影響あり | クライアント/ライブラリが署名に対応するか | signing / sealing を有効化 |
| simple bind（389/3268、TLS なし） | 影響大 | 資格情報が平文相当で流れていないか | LDAPS / StartTLS か方式変更 |
| simple bind（636/3269、または StartTLS） | 署名必須化の直接影響は受けにくい | 証明書名、信頼チェーン、接続先 FQDN | 証明書整備と継続利用 |
| SASL over TLS | 署名必須化の直接影響は受けにくい | 将来チャネルバインドも強制するか | CBT 対応可否を別途確認 |
ポイントは、「LDAP を使うか」ではなく「どうやって LDAP に入るか」です。同じ製品でも、環境 A では signed SASL、環境 B では simple bind over 389 ということがあります。この差を見ずに製品名だけで判定すると、影響範囲を過大評価するか、逆に危険な接続を見落とします。
LDAP署名・LDAPS・チャネルバインドを混同しない
影響調査で失敗しやすいのは、LDAP署名、LDAPS、チャネルバインドを同じものとして扱ってしまうことです。3つは似て見えますが、守っている対象と、止まる接続の種類が違います。ここを混同すると、調査の切り口も対策の優先順位もずれます。
| 項目 | 役割 | 主に影響する通信 | 調査で見るポイント |
|---|---|---|---|
| LDAP署名 | LDAP メッセージの改ざん防止 | SASL バインド | 署名/暗号化の有無 |
| LDAPS / StartTLS | 通信路の暗号化 | simple bind、SASL over TLS | TLS の有無、証明書品質 |
| チャネルバインド | TLS セッションと認証の結び付け | TLS 上の SASL 認証 | CBT 対応可否、監査イベント |
実務で特に重要なのが、Windows の LDAP client signing requirements を変更しても ldap_simple_bind / ldap_simple_bind_s には影響しない点です。つまり、アプリや機器が simple bind API 前提なら、クライアント GPO だけでは是正できません。必要なのは、LDAPS / StartTLS への切り替えか、製品側の接続方式変更です。
逆に、simple bind でも SSL/TLS が確立していれば、LDAPServerIntegrity の要件は TLS で満たされます。ここを理解しておくと、legacy 製品に対して「まず LDAPS 化で止血し、その後に認証方式を見直す」という現実的な順序を取りやすくなります。
影響調査は「端末一覧」ではなく「接続一覧」で進める
LDAP署名必須化の調査で作るべきなのは、製品一覧より接続一覧です。理由は単純で、同じ製品でも設定やライブラリ差で bind 方式が変わり、同一サーバーでも複数サービスが別々の LDAP 設定を持つことがあるからです。Microsoft も、まず機器種別を特定し、必要ならネットワークキャプチャやプロセストレースで、OS 機能・サービス・アプリのどれが未対策接続を出しているかまで掘ることを案内しています。
| 台帳項目 | 例 | その項目が必要な理由 |
|---|---|---|
| 接続元 IP / ホスト名 | 10.10.1.23 / app01 | 追跡の起点になる |
| 接続先とポート | dc01:389 / gc01:3268 | DC か GC か、TLS の有無を判断しやすい |
| Binding Type | 0 / 1 | unsigned SASL か simple bind か判別できる |
| TLS の有無 | なし / StartTLS / 636 | LDAPS 化の要否が分かる |
| 認証 ID | svc_sync / appbind | 影響する権限と担当者を追える |
| 実行主体 | Windows service / Java アプリ / appliance | 改修方法が変わる |
| 製品名・バージョン | middleware X 3.2 | ベンダー対応可否を調べやすい |
| 所有部門 | 情シス / 開発 / 業務部門 | 調整窓口を明確にできる |
| 対応方針 | signing 化 / LDAPS 化 / 更改 | 次のアクションに直結する |
最低限、Binding Type と TLS の有無が分からない台帳は、あとで対応方針を決めにくくなります。Event 2889 では Binding Type 0 が unsigned SASL、1 が simple bind として記録されるため、この列を最初から用意しておくと後工程が楽です。
Event ID 2887/2889で洗い出す実務手順
Microsoft の公式な切り分けでも、LDAP署名まわりの洗い出しは Directory Service ログのイベントを見る進め方が中心です。特に、2887 は「まだ残っているか」、2889 は「誰がやっているか」、2888 は「強制後に拒否されたか」を見るのに向いています。
| Event ID | 分かること | 使いどころ |
|---|---|---|
| 2886 | 署名未強制であることの警告 | まだ未強制の DC かを把握する |
| 2887 | 過去24時間に許可された問題ある bind 件数 | 残件の有無と傾向を見る |
| 2889 | 接続元 IP、ID、Binding Type | 影響接続の特定に使う |
| 2888 | 強制後に拒否された件数 | 切り替え後の残件確認に使う |
2887/2888 は件数サマリー、2889 は詳細調査用と覚えると整理しやすいです。
2887で発生有無を確認する
まず見るべきは 2887 です。これは、署名をまだ必須にしていない DC で、過去24時間に発生した未署名 SASL bind と simple bind の件数を知らせるイベントです。大事なのは、この件数はクライアント台数ではなく bind 回数だという点です。バッチやリトライが多いシステムは件数が膨らむため、2887 だけで優先順位を決めると判断を誤ります。
2889を有効化して詳細を取る
接続元を洗う本番は 2889 です。DC の HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics にある 16 LDAP Interface Events を 2 以上にすると、Directory Service ログに、問題ある接続ごとのクライアント IP、使われた ID、Binding Type が出るようになります。
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' `
-Name '16 LDAP Interface Events' -Type DWord -Value 2Get-WinEvent -LogName 'Directory Service' -MaxEvents 500 |
Where-Object Id -in 2887,2888,2889 |
Select-Object TimeCreated, Id, Message採取期間は、通常業務だけでなく夜間ジョブ、週次同期、月次バッチが一巡する長さを取るのが安全です。日中だけのログで切り替えると、「月末だけ認証連携が落ちる」という一番厄介な障害が残りがちです。
2889 の Binding Type は、0 が unsigned SASL、1 が simple bind です。台帳の分類はこの値をそのまま使うと、「GPOで直せるか、LDAPS が必要か」を切り分けやすくなります。
IPからプロセス・製品まで特定する
2889 で IP が分かっても、そこで止めないことが重要です。Microsoft は、接続元をアプライアンス/ルーター、非 Windows 端末、Windows 端末に分け、必要に応じてネットワークキャプチャ、プロセスマネージャ、デバッグトレースで、どのコンポーネントが LDAP を出しているか特定する流れを案内しています。Windows 系で追跡が難しい場合は、より新しい環境で使える LDAP client performance counters を、プロセス単位での足がかりにする方法もあります。
実務では、IP → ホスト名 → 実行サービス → 製品名・バージョン → 対応可能な設定 の順で掘ると迷いません。ここでいきなり製品名に飛ぶと、実は OS 標準機能や古いエージェントが原因だった、という遠回りが起きます。
2888で切り替え後を確認する
署名必須化を有効にした後は 2888 を見ます。2888 は、拒否された未署名 SASL bind と non-SSL/TLS の simple bind の件数を 24 時間単位で知らせるイベントです。つまり、2887/2889 が「切り替え前の洗い出し」、2888 が「切り替え後の残件確認」です。
優先順位は「危険度」と「直しやすさ」で付ける
優先順位を件数順だけで付けると、対処すべき順番を間違えます。特に simple bind を 389/3268 で使っている接続は、資格情報保護の観点で優先度を高く見るべきです。未署名の SASL も放置はできませんが、まずは 平文相当の資格情報を流しうる接続 と 止まると業務影響が大きい接続 を前に出すと判断しやすくなります。
| 優先度 | 典型例 | 先に手を付ける理由 | 初手の考え方 |
|---|---|---|---|
| 高 | Binding Type 1、389/3268、サービスアカウント利用 | 資格情報保護の観点で危険度が高い | LDAPS 化、StartTLS、方式変更を最優先 |
| 高 | 業務基盤、同期基盤、認証連携基盤 | 1本止まると影響範囲が広い | ベンダー確認と検証環境での先行試験 |
| 中 | Binding Type 0 の管理可能な Windows / middleware | 設定変更やライブラリ更新で直ることが多い | signing / sealing 対応を確認 |
| 低 | 検証用ツール、一時的な管理作業 | 発生頻度が低く代替しやすい | 運用停止または別手段に切り替え |
2887 や 2888 の件数は bind 回数なので、多いものが必ずしも最重要とは限りません。IP + ID + process で束ねて、1件ごとの危険度と業務影響を見たほうが、移行計画を現実的に組めます。
改修パターン別に考える現実的な対応策
調査で接続を特定した後は、すべてを同じ方法で直そうとしないことが重要です。simple bind と unsigned SASL では、向く対策が違います。
| 対応策 | 向くケース | メリット | 注意点 |
|---|---|---|---|
| SASL の signing / sealing を有効化 | ドメイン参加済みの Windows アプリや middleware | 証明書管理を増やさず対処しやすい | simple bind API 前提の製品には効かない |
| LDAPS / StartTLS へ移行 | simple bind 前提の製品、古い連携 | 影響を止めやすい | 証明書名、信頼チェーン、FQDN 不一致で失敗しやすい |
| 製品・ライブラリ更新 | appliance、非 Windows 製品、古い SDK | 根本解決になりやすい | サポート対象版かを必ず確認する |
| 連携方式の見直し | 既に保守切れ、改修不能 | 将来の運用負荷を下げやすい | 工数が大きく、短期対応には向かない |
考え方としては、Binding Type 1 なら LDAPS / StartTLS か方式変更、Binding Type 0 なら signing / sealing の有効化が基本です。特に simple bind については、クライアント GPO で直らないため、アプリ設定・製品更新・LDAPS 化のいずれかを選ぶ必要があります。SSL/TLS 上の simple bind は LDAPServerIntegrity の直接対象ではないため、legacy 製品の暫定策としては現実的です。
移行の進め方は、最初から全部を厳格化するより、監査で残件をつぶしながら段階的に進めるほうが現実的です。Microsoft の説明でも、段階導入ではクライアント側を Negotiate signing のまま使い、最終的により強い設定へ寄せる考え方が示されています。一方で、最大限の保護を狙う最終形としては、クライアント・サーバー双方で署名要件を強める構成が基準になります。
なお、一部の DC だけ緩い設定を長期運用する方法は、どのクライアントがその DC に流れるかの管理が難しく、是正を先送りしやすいです。暫定回避を置くなら、期限・対象・終了条件を明文化した短期策にとどめるほうが安全です。
失敗しやすいポイント
- 署名とチャネルバインドを同時に強制しないこと。別設定で影響範囲も違うため、同時に変えると原因切り分けが難しくなります。チャネルバインドも進めるなら、2887/2889 とは別に 3039、3074、3075 の監視も視野に入れます。
- 2887 や 2888 の件数を、そのまま端末数だと見なさないこと。これはクライアント数ではなく bind 回数の集計です。
LDAP client signing requirementsを入れれば simple bind も直る、と考えないこと。simple bind API を使う製品は、別の対応が必要です。- 2889 のログだけを絶対視しないこと。過去には、SASL で適切に sign/seal されているセッションを 2889 が誤って報告する問題に対する修正が出ています。DC の更新状態も確認したうえで解釈するのが安全です。
- 1台の DC、1日のログだけで終わらせないこと。夜間処理、週次同期、月次処理が出るまで観測しないと、本番切り替え後にだけ落ちる接続が残ります。
最後にやるべきこと
LDAP署名必須化の調査は、やみくもに製品棚卸しをするより、イベントと接続方式で絞るほうが速く、漏れも減ります。進め方は次の順序が分かりやすいです。
- 全 DC で 2887 を確認し、問題ある bind が残っているか把握する。
- 2889 を有効化し、IP・ID・Binding Type を採取して、台帳を
接続単位で作る。 - Binding Type 1 は LDAPS / StartTLS か方式変更、Binding Type 0 は signing / sealing 対応で整理する。
- 残件をつぶしてから署名必須化を有効にし、切り替え後は 2888 とアプリ監視で拒否の有無を確認する。
要するに、LDAP署名必須化で影響を受ける接続を洗い出す考え方は、「LDAP を使うもの全部」を探すことではなく、「未署名の SASL と TLS なし simple bind を見つけること」に尽きます。この線引きが最初にできれば、調査対象も対策の打ち手も一気に整理できます。最初の一歩は、2887 の有無を確認し、次に 2889 で接続一覧を作ることです。
コメント