ADのLDAP署名・チャネルバインディング必須化への実務対応

LDAP署名・チャネルバインディング必須化対応を解説する記事のアイキャッチ画像 Windows
LDAP署名・チャネルバインディング必須化対応

※本記事にはアフィリエイト広告（PR）を含みます。

ある朝、複合機からのアドレス帳同期が失敗するようになった。あるいは、何年も前から動いている古い業務システムが「ユーザー認証に失敗しました」を出し始めた。ログを追うと、ドメインコントローラー(DC)側でLDAP接続そのものが拒否されている。こちら側の設定は何も変えていないのに、なぜ急に止まるのか。

答えの多くは、DCの入れ替えやOSアップグレードによって、LDAPの署名要求やチャネルバインディング(CBT)の既定挙動が変わったことにある。MicrosoftはセキュリティアドバイザリADV190023以降、LDAP署名とチャネルバインディングの必須化を一貫して推奨しており、Windows Server 2025以降の新規AD環境では既定値もより厳格になっている。「そのうち対応すればいい」と後回しにしてきたLDAP連携ほど、ある日突然止まる。

なぜ署名・チャネルバインディングが必要なのか(中間者対策)

LDAPは既定でポート389を使い、通信は暗号化も署名もされない。この状態でSASLバインド(Negotiate、Kerberos、NTLM、Digestなど)や単純バインド(simple bind)を平文でやり取りすると、経路上の攻撃者が認証パケットを傍受して正規のDCへ中継する「リレー攻撃」や、パケットを書き換えて転送する中間者攻撃(MITM)が成立し得る。DC側がこれらを拒否する設定でなければ、偽造・改ざんされたリクエストのままDCが処理を進めてしまう。

2019年にMicrosoftが公開したセキュリティアドバイザリADV190023は、この問題を指摘したものだ。LDAP署名は通信内容の改ざんを検知できるようにし、チャネルバインディングはLDAPS(TLS)セッションと認証処理を結び付けることで、確立済みのTLSセッションを乗っ取った中継を防ぐ。署名だけ、暗号化だけでは塞ぎきれない穴を、両方組み合わせて塞ぐ位置づけになる。

何が変わる、影響を受けるのは何か

まず誤解しやすい点を整理したい。2020年3月の更新は、チャネルバインディングを制御するグループポリシーと関連イベント(後述)を追加しただけで、DCの既定値そのものは変更していない。2023年8月・10月の更新も、CBT非対応クライアントを監査するイベントを追加しただけで、既定の強制動作は変えていない。「更新を当てたら急に止まった」ように見える場合、大抵は過去に誰かがGPOを変更していた、あるいは新しいDCやOSバージョンを追加したことが引き金になっている。

一方でWindows Server 2025以降は、新規に構築するAD環境に限り、LDAP署名を要求する既定値がより厳格になった(既存環境をアップグレードした場合は従来の設定が維持される)。既定挙動は今後の更新やOSバージョンでも変わり得るため、自環境がどの既定値で動いているかは、実施のたびにMicrosoft Learnで確認したい。

実際に影響を受けるのは、署名を要求しないSASLバインドや、SSL/TLSを使わない単純バインド(匿名・簡易バインドを含む)でLDAPにアクセスしているクライアントだ。複合機やNAS、各種アプライアンスがアドレス帳同期や認証連携のために匿名・簡易バインドでLDAPを使っている例、古い業務アプリケーションや運用スクリプトがポート389に平文で問い合わせている例が典型となる。LDAPS(ポート636)を使っていても、チャネルバインディング非対応のクライアントは、CBTを「Always」にした瞬間に拒否される。

影響調査 ― イベントID 2886/2887/2889でログを確認する

設定を変える前に、まず現状を可視化する。DC側のディレクトリサービスログには、署名なしバインドの状況を知らせるイベントが複数用意されている。

  • イベントID 2886: LDAP署名要求が「None」のままだと、サービス起動時などに定期的に記録される注意喚起。実際の接続有無に関わらず出る。
  • イベントID 2887: 過去24時間に許可された署名なしバインドの件数を集計した通知。該当接続の規模をまず把握できる。
  • イベントID 2888: 署名を必須化した後、過去24時間に拒否したバインドの件数を集計した通知。切り替え後の影響確認に使う。
  • イベントID 2889: 署名なしバインドが発生するたびに記録される詳細ログ。クライアントのIPアドレスと接続元ポート、認証を試みたアカウント名が記録される。

2889を記録させるには診断ログのレベルを引き上げる必要がある。既定では集計(2887/2888)までしか出ないため、個々のクライアントを特定するには次のレジストリ値を2(Basic)以上に設定する。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
値の名前: 16 LDAP Interface Events
値の種類: REG_DWORD
値のデータ: 2

