NTLM廃止で業務アプリは止まるか ── 監査ログの取り方と、依存を潰す順番

「NTLMが廃止されるらしい。うちは大丈夫か」──2024年6月にマイクロソフトがNTLMの全バージョンを非推奨(deprecated)と発表して以来、この質問を受ける機会が増えました。答えは、大丈夫かどうかは調べれば分かるし、いま調べれば間に合うです。

NTLMの廃止は「ある日パッチが当たって全社が止まる」種類の変更ではありません。OSを新しくするたびに少しずつ締まっていく変更で、しかもまだNTLMが動いているいまだけ、「自社のどこがNTLMに依存しているか」を安全に一覧化できます。全部止めてから壊れた場所を探すのは、いちばんやってはいけない順番です。

この記事は、その一覧を作って潰していくための実務手順に絞ります。プロトコルの仕組みそのもの(なぜNTLMが危ないのか、なぜKerberosに落ちないのか)は、対になる記事「図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか」に分けました。

1. まず結論

• NTLMは2024年6月に非推奨になりました。対象はLANMAN・NTLMv1・NTLMv2を含む全バージョンで、「もう積極的な機能開発はしない」という宣言です。同時に「次期Windows Serverと次の年次リリースのWindowsでもNTLMの利用は動作し続ける」とも書かれています。¹
• すでに削除された部分があります。NTLMv1は、Windows 11 バージョン24H2とWindows Server 2025で削除されました。¹
• 廃止は3フェーズで進みます。フェーズ1が利用状況の可視化と監査、フェーズ2(2026年後半)がNTLMに頼らざるを得ない場面をなくすための機能(IAKerb、ローカルKDC)、フェーズ3が次期メジャーリリースでのネットワークNTLM認証の既定無効化です。²
• いまやるべきことは1つだけです。監査モードを回して「どの端末の、どのアプリが、どのサーバーに対して」NTLMを使っているかの一覧を作ることです(4章)。
• ドメインアカウントの調査は、ドメインコントローラーから始めます。イベント8004 → メンバーサーバーの8003 → クライアントの8001、という順にたどると、最後にアプリ名まで届きます(4.2節)。ただしローカルアカウントでの認証はドメインコントローラーを経由しないので8004が出ません。この経路はサーバー側の8003とクライアント側の8001から拾います。³
• 原因の大半は「名前」です。IPアドレス直打ちとSPN未登録が二大要因で、どちらもアプリを作り直さずに直せます(5章)。³²
• 1台だけで安全に試す方法があります。Windows 11 24H2 / Windows Server 2025なら NET USE \\server\share /BLOCKNTLM で、ポリシーを一切変えずに「NTLMなしで繋がるか」を確認できます(7章)。⁴
• 自作アプリは、NTLMを名指ししている箇所をNegotiateに変えます。マイクロソフト自身が「NTLMセキュリティパッケージに直接アクセスするな」と書いています(8章)。⁵

この記事の知識マップ

NTLMは2024年6月に全バージョンが非推奨になり、NTLMv1はすでにWindows 11 24H2・Windows Server 2025で削除されています。廃止に備えるには、Restrict NTLMの監査ポリシーを有効にしてNTLM/Operationalログを集め、ドメインコントローラーの8004からサーバーの8003・クライアントの8001へとたどって原因アプリを特定し、IPアドレス直打ちとSPN未登録から潰していきます。SMBクライアント側のNTLMブロックで1接続ずつ裏取りしながら段階的に締めるのが実務の順番です。

flowchart LR
    accTitle: NTLM非推奨化に伴う監査・移行の知識マップ
    accDescr: NTLM非推奨化の3フェーズ、Restrict NTLMの監査ポリシーとNTLM/Operationalログ(イベント8001・8003・8004)によるドメインアカウント・ローカルアカウントの利用状況の可視化、Get-WinEventとProcess Monitorによる原因特定、SMBクライアント側のNTLMブロックでの実地確認、開発者側のNegotiateへの置き換えの関係を示す図
    ntlm["NTLM"]
    ntlm_operational_log["NTLM/Operationalログ"]
    restrict_ntlm["「NTLMを制限する」ポリシー群"]
    group_policy["グループポリシー"]
    get_winevent["Get-WinEvent"]
    procmon["Process Monitor(procmon.exe)"]
    domain_account["ドメインアカウント"]
    domain_controller["ドメインコントローラー"]
    local_account["ローカルアカウント"]
    workgroup["ワークグループ構成"]
    kerberos["Kerberos"]
    tryipspn["TryIPSPN"]
    spn["SPN"]
    smb_ntlm_block["SMBクライアント側のNTLMブロック"]
    windows_11_24h2["Windows 11 バージョン24H2 / Windows Server 2025"]
    net_use_blockntlm["NET USE /BLOCKNTLM"]
    ntlmv1["NTLMv1"]
    security_log_auth_package["セキュリティログの「パッケージ名 (NTLM のみ)」"]
    negotiate["Negotiate"]
    ntlm_hardcoded_auth_type["認証タイプへのNTLM名指し"]
    iakerb["IAKerb"]
    local_kdc["ローカルKDC"]
    ntlm_relay_attack["NTLMリレー攻撃"]
    smb_signing["SMB署名"]
    pass_the_hash["Pass-the-Hash"]
    ntlm -->|"で構成できる"| restrict_ntlm
    restrict_ntlm -->|"で構成できる"| group_policy
    restrict_ntlm -->|"で確認できる"| ntlm_operational_log
    ntlm_operational_log -->|"で確認できる"| get_winevent
    ntlm_operational_log -->|"で確認できる"| procmon
    domain_account -->|"前提とする"| domain_controller
    domain_account -.->|"で確認できる"| ntlm_operational_log
    local_account -->|"前提とする"| ntlm
    workgroup -->|"両立しない"| kerberos
    tryipspn -.->|"前提とする"| spn
    smb_ntlm_block -->|"前提とする"| kerberos
    smb_ntlm_block -->|"前提とする"| windows_11_24h2
    smb_ntlm_block -->|"で確認できる"| net_use_blockntlm
    smb_ntlm_block -->|"で構成できる"| group_policy
    smb_ntlm_block -->|"軽減する"| ntlm
    ntlmv1 -->|"両立しない"| windows_11_24h2
    ntlmv1 -->|"で確認できる"| security_log_auth_package
    negotiate -->|"の後継"| ntlm_hardcoded_auth_type
    iakerb -.->|"軽減する"| ntlm
    local_kdc -.->|"軽減する"| ntlm
    kerberos -->|"前提とする"| spn
    ntlm -.->|"原因になり得る"| ntlm_relay_attack
    smb_signing -->|"軽減する"| ntlm_relay_attack
    ntlm -.->|"前提とする"| domain_controller
    ntlm_operational_log -->|"より先に行うべき"| smb_ntlm_block
    tryipspn -.->|"軽減する"| ntlm
    negotiate -->|"利用する"| kerberos
    negotiate -->|"利用する"| ntlm
    ntlm -->|"原因になり得る"| pass_the_hash

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

