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

「NTLMの監査を始めた。IPアドレス直打ちも直している。では、依存を全部潰し終えるまでの間、リレー攻撃への備えはどうするか」──前回の記事「NTLM廃止で業務アプリは止まるか」を公開したあと、いちばん多かった質問がこれでした。

答えが、今回扱うSMB署名とLDAP署名・LDAPチャネルバインディングです。どちらも「NTLMをやめる」施策ではなく、「NTLMが残っている間も、盗んだ認証を横流しする攻撃(リレー攻撃)を成立させない」ための防御です。そして片方のSMB署名は、Windows 11 24H2 / Windows Server 2025で既定値が実際に変わっており、こちらが何もしなくてもOSの更新と一緒にやってきます。もう片方のLDAP署名・チャネルバインディングは、既定値こそ変わっていないものの、管理者が締めない限りずっと緩いままです。つまりSMBは「先回りするか、OS更新で事故ってから対応するか」、LDAPは「自分でいつ締めるか」という話です。

この記事はNTLMシリーズの3本目です。NTLMの監査手順は1本目、プロトコルの仕組みは2本目にまとめてあります。

1. まず結論

• SMB署名は、SMBの全メッセージに改ざん検知の署名を付ける仕組みです。署名にはメッセージ全体のハッシュと送信者・受信者の身元が含まれ、リレー攻撃・なりすまし攻撃からの防御になります。¹
• 既定値はもう変わっています。Windows 11 バージョン24H2のEnterprise・Pro・Educationは送信・受信の両方で署名必須、Windows Server 2025は送信のみ必須が既定です(Homeはどちらも必須ではありません)。²
• 署名必須化はゲストアクセス無効化とセットです。署名に対応しないNASや、ゲスト接続前提の機器は、OS更新のタイミングで接続エラーになります。エラーコードは 0xc000a000(STATUS_INVALID_SIGNATURE)やゲストブロックのメッセージです(4.3節)。²
• LDAP署名は、ドメインコントローラーが「署名を要求しないSASLバインド」と「平文の単純バインド」を拒否できるようにする仕組みです。未署名のLDAPトラフィックはリプレイ攻撃・中間者攻撃に弱いためです。³
• LDAPチャネルバインディングは、LDAPS(SSL/TLS)上のWindows認証(SASLバインド)をTLSチャネルに結びつける仕組みです。CBTを持たない単純バインドは検証の対象外です(6章)。レジストリ値 LdapEnforceChannelBinding(0/1/2)またはグループポリシーで制御します。⁴
• どちらも「監査イベントを読む→接続元を直す→強制に切り替える」の3段階で進めます。LDAP署名はイベント2887・2889、チャネルバインディングはイベント3039・3040と監査イベント3074・3075で接続元を特定できます(5章・6章)。³⁴
• 重要な前提として、これらの更新は既定値を勝手に変えません。マイクロソフトは、2020年3月以降の一連のLDAP更新について「LDAP署名・チャネルバインディングの既定ポリシーは変更しない」と明言しています。締めるのは管理者の仕事です。⁴

2. なぜ署名なのか ── リレー攻撃の「残り半分」

2本目の記事で書いたとおり、NTLMの根本的な弱点は相互認証がないことです。クライアントはサーバーの身元を検証できないため、攻撃者は「本物のサーバーのふり」をしてクライアントに認証させ、受け取った認証応答をそのまま本物のサーバーへ横流しできます。これがリレー攻撃で、マイクロソフト自身がNTLMおよびNTLMv2認証はSMBリレー・中間者攻撃に対して脆弱だと明記しています。⁵

NTLMを完全に止めればこの攻撃は成立しなくなりますが、1本目の記事で見たとおり、依存の洗い出しと修正には数か月単位の時間がかかります。その間の防御が署名です。

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

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

図1: リレー攻撃とSMB署名の関係