設定後は、2889のログにこのような情報が記録される(値はいずれも例)。

クライアント IP アドレス: 192.0.2.10:51233
認証を試みたアカウント: corp.example.local\svc-fax01
バインドの種別: 1 - 署名を伴わない単純バインド

チャネルバインディング側にも同様の仕組みがある。CBTポリシーが「When Supported」または「Always」の状態で検証に失敗するとイベントID 3039が記録される。2023年以降の更新が適用された環境では、CBT非対応クライアントを検知する監査イベント(3074/3075)も利用でき、「Always」へ切り替える前にどの機器が非対応かを実害なく洗い出せる。

2889や3039系のログには接続元IPアドレスと認証アカウントが記録される。対象機器を(1)複合機・NAS・アプライアンス、(2)Windows以外で動くアプリケーション、(3)Windows上のアプリケーション、の3系統に分けて棚卸しすると優先順位を付けやすい。

対応 ― クライアント側のLDAPS/署名対応、GPO・レジストリ設定、段階適用

調査で洗い出した接続先ごとに、署名またはLDAPS(TLS)対応が基本方針になる。DC用の証明書を発行してLDAPS(ポート636)を有効化し、クライアント側の接続設定をLDAPS、または署名を要求するSASLバインドに変更する。変更できない古い機器・アプリケーションは、更新や置き換え、あるいはネットワーク分離のうえでの期限付き許容といった判断が必要になる。

DC側の既定値は、主に次の3つのグループポリシー(および対応するレジストリ値)で制御する。

  • 「Domain controller: LDAP server signing requirements」(None/Require Signing) ― レジストリ相当はLDAPServerIntegrity(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters、None=1、Require Signing=2)
  • 「Domain controller: LDAP server channel binding token requirements」(Never/When Supported/Always) ― レジストリ相当はLdapEnforceChannelBinding(同Parameters配下、Never=0、When Supported=1、Always=2)
  • 「Network security: LDAP client signing requirements」(None/Negotiate signing/Require signing) ― クライアント側で署名要求を制御する設定

いきなり「Require Signing」「Always」へ一斉切り替えするのではなく、段階を踏みたい。まずチャネルバインディングを「When Supported」、署名要求を「Negotiate signing」にし、対応済みクライアントには署名・CBTを使わせつつ非対応クライアントも動かし続ける。その状態で数週間、できれば月次バッチや締め処理も含めて2887・2889、3039系のイベントを監視し、該当が出なくなってからDC側を「Require Signing」「Always」に強制する順序が無難だ。

注意点 ― 一斉有効化前の棚卸し

最も避けたいのは、「セキュリティ推奨だから」と全DCへ一斉適用し、翌朝に問い合わせが集まってくるパターンだ。適用前に、最低限次の点は確認しておきたい。

  • LDAPを使う接続元の棚卸し(複合機・NAS・監視系アプライアンス、部門導入のアプリケーション、運用スクリプトやジョブ、AD DS以外のディレクトリサービスを含む)
  • 月次・年次でしか動かないバッチ処理は、監視期間を1か月以上に延ばして拾う
  • 各機器・アプリケーションが署名/LDAPS/CBTに対応しているか、提供元の情報を個別に確認する
  • 全DC一括ではなく、OUやサイト単位、検証用DCを使った段階適用にし、切り戻し手順も用意しておく

この分野はMicrosoftの既定値がバージョンごとに更新されてきた経緯があり、今後の新バージョンや更新で既定挙動がさらに変わる可能性がある。作業前には必ずMicrosoft Learnの最新情報を確認し、自社の環境に沿った挙動かを個別に確認してほしい。

署名必須化の影響確認は、まず検証環境で。VPS上のテストドメインで挙動を確かめてから本番へ展開すると安全です。

XServer VPS の料金・スペックを見る ▶

まとめ

LDAP署名・チャネルバインディングの必須化は、ある日突然降ってくる仕様変更ではなく、2019年のADV190023以降、Microsoftが一貫して求めてきた方向性の延長線上にある。全DCに強制設定をかける前に、イベントID 2886/2887/2889と、チャネルバインディング側の3039・3074/3075でどのクライアントが署名なし・CBT非対応のまま接続しているかを洗い出し、GPOとレジストリ設定(LDAPServerIntegrity、LdapEnforceChannelBinding)を段階的に切り替えれば、影響は最小限に抑えられる。「動いているから触らない」で放置してきたLDAP連携ほど、棚卸しの優先度は高い。

最終更新：2026年7月

タイトルとURLをコピーしました