2. 「非推奨」は何を意味するのか

最初に用語を整理しておきます。ここを曖昧にしたまま社内に説明すると、「もう使えないらしい」と「まだ何年も平気らしい」が同時に流れて話が混乱します。

マイクロソフトの非推奨機能一覧に載っているNTLMの記述は、要約すると次の3点です。¹

1. LANMAN、NTLMv1、NTLMv2を含むすべてのバージョンのNTLMが、積極的な機能開発の対象外であり、非推奨である。
2. NTLMの利用は、次期Windows Serverと次の年次リリースのWindowsでも動作し続ける。
3. NTLMの呼び出しはNegotiateの呼び出しに置き換えるべきである。NegotiateはKerberosでの認証を試み、必要なときだけNTLMにフォールバックする。

そして更新情報として、NTLMv1はWindows 11 バージョン24H2およびWindows Server 2025で削除されたことが追記されています。¹

つまり現在地は「非推奨(deprecated)」であって「削除(removed)」ではありません。ただしNTLMv1だけは、非推奨を通り越してすでに削除フェーズに入っています。古い複合機やNASがNTLMv1でしか認証できない場合、Windows 11 24H2への更新がそのまま障害になります。これは将来の話ではなく、いま起きている話です。

もうひとつ押さえておきたいのは、NTLMには「代替が存在しない用途」が残っていることです。マイクロソフトは、ワークグループ構成のシステムでのWindows認証と、ドメインコントローラー以外でのローカルログオン認証には、依然としてNTLMが使われ、使われなければならないと明記しています。⁶ フェーズ2で予定されているローカルKDCは、まさにこの「ローカルアカウントのためにNTLMが必要」という穴を埋めるための機能です。²

2.1. 3フェーズの現在地

廃止のロードマップは3フェーズです。時点依存の情報なので、基準日を添えて整理します(下の表は2026年7月時点の状況です)。

この表で確認してほしいのは、いま自分の手で動かせるのはフェーズ1だけだということです。フェーズ2の機能は6章の判断表で「解になりうる」と書いている箇所がありますが、いずれも提供状況の確認が前提です。提供時期は変わりうるので、この表の内容は自社の判断時点で必ず取り直してください。

3. なぜ消えるのか ── 3分だけ

移行の判断材料として最低限だけ押さえます。詳しい図解は対になる記事に譲ります。

マイクロソフトはポリシー設定のドキュメントで、NTLMおよびNTLMv2認証は、SMBリレー、中間者攻撃、総当たり攻撃を含むさまざまな悪意ある攻撃に対して脆弱であると、はっきり書いています。⁷ 根っこにあるのは、Kerberosとの比較で語られる次の性質です。⁸

• 相互認証がない。NTLMでは、クライアントがサーバーの身元を検証することも、サーバーが別のサーバーの身元を検証することもできません。NTLMは「サーバーは本物である」と仮定できるネットワーク環境向けに設計されたものです。Kerberosはその仮定を置きません。この差が、偽サーバーへ認証情報を送らせるリレー攻撃の成立条件になります。
• サーバーが毎回ドメインコントローラーに問い合わせる(ドメインアカウントの場合)。NTLMでは、アプリケーションサーバーはドメインアカウントのクライアントを認証するたびにドメインコントローラーへ接続する必要があります(サーバーにローカルなアカウントなら、サーバーが自分のアカウントデータベースを引いて判定します)。⁶ Kerberosでは更新可能なセッションチケットがこのパススルー認証を置き換え、サーバーはPAC(特権属性証明書)の検証が必要な場合を除きドメインコントローラーへ行く必要がありません。
• 認証材料がパスワードのハッシュそのもの。NTLMの資格情報は、ドメイン名・ユーザー名・パスワードの一方向ハッシュで構成され、クライアントはこのハッシュでチャレンジを暗号化して応答を返します。⁵ ハッシュを盗めば、平文パスワードを知らなくてもなりすませる、という性質がここから出てきます。

「相互認証がない」の実務的な意味は、SMB共有に繋ごうとしただけで、偽のサーバーに認証情報を渡してしまい得るということです。マイクロソフトがSMBクライアント側のNTLMブロック機能を用意した理由も、「悪意あるサーバーにNTLM要求を送らせる手口を防ぐ」と説明されています。⁴