要点は、署名の鍵(セッション鍵)は認証の結果としてクライアントと本物のサーバーだけが持つことです。認証応答を中継しただけの攻撃者はセッション鍵を持たないため、署名必須の環境では以降のメッセージを偽造できません。SMB署名がSMBへのリレーを、LDAP署名とチャネルバインディングがドメインコントローラーのLDAP/LDAPSへのリレーを、それぞれ塞ぎます。

もうひとつ実務的な注意があります。署名の効果は認証プロトコルの選択と独立ではありません。セッション鍵はパスワードに由来するため、KerberosではなくNTLMv2で認証していると、署名の土台となる鍵が弱くなります。マイクロソフトもSMB署名の効果を最大化する条件として、Kerberosを使うこと、IPアドレスやCNAMEで共有に接続しないことを挙げています。¹ IPアドレスや、対応するSPNが登録されていない別名で接続するとKerberosではなくNTLMが使われるためです(別名を使い続けたい場合のSPN登録は1本目の記事で扱っています)。 つまりNTLM依存の削減と署名の必須化は、別の施策ではなく同じ施策の両輪です。

3. SMB署名 ── 仕組みと、もう変わった既定値

3.1. 仕組みを1分で

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

アルゴリズムは世代ごとに強化されています。SMB1はMD5でしたが、SMB 2.02でHMAC-SHA-256に、SMB 3.0でAES-CMACになり、Windows Server 2022とWindows 11ではAES-128-GMACによる署名アクセラレーションが入りました。¹ 「署名=遅い」という記憶がSMB1時代のものなら、いったん忘れて実測し直す価値があります。

設定は「有効/無効」ではなく「必須(Require)かどうか」で考えます。SMB 2.x以降では EnableSecuritySignature 設定は無視され、意味を持つのは RequireSecuritySignature だけです。そしてクライアントとサーバーのどちらか一方でも必須にしていれば、その接続は署名されます。署名されないのは、両方が必須にしていない場合だけです。¹

3.2. 既定値の判断表

上3行はマイクロソフトのドキュメントに明記された既定値です。² 最下行は以前からの挙動で、ドメインコントローラーは接続してくるすべての相手にSMB署名を要求します。グループポリシーやログオンスクリプトの配布は、ずっと署名前提で動いてきました。¹

この表の実務的な意味はこうです。Windows 11 24H2(Enterprise・Pro・Education)への更新は、そのPCからのすべてのSMB接続を署名必須に変えます(Homeは対象外です)。社内のファイルサーバーがWindowsなら何も起きません(Windowsは全バージョンで署名に対応しているため)。事故が起きるのは、署名に対応しない・無効にしているサードパーティ機器、すなわち古いNAS、複合機のスキャン保存先設定、組み込みLinuxのSambaなどが相手のときです。

4. SMB署名を「必須」へ進める手順

4.1. 現状を確認する

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

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

Trueなら必須、Falseなら必須ではない状態です。² グループポリシーで管理する場合の場所は コンピューターの構成\Windowsの設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション の「Microsoft ネットワーク クライアント: 常に通信にデジタル署名を行う」(クライアント)と「Microsoft ネットワーク サーバー: 常に通信にデジタル署名を行う」(サーバー)です。ポリシー名の「常に(always)」が「必須」を意味します。¹

4.2. 先に「署名できない相手」を洗い出す(監査)

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

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

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

同じ仕組みで暗号化に対応しない相手を検出する監査(-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption)もありますが、¹ それは将来SMB暗号化を必須化するときの準備であり、署名のロードマップとは別トラックです。署名対応でも暗号化非対応の機器は珍しくないため、署名の完了判断に暗号化の監査イベントを混ぜないでください。

記録先は次のとおりです。¹

グループポリシーでは コンピューターの構成\管理用テンプレート\ネットワーク 配下の Lanman Server / Lanman Workstation にある「Audit client does not support signing」等が対応します。¹ 1本目の記事で書いた監査期間の考え方(業務が一巡するまで回す)は、ここでもそのまま当てはまります。

