SMB署名とLDAPチャネルバインディング ── NTLM対策の「残り半分」を実務で締める

「NTLMの監査を始め、IPアドレス直打ちの接続も直している。では、依存をすべてなくすまでの間、リレー攻撃にはどう備えるのか」

その間の防御が、SMB署名と、LDAP署名・LDAPチャネルバインディングです。NTLMそのものを止める設定ではなく、認証を別の接続へ中継する攻撃を、それぞれの接続先で防ぐための設定です。NTLM削減と並行して進め、NTLMを廃止した後も残す強化策として考えます。¹²

進め方は共通で、監査する → 接続元のアプリ・機器を直す → 強制するの順です。ただし、SMBとLDAPでは確認する設定も、読むイベントも違います。この記事では最初に役割を分け、その後でそれぞれの確認・修正・展開手順を説明します。

NTLMシリーズの3本目です。NTLMの監査手順は「NTLM廃止で業務アプリは止まるか」、認証プロトコルの仕組みは「図解でわかるNTLMとKerberos」を参照してください。

1. まず結論：3つの防御を、接続先で分ける

LDAP署名は整合性検証、LDAPSは接続全体のTLS暗号化、チャネルバインディングは認証とTLSチャネルの結び付けです。「LDAPSにした」と「CBTを検証している」は同じ意味ではありません。また、単純バインドはCBTを持たず、チャネルバインディング検証の対象外です。詳しくは5章・6章で分けて説明します。³⁴

SMBでは、Windows 11 24H2のEnterprise・Pro・Educationは送受信とも、Windows Server 2025は送信側で署名必須が既定です。Homeはこの変更の対象外なので、OSのバージョンだけでなくエディションも確認します。⁵

一方、LDAPについて本記事が参照するKB4520412の一連の更新は、署名・チャネルバインディングの既定ポリシーを変更しません。更新を入れたことと、強制を設定したことを区別する必要があります。この更新の説明を、あらゆるOS・導入条件の既定値へ一般化せず、対象環境の構成を確認してください。⁴

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全28件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. なぜ署名が必要なのか：NTLM削減と並行して守る

2.1. 認証を中継できても、正しい署名は作れない

NTLMの根本的な弱点は相互認証がないことです。クライアントがサーバーの身元を検証できないため、攻撃者は本物のサーバーのふりをして認証させ、その認証応答を本物のサーバーへ中継できます。これがリレー攻撃です。マイクロソフトもNTLM・NTLMv2認証のSMBリレーや中間者攻撃への脆弱性を説明しています。²

NTLMを完全に止めれば、このNTLMリレーは成立しなくなります。ただし、1本目の記事で扱った依存の洗い出しと修正には、数か月単位の時間がかかります。その間も接続先を守るのが署名です。

flowchart LR
    CL["クライアント"]
    AT["攻撃者<br/>(偽サーバー)"]
    SV["本物のサーバー"]

    CL -->|"① 認証応答"| AT
    AT -->|"② そのまま中継"| SV
    SV -.->|"③ 署名必須なら:<br/>セッション鍵を持たない攻撃者は<br/>正しい署名を作れず失敗"| AT

図1: 認証応答を中継しただけの攻撃者は、セッション鍵を使った正しい署名を作れない

認証の結果として、署名に使うセッション鍵を持つのはクライアントと本物のサーバーです。認証応答を中継しただけの攻撃者はその鍵を持たず、署名必須の接続で後続メッセージを偽造できません。SMBへのリレーにはSMB署名、ドメインコントローラーのLDAP/LDAPSへのリレーにはLDAP署名とチャネルバインディング、という分担になります。

2.2. 署名を必須にしても、Kerberosへの移行は続ける

署名の効果を高めるには、認証方式も確認します。セッション鍵はパスワードに由来するため、NTLMv2よりKerberosを使って強い鍵から始めることが推奨されています。マイクロソフトは、共有への接続にIPアドレスやCNAMEを使わないことも挙げています。¹