4. 監査 ── どこでNTLMが使われているかを一覧にする

ここが本題です。マイクロソフトのガイドも、制限ポリシーを実装する前に現在のNTLM認証トラフィックの状態を発見し監査することが必要であると明記しています。⁹

4.1. 監査モードを有効にする

設定するのは3つのポリシーです。場所はいずれも コンピューターの構成\Windowsの設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション で、再起動は不要です。ローカルに保存した場合も、グループポリシーで配布した場合も、設定が適用された時点で有効になります。⁷

ただし「再起動が不要」と「すぐ全台に効く」は別の話です。ドメインのGPOで配る場合、GPOを保存した時点で更新されるのはAD/SYSVOL上のポリシーだけで、各端末が実際に監査を始めるのは次のバックグラウンド更新か gpupdate /force を打ったあとです。監査期間の起点は「GPOを保存した日時」ではなく「対象端末に適用が行き渡った日時」として数えてください。ここを取り違えると、最初の1回の集計だけ対象台数が少ない、という形で結果が歪みます。

3つ目の「リモートサーバーへの送信NTLMトラフィック」にはすべて許可する / すべて監査する / すべて拒否する / 未定義の4つの値があり、未定義は「すべて許可する」と同じ扱いです。マイクロソフトの推奨も明快で、いきなり「すべて拒否する」を選ばず、まず「すべて監査する」にして運用ログを確認し、どのサーバーが認証要求を受けているかを把握してから例外リストを作れ、というものです。⁷

記録先はイベントビューアー > アプリケーションとサービス ログ > Microsoft > Windows > NTLM(Microsoft-Windows-NTLM/Operational)です。この監査には対応するセキュリティ監査イベントポリシーが存在しないため、セキュリティログではなくこのチャネルを見ます。⁷

現場でいちばん取り違えやすいのが、「どのマシンに、どのポリシーを入れて、どのイベントを見るか」の対応です。上の表の3つのポリシーを①②③として、チェックリストにします。

ログはどのマシンでも同じ Microsoft-Windows-NTLM/Operational です。①はドメインコントローラーにしか効かず、②③を入れ忘れた端末は「NTLMを使っていない端末」ではなく「記録していない端末」になります。この違いが集計を歪める最大の原因です。

注意: 監査モードは記録するだけで何もブロックしません。一方で、台数が多い環境ではログ量が一気に増えます。イベント収集(WEF)を使っていない場合は、ログサイズの上限と保存期間を先に見直してから有効にしてください。マイクロソフトのガイドも、環境の複雑さによっては分析に数か月かかりうるとしています。³

4.2. 追跡は「ドメインコントローラーから下流へ」

集まったイベントをどう読むかには、決まった順番があります。マイクロソフトのガイドが示す追跡経路は次のとおりです。³

flowchart TD
    DC["ドメインコントローラー<br/>イベント 8004"]
    MS["メンバーサーバー<br/>イベント 8003"]
    CL["クライアント<br/>イベント 8001"]
    APP["原因のアプリケーション"]

    DC -->|"セキュア チャネル名 =<br/>調べるべきサーバー"| MS
    MS -->|"ワークステーション名 =<br/>調べるべきクライアント"| CL
    CL -->|"クライアント プロセス名"| APP
    MS -.->|"PID が 4 (SYSTEM) なら<br/>SMB 経由"| CL

図1: NTLM監査イベントの追跡順序

各イベントで見るべき項目は次のとおりです。³

この経路で特に価値があるのは、8001の「ターゲット サーバー」と「クライアント プロセス名」です。前者は「なぜKerberosにならなかったか」を、後者は「誰が悪いか」を直接教えてくれます。マイクロソフトのガイドも、この情報からユーザーがWebサーバーのIPアドレスに接続していて、Kerberosが使えたはずのNetBIOS名やFQDNを使っていないことを特定できると説明しています。³

なお、ドメインコントローラーに8004が出ないケースもあります。ローカルユーザーアカウントでファイルサーバーに接続している場合、その認証はドメインコントローラーを経由しないためです。³ 「DCのログを見たら少なかったので大丈夫」と判断してはいけません。

4.3. PowerShellで集計する

イベントビューアーのGUIで数千件を眺めるのは現実的ではないので、Get-WinEvent でまとめます。まず、そのマシンにどのイベントが何件出ているかを確認します。

# NTLM/Operational のイベントをID別に集計する(管理者権限で実行)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

イベントが出ていることを確認したら、クライアント側の8001を「接続先サーバー × 呼び出し元プロセス」で束ねます。イベントのフィールド構成はイベントIDごとに違うので、まず1件を Format-List で開いて構造を確認してからインデックスを決めるのが安全です。

# まず1件だけ中身を確認する
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# 構造化フィールドを見る場合
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

構造が分かったら、XMLの Name 属性で取り出して集計します。属性名はOSのバージョンによって差があるため、名前で引くほうが位置指定より壊れにくくなります。

# 直近7日の 8001 を「接続先 × 呼び出し元プロセス」で集計する
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # 実際に存在したフィールド名だけを、優先順位をつけて拾う
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

最後の集計は、Count(件数)と Name(接続先, 呼び出し元プロセス をカンマで連結したもの)の2列で返ります。つまり出力はこの形です(値は説明のための例です)。

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

見るべきは Name の前半、つまり接続先です。行ごとの読み方は次のとおりです。

件数の絶対値そのものにはあまり意味がありません。「IPアドレス宛の行が上位に来ているか」「実行ファイル名まで割れている行がいくつあるか」の2点を見てください。前者は直せば確実に減る依存で、後者は担当者を割り当てられる依存です。