4.3. 事故のパターンを知っておく

署名必須の環境で署名できない相手に接続すると、次のエラーになります。²

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

もうひとつ、見落としやすいのがゲストアクセスです。署名の必須化はゲストアクセスの無効化も伴います。認証なし(ゲスト)でアクセスさせる設定のNASに接続すると、次のようなエラーになります。²

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

対処の優先順位は明確です。第一は機器側でSMB署名を有効にし、ゲストではなく資格情報で認証させることです。クライアント側で Set-SmbClientConfiguration -RequireSecuritySignature $false とすれば署名エラー(0xc000a000)の側は回避できますが、ゲストブロックは署名とは別のクライアント設定(安全でないゲストログオンの禁止)によるもので、署名を緩めただけでは解消しません。マイクロソフトは、サードパーティ機器への回避策として署名を無効化することも、ゲストアカウントで署名を使おうとすることも推奨していません。² 緩和する場合は「その機器の更改までの、期限を切った例外」として扱ってください。

4.4. 展開の順番

なお、24H2以降の端末が増えるほど「クライアント側が既定で必須」になっていくため、実質的な締め切りはOS更新計画が決めます。Windows 10のサポート終了対応でWindows 11 24H2以降へ移行中の組織は、この検証を移行の前提作業に含めてください(「Windows 10サポート終了の選択肢」)。

5. LDAP署名 ── ドメインコントローラーへの経路を守る

SMBの次はLDAPです。ドメインコントローラー(およびAD LDS)への未署名のLDAPトラフィックは、リプレイ攻撃や中間者攻撃に対して脆弱です。攻撃者が傍受・改変したパケットをサーバーに転送すると、サーバーが偽造されたリクエストに基づいて判断を下すおそれがあります。³

LDAP署名の強制とは、ディレクトリサーバーに次の2種類のバインドを拒否させることです。³

1. 署名(整合性検証)を要求しないSASLバインド(SASLにはNegotiate、Kerberos、NTLM、Digestが含まれます)
2. 平文(非SSL/TLS)接続で行われる単純バインド

5.1. まず監査 ── イベント2886/2887/2889

ドメインコントローラーのDirectory Serviceログには、最初から手がかりが出ています。³

2889だけは既定では出ません。診断設定「16 LDAP Interface Events」を2(Basic)に上げると記録されるようになります。³ 手順は、まず2887の集計で「そもそも未署名バインドが何件あるか」を見て、ゼロでなければ2889を有効にして接続元を特定する、という流れです。注意点として、2889は集計ではなく該当バインドの発生ごとに記録されるため、レガシーなバインドが高頻度で残っている環境ではDirectory Serviceログを一気に埋めます。接続元の特定が済んだら診断設定を元のレベル(既定は0)へ戻してください。回しっぱなしにするなら、ログの転送と保持の確保が先です。

接続元の典型は、LDAP連携している業務システム(認証連携、人事システム連携)、複合機のLDAPアドレス帳検索、ネットワーク機器のLDAP認証です。とくに複合機・機器類の「LDAPサーバー設定」は平文の単純バインドになっていることが多いので、真っ先に疑ってください。修正は、機器・アプリ側の設定をLDAPS(636番)またはサインされたSASLバインドに切り替えることです。

5.2. 強制する

接続元を直し終えたら、グループポリシーで強制します。³

• ドメインコントローラー側: Default Domain Controller Policy の セキュリティ オプション にある「ドメイン コントローラー: LDAP サーバー署名必須」を「署名を必要とする」に設定
• クライアント側: 「ネットワーク セキュリティ: LDAP クライアント署名の要件」を「署名を必要とする」に設定

確認は ldp.exe でできます。389番ポートに接続し、単純バインドを試みて、次のエラーになれば構成は効いています。³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAPチャネルバインディング ── LDAPS側の防御