IPアドレスや、対応するSPNが登録されていない別名で接続すると、KerberosではなくNTLMが使われるためです。別名を使い続ける場合のSPN登録は、1本目の記事で扱っています。

NTLM依存の削減と署名の必須化は、同時に進める施策です。署名による改ざん検知とチャネルバインディングはKerberos認証のセッションにも効くので、NTLMを廃止した後に外す設定ではありません。¹

3. SMB署名：仕組みと既定値を確認する

3.1. 「対応している」と「必須にしている」を分ける

SMB署名は、セッション鍵と暗号スイートを使って各メッセージに署名を付けます。SMBヘッダー内の署名にはメッセージ全体のハッシュと送信者・受信者の身元が含まれ、途中で改ざんされると一致しなくなります。これが改ざん検知となり、なりすましやリレーからの防御になります。¹

設定を見るときの軸は、単なる有効・無効ではなく、署名を必須(Require)にしているかです。SMB 2.x以降では EnableSecuritySignature は無視され、意味を持つのは RequireSecuritySignature です。クライアントかサーバーのどちらか一方でも必須なら、その接続には署名が必要です。署名しないのは、両方とも必須にしていない場合です。¹

署名の計算にはコストがありますが、アルゴリズムはSMB1のMD5から、SMB 2.02のHMAC-SHA-256、SMB 3.0のAES-CMACへ進み、Windows Server 2022とWindows 11ではAES-128-GMACによる高速化が入りました。「署名は遅い」という過去の印象だけで見送らず、パイロット端末で実測して判断します。¹

3.2. OS・エディションと、送信・受信の向きを確認する

まず「設定 > システム > バージョン情報」で、OSのエディションとバージョンを確認します。次の表の送信は、そのPCがSMBクライアントとして接続する側、受信はSMBサーバーとして接続を受ける側です。自社の端末・サーバーが該当する行を見てください。

上3行はマイクロソフトが明記する既定値です。⁵ 最下行のドメインコントローラーは従来からの別条件で、SYSVOL・NETLOGONへ接続してくる相手にSMB署名を要求します。グループポリシーやログオンスクリプトの配布は、以前から署名前提で動いています。¹

Windows 11 24H2でもHomeは送受信とも必須ではなく、この既定値変更の対象外です。Homeへの更新だけで署名必須になるという説明は当てはまりません。将来の変更や個別の設定まで保証する表ではないため、接続障害ではエディションを確認したうえで、4.1節の実際の設定値も確認します。⁵

Enterprise・Pro・Educationでは、24H2への更新により、そのPCからのSMB接続が既定で署名必須になります。Windowsは署名に対応しているため、先に洗い出すべき相手は、署名非対応・無効のサードパーティ機器です。古いNAS、複合機のスキャン保存に関係する設定、組み込みLinuxのSambaなどを確認します。

4. SMB署名：監査して機器を直し、必須化する

4.1. 現在の署名要求と、管理するポリシーを確認する

# クライアント側(送信)の署名要求
Get-SmbClientConfiguration | FL RequireSecuritySignature

# サーバー側(受信)の署名要求
Get-SmbServerConfiguration | FL RequireSecuritySignature

True は必須、False は必須ではない状態です。確認は送信側と受信側を分けて行います。⁵

グループポリシーで管理する場所は、コンピューターの構成\Windowsの設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション です。次の2つを使い分けます。¹

ポリシー名の「常に(always)」が「必須」を意味します。まだ非対応機器を把握できていなければ、この段階で一斉に強制せず、次の監査へ進みます。

4.2. 署名できない相手を監査で洗い出す

Windows 11 24H2以降では、署名や暗号化に対応しないサードパーティのクライアント・サーバーを検出する監査を利用できます。次は署名について有効にするコマンドです。¹

# サーバー側: 署名に対応しないクライアントを検出する
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# クライアント側: 署名に対応しないサーバーを検出する
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

サーバー側では接続してくるクライアント、クライアント側では接続先サーバーを調べます。グループポリシーでは、コンピューターの構成\管理用テンプレート\ネットワーク 配下のLanman Server / Lanman Workstationにある「Audit client does not support signing」などが対応します。¹