フィールド名はOSのバージョンによって差があるため、候補を優先順位つきの配列で並べ、実在するものだけを拾う形にしています。ここで -match 'Process' のような部分一致を使うと、ClientProcessId のようなPIDのフィールドまで引っかかり、実行ファイル名ではなく毎回変わるPIDで集計してしまうことがあります(ハッシュテーブルのキー順は不定なので、どちらが取れるかも安定しません)。Process 列が全部空になったら、候補名が実際のスキーマと合っていないサインなので、前の手順で確認した名前を配列に足してください。

複数台から集めるなら、PowerShell Remotingで並列に回すのが早いです(「PowerShell Remoting(WinRM)入門」)。Get-WinEvent の絞り込みは -FilterHashtable を使うかどうかで所要時間が桁違いになるので、その勘所は「Get-WinEventでイベントログを実務的に調べる」にまとめています。

4.4. セキュリティログ側から見る ── NTLMv1がまだ使われていないか

NTLM/Operationalとは別に、セキュリティログのログオンイベントからNTLMのバージョンを確認する方法もあります。手順は、セキュリティログで「認証パッケージ」を検索し、各イベントの「詳細な認証情報」を見る、というものです。³

詳細な認証情報:
    ログオン プロセス:          NtLmSsp
    認証パッケージ:             NTLM
    移行されたサービス:         -
    パッケージ名 (NTLM のみ):   NTLM V1
    キーの長さ:                 128

この「パッケージ名 (NTLM のみ)」が、NTLMプロトコル群のどのサブプロトコルが使われたかを示します。³ NTLM V1 が出ているホストは、そのままWindows 11 24H2 / Windows Server 2025に上げると認証が通らなくなる候補です。NTLMv1はこれらのバージョンで削除されているためです。¹ 監査を回すとき、この観点だけは優先度を上げて拾ってください。

4.5. PIDが4(SYSTEM)ばかりで進めないとき

監査を始めると、ほぼ必ずこの壁に当たります。SMB(共有フォルダ)のようにリダイレクター経由で通信するアプリでは、認証を要求する主体がカーネルモードのリダイレクターになるため、イベントに残るPIDは常に4(SYSTEM)になります。³

マイクロソフトのガイドが示す対処は次のとおりです。³

1. NTLM資格情報を送っているクライアント(8001の「コンピューター」)に、プロセス監視ツールを入れる。
2. 相手サーバーのコンピューター名とIPアドレスの両方でパスをフィルターする。長時間の採取が必要ならバックグラウンドモードで回す。
3. 採取結果を、サーバー側イベント8003のタイムスタンプと突き合わせる。ユーザー・パス・認証識別子が対応するので、そこから呼び出し元アプリケーションが特定できる。

ツールはProcess Monitor(ProcMon)です。フィルターの当て方と読み方は「Process Monitor(ProcMon)実践ガイド」にまとめてあります。

実務的なコツを1つ足すと、この段階までイベントログだけで「どの端末か」を絞り切ってから、その端末1台にだけProcMonを仕掛けるのが圧倒的に速いです。全台にProcMonを配るのは現実的ではありません。

5. NTLMに落ちる典型パターン

監査で場所が分かったら、次は原因の分類です。マイクロソフトのガイドは、理屈のうえではKerberosに対応していても、NTLMを使ってしまうアプリケーションとして次の4つを挙げています。³

• さまざまなセキュリティ構成やプロバイダーを選択できるアプリケーション
• SPN(サービスプリンシパル名)が正しく構成されていないアプリケーション
• 設定ミスやベンダーのドキュメントのせいで、DNS名ではなくIPアドレスを使っているアプリケーション
• レガシーなコードベースを持ち、NTLM専用の部分が残っているアプリケーション

マイクロソフト日本のサポートブログは、NTLMが使われる代表的な原因として、IPアドレス指定でのサーバーアクセス、Kerberosに必要なポートのファイアウォールによる制限、SPN未登録、信頼関係先への認証、ワークグループ環境での認証を挙げています。²

これらを、現場で出会う形に整理すると次の表になります。右の2列は優先度をつけるための基準です。「影響範囲」は止まったときに困る広さ、「修正容易性」は自社の判断だけで直せるかどうかを表します。この2つが分かっていれば、そのまま計画書の着手順になります。

着手順は、この2列から機械的に決まります。

1. 影響範囲にかかわらず最優先なのは、NTLMv1しか話せない機器と NTLM V1 が記録されたホストです(4.4節)。ここだけは「期限がすでに来ている」ためで、優先度の計算の外に置きます。¹
2. 次が影響範囲=大 かつ 修正容易性=高、つまりIPアドレス直打ちです。件数が多く、自社の判断だけで直せます。最初の1か月はここに集中してください。
3. その次が修正容易性=中のSPN関連。名前の統一とセットで進めます。
4. 修正容易性=低のもの(機器依存、経路、フェーズ2待ち)は、着手が遅れるのではなくリードタイムが長いだけなので、ベンダーへの照会と予算取りだけは1〜3と並行して先に始めます。

「すぐ直せる」と「SPN登録で直る」に分類されたものが、監査結果の大半を占めるはずです。ここを潰すだけで、残る例外はかなり少なくなります。

6. 直し方の判断表

7. SMBのNTLMブロック ── 実地確認の最短ルート

監査ログは「使われている」ことは教えてくれますが、「止めたらどうなるか」は教えてくれません。そこで役に立つのが、Windows Server 2025とWindows 11 バージョン24H2で追加された、SMBクライアント側のNTLMブロックです。⁴