「うちはLDAPSにしているから大丈夫」──ここに残る穴を塞ぐのがチャネルバインディングです。LDAPSは通信を暗号化しますが、それだけでは「クライアントに認証させ、その認証情報を攻撃者自身の別のTLS接続に中継する」形のリレーを防ぎきれません。チャネルバインディングトークン(CBT)は、認証をそのTLSチャネル自体に結びつけることで、別チャネルへの中継を検出可能にします。

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

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

監査に使うイベントは次のとおりです。2020年3月10日の更新でチャネルバインディング関連のイベントが追加され、さらに2023年以降の更新で監査イベントが拡充されました。⁴

進め方はLDAP署名と同じで、マイクロソフトの案内も「全ドメインコントローラーのDirectory Serviceログで、署名失敗の2889、チャネルバインディング失敗の3039、監査イベントの3074・3075を監視し、問題のある機器を特定して提供元に確認し、対応を確認してから強制する」というものです。⁴

ひとつ強調しておきたいのは、マイクロソフトはこれらの更新で既定値を変えていないことです。2020年3月10日の更新および当面の更新は、LDAP署名・LDAPチャネルバインディングの既定ポリシーを変更しないと明言されています。⁴ SMB署名(24H2で既定が変わった)とは対照的に、LDAP側は管理者が自分で締めない限り、ずっと緩いままです。逆に言えば、締めるタイミングを自分で選べるうちに計画的に進められます。

7. 業務アプリと機器の直し方(判断表)

監査で見つかった接続元を、原因別に整理します。

自社開発の.NETアプリでLDAPを触っている場合、まず疑うのは「単純バインドを平文で投げていないか」です。

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

// 良い例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監査(送信NTLMトラフィック=すべて監査する)を有効にしている環境なら、イベント8001が出ていないことも傍証になります。監査ポリシーが無効のままでは「8001が出ていない」ことに意味はない点に注意してください。なお良い例2の単純バインドはTLSで暗号化されますが、6章で述べたとおりCBT検証の対象になるのはWindows認証の側です。ドメイン環境で選べるなら良い例1を基本にしてください。DirectoryEntry(ADSI)経由なら、AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing を明示するのが確実です。NTLMシリーズ1本目で書いた原則(接続先はIPアドレスではなくFQDNで書く)は、KerberosでのSASLバインドを成立させるための前提として、ここでも効いてきます。

8. まとめ

• SMB署名とLDAP署名・チャネルバインディングは、NTLM依存を潰し終えるまでの間もリレー攻撃を成立させないための防御であり、同時にNTLM廃止後も残す恒久的な強化策です(署名の改ざん検知とチャネルバインディングはKerberos認証のセッションにも効きます)。NTLM削減と同じ施策の両輪として進めます。¹⁵
• SMB署名の既定値はすでに変わりました。Windows 11 24H2(Enterprise/Pro/Education)は送受信とも必須、Windows Server 2025は送信必須です。OS更新計画がそのまま締め切りになります。²
• 事故のパターンは決まっています。署名非対応機器の 0xc000a000 と、ゲストアクセスのブロックです。24H2以降の監査機能で先に洗い出せます。²¹
• LDAPはイベント2887・2889(署名)、3039・3040・3074・3075(チャネルバインディング)で接続元を特定し、直してから強制します。³⁴
• LDAP側の既定値は更新では変わりません。管理者が締めない限り緩いままです。計画的に進められるうちに進めてください。⁴
• 自社アプリは「平文の単純バインド」と「IPアドレス直打ち」を潰せば、大半は片づきます。

関連記事

• NTLM廃止で業務アプリは止まるか ── 監査ログの取り方と、依存を潰す順番
• 図解でわかるNTLMとKerberos ── なぜNTLMに「落ちる」のか
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める
• Windows 10サポート終了(EOL)対応の判断 ── 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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。