同じ監査機能には、暗号化非対応を調べる -AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption もあります。ただし、これは将来SMB暗号化を必須化するための準備です。署名対応でも暗号化には非対応の機器があるため、署名必須化の完了判断に、暗号化の監査結果を混ぜないでください。¹

署名・暗号化の監査が使うログとイベントIDは、次のとおりです。イベント本文も読み、今回調べる署名の問題かを確認します。¹

イベント ビューアーでは、次の手順で確認します。

1. eventvwr.msc を開き、アプリケーションとサービス ログ > Microsoft > Windows > SMBClient > Auditへ進む。サーバー側は同じ階層のSMBServer > Auditを開く。
2. 右ペインの「現在のログをフィルター」で、イベントIDに 31998,31999、サーバー側なら 3021,3022 を指定する。
3. イベントを開いて問題の種類と相手の情報を確認し、署名に対応できない機器の一覧を作る。

PowerShellでまとめて取得する場合は、次の例を使います。

# クライアント側: 署名に対応しないサーバーを検出した監査イベント
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# サーバー側: 署名に対応しないクライアントを検出した監査イベント
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

この例は、署名・暗号化の監査IDをまとめて取得します。表示された件数すべてを「署名非対応の件数」とせず、Messageで署名と暗号化を分けてください。

監査を有効にした直後など、該当イベントがなければ Get-WinEvent は該当なしのエラーを返します。例の -ErrorAction SilentlyContinue はそれを抑えるためのものです。絞り込みの書き方は「Get-WinEventでイベントログを実務的に調べる」も参照してください。

監査期間は、NTLM監査と同じく業務が一巡するまで取ります。有効にした直後のログだけで、すべての接続先を確認したことにはしません。

4.3. 署名エラーとゲストブロックを分けて直す

署名必須の環境から、署名できない相手へ接続すると、次のエラーが発生します。⁵

0xc000a000
STATUS_INVALID_SIGNATURE
暗号化署名が無効です。

もうひとつが、ゲストアクセスの拒否です。署名必須の接続ではゲストアクセスも使えないため、認証なしで使うNASなどでは、次のようなエラーになります。⁵

組織のセキュリティ ポリシーによって認証されていないゲスト アクセスが
ブロックされているため、この共有フォルダーにアクセスできません。

第一の対処は、機器側でSMB署名を有効にし、ゲストではなく資格情報で接続することです。必要ならファームウェア更新や、接続経路の変更を検討します。

クライアントで Set-SmbClientConfiguration -RequireSecuritySignature $false とする回避策は、署名エラーの側を緩和するものです。ゲストブロックは「安全でないゲストログオンの禁止」という別のクライアント設定でも制御されるため、署名要求を外しただけでは、ゲスト接続の拒否は解消しません。

マイクロソフトは、サードパーティ機器への回避策として署名を無効にすることも、ゲストアカウントで署名を使おうとすることも推奨していません。⁵ 緩和が必要でも、通常の運用にせず、機器更改までの期限付き例外として管理します。

4.4. パイロットから全体展開へ進める

24H2以降の対象エディションが増えるほど、クライアント側が既定で署名必須になります。実質的な締め切りはOS更新計画が決めるので、Windows 11への移行前提作業に、この監査と機器の修正を含めてください。Windows 10からの移行方針は「Windows 10サポート終了の選択肢」で扱っています。

5. LDAP署名：バインド方式を確認してから強制する

SMBの次は、ドメインコントローラーとAD LDSへのLDAP接続です。未署名のLDAPトラフィックはリプレイ攻撃や中間者攻撃に弱く、傍受・改変された要求に基づいてサーバーが判断してしまうおそれがあります。³

まず、認証に使う「バインド」の種類を分けます。

LDAP署名を必須にすると、署名を要求しないSASLバインドと、平文(非SSL/TLS)接続の単純バインドを拒否します。署名は暗号化とは別の整合性検証です。単純バインドには署名の枠組みがないため、単純バインドを使い続ける場合はLDAPSへ移す、という判断になります。³