この機能は、SMBクライアントがリモートへの送信接続でNTLM認証を使うことをブロックします。マイクロソフトは、これによって悪意あるサーバーへNTLM要求を送らせる手口を防ぎ、総当たり・クラッキング・Pass-the-Hash攻撃に対抗できるとし、さらに組織の認証プロトコルをKerberosへ切り替えるうえでNTLMブロックが必要だと位置づけています。同時に、NTLMを完全に無効化しなくてもこの保護層だけを有効にできるとも書かれています。⁴

前提条件は次の2つです。⁴

• SMBクライアントがWindows Server 2025以降、またはWindows 11 バージョン24H2以降であること
• 接続先のSMBサーバーがKerberosを使えること(SMBサーバー側のOSは、PKU2UかKerberosが使えるものであれば何でもよい)

7.1. まず1台・1接続だけで試す

いきなりポリシーを配るのではなく、接続単位でブロックを指定できることを使います。これが実地確認の最短ルートです。

# その接続だけNTLMを禁止して繋いでみる(繋がれば、その共有はNTLMなしで足りている)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# PowerShellのマッピングでも同じことができる
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

繋がれば、その経路はNTLMなしで成立しているということです。失敗するなら、そこがNTLM依存箇所です。ポリシーを一切変えずに、1接続ずつ「本番で止まるかどうか」を確認できるので、監査ログの裏取りに向いています。

結果の確認先は3か所です。(1)接続の成否はコマンドの結果そのもので、成功すればマッピングが作られて net use の一覧と Get-SmbConnection -ServerName <サーバー名> に現れ、失敗すればエラーで終わりマッピングは残りません。(2)本当にNTLM起因かは、下の手順3(フラグ無しでの接続)と対にして判断します。フラグ無しでも失敗するなら別の問題です。(3)何で認証したかまで確定させたいなら、この節の最後で述べる方法(klist とサーバー側のセキュリティログ)を使います。エラーメッセージの文言だけでNTLM依存と断定しないでください。

ただし、この確認には手順が要ります。何も考えずに実行すると、両方向に誤判定します。

$server = 'fileserver.corp.example.com'

# 1. そのサーバーへのマッピングを「1つ残らず」外す
#    別の共有が1つでも残っていると、サーバー単位のセッションが生き続ける
net use | Select-String $server              # まず何が繋がっているか見る
net use \\$server\share  /delete
net use \\$server\other  /delete             # 同じサーバーの他の共有もすべて

# 2. セッションが本当に消えたことを確認する(空になるまで次へ進まない)
Get-SmbConnection -ServerName $server

# 3. まずフラグ無しで繋がることを確かめる(ここで失敗するならNTLM以外の問題)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # ここでも空に戻す

# 4. そのうえで /BLOCKNTLM を付けて試す
net use \\$server\share /BLOCKNTLM

• 手順1〜2が要る理由: SMBのセッションは共有単位ではなくサーバー単位です。そのサーバーへの認証済みセッションが残っていると、リダイレクターは認証をやり直さずにそれを再利用します。/BLOCKNTLM が効くのはそのマッピングのために行われる認証だけで、すでに確立済みのセッション(NTLMで張られたかもしれないもの)を遡って検証はしません。つまり、テスト対象の共有だけを /delete しても不十分です。同じサーバーの別の共有が繋がったままなら、NTLM依存があるのに成功してしまいます。Get-SmbConnection が何も返さない状態まで落としてください。自分のマッピング以外にも、常駐アプリやバックアップジョブがセッションを掴んでいることがあります。確実にやるなら、そのサーバーに一度も繋いでいない端末から試すのがいちばん速いです。
• 手順3が要る理由: 名前解決の失敗、資格情報の誤り、共有そのものへのアクセス権不足でも /BLOCKNTLM 付きの実行は失敗します。フラグ無しでも失敗するなら、それはNTLM依存ではなく別の問題です。

ここで言えるのは「NTLMを必要としなかった」までで、「Kerberosで認証された」までは言えない点に注意してください。この機能の前提条件は「Kerberosを使えるSMBサーバー」ですが、接続先はPKU2Uが使えるOSでもよいとされています。⁴ つまり成功の理由がKerberosではなくPKU2Uである可能性が残ります。ドメイン参加済みのファイルサーバーが相手ならまず問題になりませんが、実際に何で認証したかまで確定させたいときは、接続後にクライアントで klist を実行して当該サーバーの cifs/ チケットが取得されているかを見るか、サーバー側のセキュリティログでログオンイベントの認証パッケージ(4.4節)を確認してください。

7.2. 端末単位で有効にする

裏取りが済んだら、パイロット端末で端末全体のブロックに進みます。⁴

# SMBクライアント全体でNTLMをブロックする(管理者権限)
Set-SmbClientConfiguration -BlockNTLM $true

グループポリシーの場合は コンピューターの構成 > 管理用テンプレート > ネットワーク > Lanman ワークステーション の 「NTLM をブロックする (LM、NTLM、NTLMv2)」 を有効にします。⁴

7.3. どうしても残る相手は例外リストへ

ドメインに参加していないSMBサーバーなど、どうしてもNTLMが必要な相手は例外にできます。グループポリシーの Lanman ワークステーション > NTLM サーバー例外リストをブロックする を有効にし、許可する相手のIPアドレス・NetBIOS名・FQDNを列挙します。⁴

例外リスト自体を作るPowerShellコマンドレットは用意されていないため、初回はグループポリシーエディターで設定する必要がありますが、いったん作ったあとの個別追加はレジストリ操作でできます。⁴

# 既存の例外リストにエントリを追加する
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