5.1. イベントは「件数」と「接続元」を分けて読む

LDAP署名と、次章のチャネルバインディングは、いずれもドメインコントローラーのDirectory Serviceログを使います。イベント ビューアーでは、アプリケーションとサービス ログ > Directory Serviceを開きます。

使い分けは、残件数を見る集計イベント(2887・3040)と、接続元を調べる個別イベント(2889・3039・3074・3075)です。問題のある接続が残っている間は、強制へ進まず修正します。

表にある「手動の有効化なしで利用可能」は、その更新で監査機能を利用できることの説明です。あらゆる構成で対象イベントが必ず出る、という意味にせず、OS・適用更新と診断設定をKB4520412で確認します。単純バインドがCBT検証の対象外である点も、6章で読み分けます。⁴

5.2. 2887で残件を見て、2889で接続元を特定する

LDAP署名で使うのは2886・2887・2888・2889です。2886は構成を促すリマインダー、2887は24時間ごとの問題バインドの集計、2888は拒否構成後の集計です。接続元を知るための2889だけは、既定では出ません。³

まず2887で未署名バインドが残っているかを確認します。件数があれば、診断設定「16 LDAP Interface Events」を2(Basic)にして2889を記録し、接続元IPアドレスと認証に使われたIDを調べます。³

2889は、集計ではなく該当バインドごとの記録です。高頻度の接続が残る環境ではDirectory Serviceログを急速に埋めるため、接続元の特定後は診断設定を元のレベル(既定は0)へ戻します。継続して記録するなら、先にログ転送と保持容量を確保してください。

調べる相手は、業務システムのAD認証・人事連携、複合機のLDAPアドレス帳検索、ネットワーク機器のLDAP認証などです。特に機器類は平文の単純バインドになっていることが多いため、LDAP設定を確認します。修正はLDAPS(636番)または署名付きSASLバインドへの切替です。具体例は7章にまとめます。

5.3. 修正後に署名を要求し、拒否動作を確認する

接続元の修正後、グループポリシーで次の設定を行います。³

構成の確認には ldp.exe を使います。TLSを使わず389番へ接続して単純バインドを試し、次のエラーになれば、拒否する設定が効いています。これは拒否動作の検証であって、平文バインドを業務で使う手順ではありません。検証用の資格情報で行います。³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAPチャネルバインディング：LDAPSの認証も確認する

6.1. TLS暗号化と、認証をチャネルへ結び付けることは別

LDAPSは通信をTLSで暗号化します。しかし、クライアントに認証させ、その認証を攻撃者自身の別のTLS接続へ中継する形のリレーには、暗号化だけでは足りません。チャネルバインディングトークン(CBT)は、認証をそのTLSチャネル自体へ結び付け、別チャネルへの中継を検出できるようにする値です。⁴

対象は、LDAPS上でNTLMやKerberosなどのWindows認証(SASLバインド)を行う接続です。単純バインドはCBTを持たず、この検証の対象外です。LDAPS上の単純バインドを守るのはTLS暗号化と資格情報管理であり、設定を Always にしても、単純バインドのクライアントがCBTの監査イベントに現れるわけではありません。

6.2. 設定値0・1・2とポリシーを対応させる

ドメインコントローラーのレジストリ、または対応するグループポリシーで制御します。⁴

When supportedとAlwaysは同じではありません。対応しているクライアントを検証する段階と、対象接続に常に検証を要求する段階を分け、対応状況を確認してから Always へ進めます。

6.3. 3039・3040・3074・3075で接続元を調べる

5.1節の早見表のうち、チャネルバインディング側のイベントの意味を詳しく見ると、次のようになります。2020年3月10日の更新で関連イベントが加わり、2023年以降の更新で監査が拡充されました。⁴

マイクロソフトの展開手順も、全ドメインコントローラーのDirectory Serviceログで2889、3039、3074・3075を監視し、問題のある機器を特定して提供元に確認し、対応後に強制する順です。⁴

LDAPSを利用していることだけで完了とせず、認証方式とCBT対応まで見ます。対象外の単純バインドをCBTイベントだけで探そうとしないことも、6.1節の区別から分かります。

6.4. 更新適用だけで、強制済みになったと判断しない

KB4520412は、2020年3月10日の更新および同文書が扱う一連の更新では、LDAP署名・チャネルバインディングの既定ポリシーを変更しないと説明しています。⁴

したがって、その更新を適用しただけの未強制環境では、管理者が設定する作業が残ります。SMBの24H2における既定値変更と混同せず、監査機能を使えることと、防御を強制したことを分けて確認してください。強制する時期を選べるうちに、接続元の修正を計画して進めます。

7. 業務アプリと機器を、原因別に直す

7.1. イベントに出た相手と、修正方法を対応させる

署名非対応、ゲスト運用、平文の単純バインド、CBT未対応では、直す場所が違います。同じ「接続できない」でも一括して設定を緩めず、イベントと接続方式から対応を選びます。

7.2. .NETアプリは、認証方式とTLSの設定を確認する

自社開発の.NETアプリでは、まずAuthType.Basicの単純バインドを、平文の389番へ送っていないかを調べます。次は、LDAP署名を強制すると拒否される悪い例です。実際の資格情報で実行するための例ではありません。

// 悪い例: 平文389番への単純バインド。LDAP署名を強制すると拒否される
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

修正は、ドメイン環境で選べるならNegotiateと署名・暗号化の要求を基本にします。単純バインドが必要ならLDAPSを使います。次の2例はこの選択肢を対比する抜粋です。前の悪い例と続けて実行するものではありません。

// 良い例1: Negotiate+署名・暗号化を要求する(KerberosはSPNと名前解決が揃えば選ばれる)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // 実行中のアカウントで認証

// 良い例2: 単純バインドを使うなら必ずLDAPSにする
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

良い例1のNegotiateはKerberosを優先しますが、強制はしません。IPアドレスで接続する、SPNが未登録・重複している、といった条件ではNTLMへフォールバックします。その場合でも、コードで要求した署名・暗号化の要求自体は効きます。

Kerberosで認証できているかを確認するには、klistで該当サービスのチケット取得を確認します。1本目の記事の送信NTLM監査を「すべて監査する」にしていれば、イベント8001が出ていないことも傍証になります。ただし、監査ポリシーが無効のまま「8001がない」と判断しても意味はありません。

良い例2の単純バインドはTLSで暗号化されますが、CBT検証の対象ではありません。これを良い例1と同じ防御だと扱わないことが重要です。DirectoryEntry(ADSI)を使う場合は、AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing を明示します。

接続先をIPアドレスではなくFQDNで書く原則は、KerberosでのSASLバインドにも共通です。名前解決とSPNを含めて直し、コードの認証方式だけを変えて終えないようにします。

8. まとめ：監査・修正・強制を、経路ごとに完了させる

SMB署名、LDAP署名、LDAPチャネルバインディングは、NTLMを止める設定の代わりではありません。NTLMの依存を減らしている間もリレーを防ぐための防御であり、Kerberos移行後も残す恒久的な強化策です。¹²

SMBでは、OS・エディションと送受信の既定値を確認し、署名非対応機器とゲスト運用を先に直します。Windows 11 24H2の対象エディションへの更新計画が、準備の締め切りになります。LDAPでは、2887・2889で未署名バインド、3039・3040・3074・3075でCBT関連の問題を調べ、接続元を直してから強制します。⁵³⁴

更新適用、監査機能の有効化、防御の強制は別の段階です。特にKB4520412のLDAP更新を入れただけで、強制が済んだとは判断しないでください。単純バインドがCBT検証の対象外であることも踏まえて確認します。⁴

自社アプリでは、まず平文の単純バインドとIPアドレス直打ちをなくすことが、大きな改善になります。仕上げは「設定を変更した」ではなく、業務一巡分の監査と修正、パイロットでの動作確認を終えて、強制へ進めたかで判断してください。

関連記事