注意: マイクロソフトのドキュメントに載っているサンプルは、値がまだ存在しない場合の分岐が @("") を設定するだけになっており、追加したかったエントリがそのまま捨てられます。⁴ 初回実行では例外が1件も入らず、2回目の実行でようやく入る、という挙動になるので、上のコードでは未作成の場合も追加対象をそのまま書き込むようにしています。とはいえ、そもそもこのレジストリ値はグループポリシーが管理する領域です。恒久的な例外はグループポリシー側で管理し、この操作は緊急時の一時対応に留めてください。次のポリシー適用で上書きされます。

注意: この機能はSMBクライアント側の機能です。⁴ SMB以外の経路(自社アプリのHTTP通信、SQL Serverへの接続、WinRMなど)でのNTLMは、これでは止まりません。そちらは5章の分類に従って個別に潰す必要があります。

8. 開発者から見たNTLM ── Negotiateを使う

自社でWindowsアプリを作っている場合、直す箇所ははっきりしています。マイクロソフトは次のように明記しています。⁵

アプリケーションはNTLMセキュリティパッケージに直接アクセスすべきではありません。代わりにNegotiateセキュリティパッケージを使うべきです。Negotiateは、認証に関わるシステムがサポートしていれば、より高度なセキュリティプロトコルを利用できるようにします。現在、NegotiateセキュリティパッケージはKerberosとNTLMのどちらかを選択します。Negotiateは、認証に関わるシステムのいずれかがKerberosを使えない場合を除き、Kerberosを選択します。

つまり「NTLM」と書いてある箇所を「Negotiate」に変えるのが原則です。非推奨機能一覧の記述も同じで、NTLMの呼び出しはNegotiateの呼び出しに置き換えるべき、とされています。¹

8.1. .NETでよくある「NTLM名指し」

// 悪い例: 認証タイプにNTLMを名指ししている
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// 良い例: 変えるのは認証タイプだけ。資格情報はそのまま渡す
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

ここで変えるのは認証タイプの文字列だけです。credential を CredentialCache.DefaultNetworkCredentials に差し替えると、認証プロトコルだけでなく認証する主体まで変わります。指定していたアカウントではなく、そのプロセスを実行しているアカウント(サービスアカウントやログオン中のユーザー)で認証しにいくことになり、接続先の権限設定によっては動かなくなります。プロトコルの置き換えと資格情報の見直しは、別々の変更として分けて進めてください。

いっぽう、そもそもログオン中のユーザーの資格情報で認証したい(統合Windows認証)なら、もっと単純に書けます。こちらは「誰として認証するか」を意図的に変える場合の書き方です。

// 統合Windows認証(現在のログオンユーザーで認証する)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

HttpClient そのものの扱い(using で包まない、生成パターン、タイムアウト設計)は「HttpClientをusingで包むな」に整理しています。

SSPIを直接扱う必要がある場合は、.NET 7以降で追加された System.Net.Security.NegotiateAuthentication を使うと、Negotiate越しの認証をマネージコードから扱えます。ここでもパッケージ名にNTLMを指定しないことが要点です。

8.2. コードより先に見るべき「接続先の書き方」

コードを直しても、接続先がIPアドレスのままなら結局NTLMに落ちます。既定では、ホスト名がIPアドレスの場合Windowsはそのホストに対してKerberos認証を試みず、NTLMなど有効な他のプロトコルにフォールバックするからです。¹⁰ 具体的には次を洗ってください。

• 設定ファイル(appsettings.json、App.config、iniファイル)に書かれたサーバー名
• SQL Serverの接続文字列のサーバー指定(Data Source)
• UNCパスを組み立てている箇所。ハードコードされたIPアドレスがないか
• インストーラーやキッティング手順書のデフォルト値
• 過去の障害対応で「名前解決が不安定だから」とIPに書き換えたまま戻していない箇所

最後の項目は本当によく見つかります。IPアドレス直打ちは、当時は正しい応急処置でしたが、いまは技術的負債です。

8.3. サービス側を作っているなら

自作のWindowsサービスやIISアプリをKerberosで受けたい場合は、チケットを復号するアカウントに、クライアントがアクセスに使う名前でSPNを登録する必要があります。SPNが登録されていないアプリケーションは、Kerberos対応をうたっていてもNTLMに落ちる、という代表例としてマイクロソフト自身が挙げているとおりです。³

登録先を「サービスを実行しているアカウント」と単純に考えると、IISでつまずきます。IISのWindows認証は既定でカーネルモード認証が有効で、このときKerberosチケットを復号するのはアプリケーションプールのIDではなくHTTP.sysが使うマシンアカウントです。専用のドメインアカウントでアプリケーションプールを動かしているからといって、そのアカウントにサイトのHTTP SPNを登録すると、SPNの持ち主と実際に復号するアカウントが食い違い、NTLMに落ちるどころか KRB_AP_ERR_MODIFIED で認証そのものが失敗します。

要点は「SPNの登録先と、チケットを復号するIDを一致させる」ことです。取れる形は次の2つです。

• マシンアカウントで復号する(既定のまま):サイトをホスト名で公開しているなら、そのホスト名のHTTP SPNをマシンアカウントに登録する。
• アプリケーションプールのIDで復号する:useAppPoolCredentials を有効にしたうえで、HTTP SPNをアプリケーションプールのアカウントに登録する。

どちらを選ぶかは、複数サーバーで同じサービスアカウントを共有しているか(共有しているならプールIDに寄せる形が扱いやすい)で決まります。なおSPNは1つのアカウントにしか登録できないので、切り替えるときは古い登録の削除を忘れないでください。重複登録はKerberos認証そのものを壊します。