• NTLM廃止で業務アプリは止まるか ── 監査ログの取り方と、依存を潰す順番
• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表
• Windowsアプリのセキュリティ最小チェックリスト

関連する相談領域

合同会社小村ソフトでは、SMB署名・LDAP署名の強制にともなう業務アプリの改修、認証・ファイル共有まわりの接続障害の調査を扱っています。

• Windowsアプリ開発
• 不具合調査・原因解析
• 既存資産活用・移行支援
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

SMB署名を必須にすると、ファイルサーバーは遅くなりませんか？

署名の計算コストはゼロではありませんが、アルゴリズムは世代ごとに改善されています。SMB1のMD5に対して、SMB 2.02ではHMAC-SHA-256、SMB 3.0ではAES-CMACになり、Windows Server 2022とWindows 11ではAES-128-GMACによる署名の高速化が入りました。また、ドメインコントローラーは以前からSYSVOLとNETLOGONに接続するすべての相手にSMB署名を要求しており、グループポリシー配布はずっと署名前提で動いてきました。性能を理由に見送る前に、まずパイロット端末で必須化して実測することをおすすめします。体感できる差が出るのは、大容量ファイルを連続転送するような特定の使い方に偏ります。

Windows 11 24H2にしたらNASに繋がらなくなりました。SMB署名が原因ですか？

典型的にはそれが原因です。Windows 11 バージョン24H2のEnterprise・Pro・Educationは送信・受信の両方でSMB署名が既定で必須になったため、署名に対応しない(または無効にしている)サードパーティのNASに接続すると 0xc000a000(STATUS_INVALID_SIGNATURE)で失敗します。また、署名の必須化はゲストアクセスの無効化も伴うため、認証なしで使わせる設定のNASでは「組織のセキュリティポリシーによって、認証されていないゲストアクセスがブロックされているため」というエラーになります。第一の対処はNAS側でSMB署名を有効にし、ゲストではなく資格情報で接続することです。クライアント側で署名要求を無効化する回避策もありますが、それで解消するのは署名エラーの側だけです。ゲスト接続のブロックは署名とは別のクライアント設定(安全でないゲストログオンの禁止)によるもので、そちらまで緩めない限り失敗したままです。マイクロソフトは署名の無効化もゲストでの運用も推奨していません。

LDAP署名とLDAPS(LDAP over SSL/TLS)は何が違うのですか？

別のものです。LDAP署名は、389番ポートのLDAP接続の上で行われるSASLバインド(Negotiate、Kerberos、NTLM、Digest)に整合性検証(署名)を要求する仕組みで、通信の暗号化はしません。LDAPSは接続全体をSSL/TLSで暗号化する仕組みです。そしてLDAPチャネルバインディングは、LDAPSのさらに上の防御で、認証とTLSチャネルを結びつけることで「認証情報だけを別のTLS接続に中継する」攻撃を防ぎます。ドメインコントローラーを守るには、平文の単純バインドをやめさせ、SASLバインドには署名を要求し、LDAPS上のWindows認証(SASLバインド)にはチャネルバインディングトークンの検証を要求する、という3点セットで考えてください。なおCBTを持たない単純バインドはチャネルバインディング検証の対象外で、LDAPS上の単純バインドを守るのはTLS暗号化そのものです。

どの順番で締めていけばよいですか？

監査→修正→強制の順番はNTLM制限のときと同じです。まずSMBは、Windows 11 24H2以降で使える署名非対応の相手を検出する監査を有効にして、署名できない機器を洗い出します。LDAPはドメインコントローラーのDirectory Serviceログでイベント2887(24時間ごとの未署名バインド集計)を確認し、件数が出ているなら診断設定「16 LDAP Interface Events」を2にしてイベント2889でクライアントを特定します。チャネルバインディングはイベント3039・3040と、2023年以降の更新で追加された監査イベント3074・3075で同様に洗い出します。問題のある接続元をすべて直してから、SMB署名の必須化、LDAP署名の必須化、チャネルバインディングのAlwaysへと切り替えます。いきなり強制に振らないことが唯一の原則です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。