クライアントに偽装して他のサーバーへアクセスする設計(委任)を採っている場合は、NTLMとKerberosで扱いが変わります。Kerberosは、サービスがクライアントの代理として他のサービスへ接続する委任メカニズムをサポートしていますが、NTLMが提供するのはローカルでの偽装に必要な認可情報までです。⁸ 偽装まわりの実装は「Windowsの偽装(Impersonation)とトークン」で扱っています。

9. 段階的に締めていくロードマップ

以上をまとめると、進め方は次の順番になります。どの段階も「戻せる」ことが条件です。

9.1. SMBを止めても、それはNTLM対策の半分

段階4〜6が扱うのはSMBだけです。7章で触れたとおり、SMBクライアントのNTLMブロックはSMBクライアント側の機能であり、⁴ それ以外の経路には効きません。段階2で「HTTPで認証している」「SQL ServerがNTLMになっている」「WinRMがNTLMを使っている」と分類したものは、段階6まで進めても手つかずのまま残ります。しかもSMBの例外リストにも載らないので、件数を数えても見えません。

そこを締めるのが段階6bです。使うのは4章で監査モードにした、あの3つのポリシーそのものです。手順は同じ形をたどります。¹¹

1. 「リモートサーバーへの送信NTLMトラフィック」をすべて監査するのまま、残っている接続先を洗い出す
2. どうしても必要な相手を「リモートサーバーの例外を追加する」に登録する
3. パイロット端末ですべて拒否するに切り替え、業務が一巡するのを待つ
4. 問題がなければ展開する

ドメイン全体に対しては「このドメインでのNTLM認証」を、同じく監査 → 例外(「このドメインでのサーバー例外を追加する」)→ 拒否の順で進めます。¹² マイクロソフトも、拒否オプションを選ぶ前に対応する監査ポリシーを同じオプションに設定して影響を評価すべきだとしています。¹²

「SMBをブロックしたからNTLM対策は完了」ではありません。完了の指標にするなら、SMBの例外リストとRestrict NTLMのサーバー例外リストの両方を数えてください。

9.2. 監査期間は「日数」ではなく「業務の一巡」で決める

段階1でいちばん失敗しやすいのが、期間の決め方です。「2週間集めたから完了」としてしまうと、その2週間に走らなかった処理は一覧に載りません。そして載らなかったものは、段階6でブロックを配ったあとに初めて壊れます。

具体的に取りこぼしやすいのは次のようなものです。

• 月次・四半期の締め処理。月末バッチが共有フォルダやDBへIPアドレス直打ちで繋いでいる、というのは典型例です。
• 年次処理。棚卸し、年度切り替え、決算関連。
• 障害時にしか通らない経路。バックアップからの復旧手順、代替サーバーへの切り替え、DR訓練。
• 長期間オフラインの端末。持ち出しPC、長期休暇中の担当者の端末、普段は電源が入っていない予備機。
• 年に数回しか使わない業務アプリ。

マイクロソフトのガイド自身も、分析は配備の複雑さによっては数か月に及びうるとしています。³ 現実的な線引きは次のどちらかです。

1. 業務が一巡するまで監査を回し続ける。最低でも月次締めを1回、できれば四半期をまたぐ。
2. 低頻度の処理を洗い出して、意図的に実行する。期間を待てない場合は、締め処理やDR手順を検証環境で走らせ、その結果を一覧に足す。「実行していないから出ていないだけ」の処理を、担当者への聞き取りで先に列挙しておくのが要点です。

どちらの場合も、「イベントが出なかった」と「まだ実行されていない」を区別できる状態にしてから次の段階へ進んでください。

9.3. 一気に拒否へ振らない

ここで「送信NTLMトラフィック=すべて拒否する」に一気に振らないのが要点です。マイクロソフトも、このポリシーを拒否に設定すると多数のNTLM認証要求が失敗して生産性を下げうるため、実装前に「すべて監査する」でログを確認し、サーバーの分析を行い、除外する例外リストを作るべきだとしています。⁷ ドメイン全体を対象とする「このドメインでのNTLM認証」ポリシーについても同様の警告が書かれています。¹²

10. まとめ

• NTLMは2024年6月に全バージョンが非推奨になりました。ただちに停止する変更ではなく、次期Windows Server・次の年次リリースのWindowsでも動作し続けるとされています。¹
• 一方でNTLMv1はすでに削除されています(Windows 11 24H2 / Windows Server 2025)。NTLMv1しか話せない機器と、NTLM V1 が記録されているホストが、いちばん近い期限です。¹
• 廃止は3フェーズで、フェーズ1は監査、フェーズ2(2026年後半)がIAKerbとローカルKDC、フェーズ3が既定無効化です。²
• 監査は3つのポリシーを監査モードにして Microsoft-Windows-NTLM/Operational を集めます。ドメインアカウントならDCの8004 → メンバーサーバーの8003 → クライアントの8001の順で、最後にアプリ名まで届きます。ローカルアカウントでの認証は8004が出ないので、サーバーとクライアントのイベントから拾います。³⁷
• SMB経由はPIDが常に4(SYSTEM)になります。イベントログで端末まで絞ってから、その1台をProcMonで追ってください。³
• 原因の大半は「名前」です。IPアドレス直打ちとSPN未登録を潰すだけで、残る例外は大きく減ります。³²
• NET USE \\server\share /BLOCKNTLM は、ポリシーを変えずに1接続だけで裏取りできる、いちばん安全な確認手段です。⁴
• 自作アプリはNTLM名指しをNegotiateに置き換え、接続先の書き方をFQDNに揃えます。⁵
• 例外リストは解決ではなく猶予です。件数が毎年減っているかどうかを指標にしてください。

関連記事

• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める
• Process Monitor(ProcMon)実践ガイド ── 「設定が読まれない」「ACCESS DENIED」を10分で特定する
• PowerShell Remoting(WinRM)入門 ── 複数台のWindowsを一括管理する
• PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する
• WinForms/WPFアプリにEntra ID認証を組み込む ── MSAL.NETとWAMブローカーの実務構成
• WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動

関連する相談領域

合同会社小村ソフトでは、NTLM依存の棚卸しやKerberos前提への移行にともなう業務アプリの改修、認証まわりの不具合調査を扱っています。

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

参考リンク

</content> </invoke>

関連する記事

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

関連トピック

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

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

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

よくある質問

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

NTLMが廃止されると、いつから業務が止まりますか？

「非推奨(deprecated)」の告知だけでは何も止まりません。マイクロソフトは2024年6月にNTLMの全バージョンを非推奨としましたが、そのときの案内は「次期Windows Serverと次の年次リリースのWindowsでもNTLMの利用は動作し続ける」というものでした。すでに動かなくなった具体的な変更は、Windows 11 バージョン24H2とWindows Server 2025でのNTLMv1の削除です。将来のリリースでネットワークNTLMが既定で無効になる計画は公表されていますが、その時点でもポリシーで再度有効にできるとされています。つまり「ある日いきなり全社が止まる」種類の変更ではなく、OSを新しくするたびに少しずつ締まっていく種類の変更です。だからこそ、止まってから調べるのではなく、まだNTLMが動いているうちに監査ログで依存箇所を洗い出しておくのが唯一の現実的な備えになります。

NTLMを使っている場所は、どうすれば一覧にできますか？

グループポリシーの「ネットワークセキュリティ: NTLMを制限する」系の設定を監査モードにして、NTLM/Operationalログを集めます。ドメインコントローラーに「このドメインでのNTLM認証を監査する」、サーバーとクライアントに「受信NTLMトラフィックを監査する」と「リモートサーバーへの送信NTLMトラフィック=すべて監査する」を設定すると、イベントビューアーの「アプリケーションとサービスログ > Microsoft > Windows > NTLM」にイベントが記録されます。ドメインアカウントでの認証なら、追い方は、ドメインコントローラーのイベント8004でユーザーと接続先サーバー(セキュアチャネル名)を特定し、そのサーバーのイベント8003でプロセスIDを見て、最後にクライアントのイベント8001で「どのアプリが、どのサーバー名で」要求したかを確定させる、という順番です。イベント8001にはターゲットサーバー名とクライアントプロセス名が入るので、ここまで来れば原因のアプリが分かります。ただしローカルアカウントでの認証はドメインコントローラーを経由しないため8004が出ません。ワークグループ機やファイルサーバーのローカルアカウントで共有に繋いでいる経路は、サーバー側の8003とクライアント側の8001から拾う必要があります。ドメインコントローラーのログだけを見て「うちは少ない」と判断しないでください。

監査したらイベントのPIDが4(SYSTEM)ばかりで、どのアプリか分かりません。

SMB(共有フォルダ)経由の通信だからです。SMBの認証はカーネルモードのリダイレクターが行うため、呼び出し元のアプリはSMBパケットの向こう側に隠れてしまい、イベントに残るPIDは常に4(SYSTEM)になります。マイクロソフトのガイドもこのケースを明記していて、対処として、イベントが出ているクライアント上でProcess Monitor(ProcMon)を動かし、相手サーバーのコンピューター名とIPアドレスでパスをフィルターし、サーバー側イベント8003のタイムスタンプと突き合わせて呼び出し元プロセスを特定する、という手順を案内しています。実務では、まず「どの端末か」までをイベントログで絞り、その端末だけをProcMonで追うのが速いです。

Kerberosに対応しているはずのアプリがNTLMに落ちるのはなぜですか？

ほとんどが名前の問題です。マイクロソフトのガイドは、理屈のうえではKerberosに対応していてもNTLMを使ってしまうアプリとして、セキュリティ構成やプロバイダーを選択できるアプリ、SPN(サービスプリンシパル名)が正しく登録されていないアプリ、設定ミスやベンダーの手順書のせいでDNS名ではなくIPアドレスで接続しているアプリ、レガシーなコードベースにNTLM専用の部分が残っているアプリ、の4つを挙げています。イベント8001の「ターゲットサーバー」がNetBIOS名でもFQDNでもない形式(つまりIPアドレス)なら、既定の構成ではKerberosは使われません。IPアドレス直打ちをFQDNに直す、別名でアクセスしているならその名前でSPNを登録する、というのが最初にやる二手です。なお、どうしても名前に変えられない場合に備えて、クライアントにTryIPSPNを設定してIPアドレスのSPNを手動登録する方法も用意されていますが、マイクロソフト自身がDNS名への変更が不可能な場合に限るべきとしているので、あくまで最後の手段です。

自分たちで作っているWindowsアプリは、何を直せばよいですか？

認証パッケージにNTLMを名指ししているところを、Negotiateに置き換えます。マイクロソフトは「アプリケーションはNTLMセキュリティパッケージに直接アクセスすべきではなく、Negotiateパッケージを使うべき」と明記しています。NegotiateはKerberosとNTLMのどちらかを選び、認証に関わるシステムのいずれかがKerberosを使えない場合を除いてKerberosを選びます。.NETであれば、CredentialCache.Add に渡す認証タイプを "NTLM" から "Negotiate" に変える、というのが典型的な修正です(認証タイプを指定するのは CredentialCache.Add であって、NetworkCredential のコンストラクターではありません)。あわせて、接続先をIPアドレスやhostsに書いた別名ではなくFQDNで指定すること、自作サービスをKerberosで受けるならそのサービスアカウントにSPNを登録することも必要になります。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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