「NTLMが廃止されるらしい。うちは何をすればいいのか」。Active Directoryを運用していると、2026年に入ってからこの質問を受ける機会が増えたはずです。
先に結論を書きます。いま使っているWindows 10/11やWindows Server 2019/2022/2025で、ある日NTLMが使えなくなるわけではありません。 既定で無効になるのは、WindowsとWindows Serverの次のメジャーリリースからです（予定で、変わる可能性があります）。一方で、2026年10月13日の更新で、先に止まったものが1つあります。 Wi-Fi・有線LAN・VPNのシングルサインオンで使われてきた、NTLMv1由来の資格情報です。
そして、いまからできる作業ははっきりしています。どこで、誰が、なぜNTLMを使っているかを監査で洗い出し、原因ごとに直す。 2026年10月の更新からは、この監査がWindows Server 2019と2022でも使えるようになりました。
この記事は、MicrosoftのFAQを日本語で解説した無料動画と、NTLMとKerberosをパケットやイベントログで確かめた動画を素材にしています。日付と仕様は、2026年10月16日時点のMicrosoft公式情報で確認しました。
いつ、何が止まるのか
Microsoftは2026年9月に「Retiring NTLM: Frequently asked questions」（英語）を公開し、方針をQ&Aでまとめました。ロードマップそのものは、同年初めの「Advancing Windows security: Disabling NTLM by default」で発表されています。FAQの要点を、自分の環境に当てはめやすい形で並べます。
| 時期 | 何が起きるか | 自分の環境への影響 |
|---|---|---|
| 2024年6月 | NTLM（LANMAN・NTLMv1・NTLMv2のすべて）が非推奨に。機能開発は止まった | 動作は続く。新しく作るものでNTLMに頼らない |
| Windows 11 24H2・Windows Server 2025 | NTLMv1のプロトコルが削除された | これらのOSではNTLMv1で通信できない |
| 2026年10月13日の更新 | NTLMv1由来の資格情報を使うシングルサインオンが、既定で「監査」から「ブロック」に変わった | MS-CHAPv2を使うWi-Fi・有線LAN・VPNで自動接続が失敗しうる（後述） |
| 2026年10月13日以降の更新 | 強化されたNTLM監査が、Windows Server 2019・2022でも使えるようになった | 古いサーバーでも、NTLMの利用元を洗い出せる |
| 今後数か月 | IAKerbとLocalKDC（NTLMに頼ってきた場面をKerberosで置き換える機能）が一般提供の予定 | NTLMを外せる場面が広がる |
| 次のメジャーリリース | ネットワークでのNTLM認証が既定で無効に。当面はグループポリシーやレジストリで有効に戻せる | 削除ではない。ただし戻せる範囲は将来狭まる |
NTLMの非推奨は、Microsoft Learnの「Windows クライアントの非推奨機能」にも載っています。
「削除ではなく、まず既定で無効にする」という点は、無料動画の2分11秒から、時期の答えは10分26秒から、「いまのWindows Server 2019/2022/2025やWindows 10/11でも止まるのか」には「明確にノー」と答えている場面が12分26秒からです。
期限が先なら、後回しでいいか。 FAQの答えは逆です。Microsoftは「いまから減らし始める」ことを強く勧め、IAKerbやLocalKDCの一般提供を待つ必要もないと書いています。後で詳しく書くとおり、NTLMの利用元を洗い出して1つずつ直す作業は、想像以上に時間がかかるからです。
なぜNTLMが危ないのか、を1分で
NTLMは1993年からWindowsが使ってきた認証方式です。サーバーが出した「お題」に、クライアントがパスワードから計算した答えを返す仕組みで、パスワードそのものはネットワークに流しません。ただし、相手のサーバーが本物かを確かめないため、答えを横取りして別のサーバーへ中継する攻撃（リレー攻撃）や、盗んだハッシュでなりすます攻撃（パス・ザ・ハッシュ）に弱いのです。
Kerberosは、信頼できる発行元（ドメインコントローラー）が出した、有効期限付きのチケットを見せ合う方式です。サーバー側の身元も確かめられます。この違いは無料動画の3分29秒からで、図を使って説明しています。
文字で読むより実際の通信を見たほうが早い人は、ファイルサーバーへのアクセスをパケットで追った無料の前編へ。9分0秒からはワークグループ環境でNTLMSSPのやり取りが見える場面、12分20秒からは同じアクセスがドメイン環境ではKerberosに変わる場面です。
止まるのは「Kerberosが使えたはずなのにNTLMで通っている」場所
ドメインに参加したPC同士なら、本来の認証はKerberosです。それでもNTLMが残っているのは、Kerberosが失敗したときに、WindowsがNTLMで黙って救済しているからです。利用者から見ると、IDとパスワードを入れれば普通に使えてしまうので、誰も気づきません。この「フォールバック」の説明は無料動画の5分59秒からにあります。
NTLMが既定で無効になったとき、壊れるのはこの救済に頼っていた場所です。FAQは、失敗のパターンを4つに分けています（動画では19分19秒から）。
| パターン | 典型例 | 誰が直すか |
|---|---|---|
| NTLMの決め打ち | アプリがNTLMを直接指定し、Negotiate（Kerberosを先に試す方式）を使っていない | 自社アプリなら自分で。Windows側の自動置き換え（Auto-Redirect）も用意される |
| Kerberosの前提が欠けている | IPアドレスで接続している、SPNが無い・重複している、ドメインコントローラーに届かない | 大半は自分で今すぐ直せる |
| NTLMしか話せない相手 | 古いNAS、組み込み機器、他社製アプライアンス | ベンダーの更新。できなければ置き換え |
| ローカルアカウントでのネットワーク認証 | ドメインに参加していないサーバーへ、ローカルアカウントで接続している | 大半はLocalKDCで解消の見込み |
2つ目は、プラットフォームの進化を待っても直りません。 FAQは「ディレクトリのSPNが欠けている・重複している・誤っているものは、私たちには直せない」とはっきり書いています。
使っている場所の調べ方：強化されたNTLM監査
従来の調べ方は、全サーバーのログを集める必要があった
これまでNTLMの利用状況を調べるには、セキュリティログのイベントID 4624（ログオン）の「認証パッケージ」と「パッケージ名（NTLMのみ）」を見ていました。ここに NTLM と NTLM V2 などが記録されます。ワークグループのPCから共有フォルダーを開いたとき、サーバー側の4624に NTLM V2 と出る様子は、無料動画の7分11秒からで見られます。
困るのは、4624はアクセスされた側のサーバーにしか出ないことです。ドメインコントローラーのログだけを見ても全体は分かりません。この問題と、Windowsイベント転送などで全台からイベントを集める方法は、メンバー限定のNTLMv1の回の15分6秒からと19分36秒からで、図を使って説明しています。何千台ものPCのログを集める手段が無い組織は、そこから整える必要がある、というのが動画の結論です。参加していない場合は、リンク先でメンバーシップの案内が表示されます。
強化された監査は「誰が・なぜ・どこで」まで出す
強化されたNTLM監査は、この弱点を埋める新しいログです。仕様はMicrosoftサポートの「Windows 11 バージョン 24H2、Windows Server 2019 以降のバージョンでの NTLM 監査の機能強化の概要」にまとまっています。
- 使えるOS：Windows 11 24H2以降、Windows Server 2025。Windows Server 2022と2019は、2026年10月13日以降の更新を入れると使えます
- ログの場所：イベントビューアーの「アプリケーションとサービス ログ > Microsoft > Windows > NTLM > Operational」
- 有効にするポリシー：クライアントとサーバーは「管理用テンプレート > システム > NTLM」の「NTLM Enhanced Logging」、ドメインコントローラーは「管理用テンプレート > システム > Netlogon」の「Log Enhanced Domain-wide NTLM Logs」。サポート記事では、これらのイベントは既定で有効とされています
| 記録する場所 | イベントID（情報／警告） | 分かること |
|---|---|---|
| クライアント（NTLMで出て行った側） | 4020／4021 | プロセス名、ユーザー、接続先の名前・IP・SPN、NTLMを使った理由、NTLMのバージョン |
| サーバー（NTLMを受けた側） | 4022／4023 | プロセス名、接続元のユーザー・マシン・IP、成否 |
| ドメインコントローラー（同じドメイン） | 4032／4033 | ドメイン全体のNTLM認証。クライアントとサーバーの名前・IP |
| ドメインコントローラー（別ドメインから） | 4030／4031 | ドメインをまたいだNTLM認証 |
警告（4021・4023・4031・4033）は、NTLMv1の利用など安全性が下がる認証を示します。動画では25分38秒からで、この監査が「アカウント名、マシン名、IP、プロセスまで出る」点を取り上げています。動画の収録時点ではWindows Server 2019/2022は「作業中」でしたが、その後2026年10月の更新で提供されました。
いちばん役に立つのは「NTLMを使った理由」
クライアント側のイベント（4020・4021）には、なぜKerberosではなくNTLMになったのかが「Reason ID」として記録されます。これが、そのまま直す作業の割り振りになります。
| Reason ID | 記録される理由 | 次にやること |
|---|---|---|
| 1 | アプリがNTLMを直接呼んだ | アプリの所有者へ。自社コードなら NTLM を Negotiate に変える |
| 2 | ローカルアカウントで認証した | ドメインアカウントに寄せる。LocalKDCの対象かを確かめる |
| 5・6 | 接続先の名前が空・解決できない | 接続先の名前とDNSの登録を確かめる |
| 7 | 接続先の名前がIPアドレス | 名前で接続するよう直す（次の節） |
| 8 | 接続先の名前がActive Directoryで重複している | setspn -X で重複したSPNを探して直す |
| 9 | ドメインコントローラーに届かなかった | 経路と名前解決を確かめる。IAKerbの対象かを確かめる |
（理由の一覧は、上のサポート記事の「Usage Id/Reason」の表から、作業につながるものを抜き出しました。）
SPNの重複を直す手順は、Microsoft Learnの「Kerberos でKDC_ERR_S_PRINCIPAL_UNKNOWNまたはKDC_ERR_PRINCIPAL_NOT_UNIQUE エラーが発生する」が、setspn -Q と setspn -X の使い方から説明しています。
ログを読む前の手早い確認なら、クライアントで klist を実行します。Kerberosで接続できていれば、接続先のチケットが一覧に出ます。期待した接続先のチケットが無ければ、NTLMで通っていると考えられます。ファイルサーバー用のチケットが増える様子は、パケット編の20分37秒から（無料）で確かめられます。
いちばん多い原因：IPアドレスで接続している
KerberosはIPアドレスを宛先として扱えません。チケットを発行するときに使うSPNは、サーバーの名前で登録するものだからです。そのため \\10.1.2.30\share のようにIPアドレスで開くと、Windowsは既定でNTLMを使います。
FAQはここを「プラットフォームの修正を待つな」と書き、今すぐ次の順で減らすよう勧めています（動画では23分16秒から）。
- 監査で、IPアドレスを使っているプロセスを特定する。プロセス名が、そのまま直す人のリストになる
- 業務アプリやスクリプトの接続文字列・設定ファイルにあるIPアドレスを、DNS名に変える。多くは書き換えではなく設定変更で済む
- 利用者の習慣を変える。ブックマーク、ネットワークドライブの割り当て、手順書にIPアドレスで書かれた共有が残っていないか
- どうしても相手を変えられない場合だけ、クライアント側のレジストリ
TryIPSPNとIPアドレスのSPN登録で、IPアドレスでもKerberosを使えるようにする
4つ目は、対象のクライアント1台ごとに設定が要り、IPアドレスも固定しておく必要があります。手順と注意点はMicrosoft Learnの「IP アドレス用 Kerberos の構成」にあります。例外として使うもので、最初の手段にはしません。
共有フォルダーで「名前では開けないのにIPアドレスなら開ける」といった症状が出ている場合は、共有フォルダーにアクセスできない原因の切り分けで、名前解決とKerberosのどちらで止まっているかを順に追えます。
2026年10月、先に止まったもの：NTLMv1由来の資格情報
NTLMv1は、NTLMの中でもさらに古く、暗号の強度が弱い方式です。Windows 11 24H2とWindows Server 2025からは、NTLMv1のプロトコル自体が削除されています。
ただし、NTLMv1の計算方式は、MS-CHAPv2を使う認証（PEAP-MSCHAPv2、EAP-MSCHAPv2）の中に残っていました。ドメイン参加のPCが、サインインしたユーザーの資格情報でWi-Fi・有線LAN・VPNへ自動接続するときに使われるものです。
Microsoftサポートの「Windows 11 バージョン 24H2 および Windows Server 2025 の NTLMv1 に対する今後の変更」によると、2026年10月13日のセキュリティ更新で、この動作の既定が変わりました。
- 対象：Windows 11 24H2・25H2・26H2とWindows Server 2025のうち、Credential Guardが無効で、レジストリ値
BlockNtlmv1SSOを設定していない端末 - 変化：NTLMv1由来の資格情報を使うシングルサインオンが、これまでの「監査して許可」から「ブロック」になった。更新はレジストリ値を作らず、値が無いときの内部の既定だけを変える
- 症状：MS-CHAPv2を使うWi-Fi・有線LAN・VPNで、自動接続が失敗しうる。手でユーザー名とパスワードを入れれば接続できる
- 記録：イベントビューアーの「Microsoft > Windows > NTLM > Operational」に、ブロックしたときはイベントID 4025（エラー）、監査モードでは4024（警告）
つまり、10月の更新のあとに「社内Wi-FiやVPNに、毎回パスワードを聞かれるようになった」という問い合わせが来たら、この変更を疑う価値があります。4025が出ているかで確かめられます。
本来の対処は、証明書を使う方式（EAP-TLSやPEAP-TLS）へ移すことです。Credential Guardを有効にした端末では、もともとMS-CHAPv2のシングルサインオンは使えません。Wi-FiとVPNで気をつける点は、Microsoft Learnの「Credential Guard を使用するときの考慮事項と既知の問題」にまとまっています。すぐに移せない場合は、HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 の BlockNtlmv1SSO を 0（監査モード）にすると一時的に戻せます。ただし、サポート記事は期間を区切った例外として扱うよう求めています。戻したなら、移行の期限と担当を決めておきます。
古いサーバーや機器が残っているなら、LmCompatibilityLevelも見直す
Windows Server 2022以前や、NASなどの他社製機器が残っている環境では、NTLMv1そのものがまだ使われている可能性があります。メンバー限定のNTLMv1の回では、この確認と止め方を、順番を守って進める方法として解説しています。2025年1月公開の回で、Windows 11 24H2とServer 2025でNTLMv1のプロトコルが削除されたことには触れていません。古いOSと他社製機器を対象にした手順として見てください。
- 11分13秒から：NTLMの使い方を決める設定「LmCompatibilityLevel」（グループポリシーでは「ネットワーク セキュリティ: LAN Manager 認証レベル」）の値の意味
- 14分41秒から：監査でNTLMv1を使う機器やアプリを見つけ、個別に直してから、値を3、5と段階的に上げる順番
- 23分13秒から：グループポリシーで「未構成」に戻しても端末側に設定が残る、いわゆる「タトゥー」に注意する理由
- 24分36秒から：ドメインコントローラーをいきなり5にすると、認証の再試行でアカウントのロックアウトが多発しうる、という注意
この設定の値ごとの意味は、Microsoft Learnの「Network security LAN Manager authentication level」で確かめられます。値の表は読めば分かりますが、どの順で上げれば業務を止めずに済むかは、図を使った説明のほうが判断しやすいはずです。
「ドメインに参加していないからNTLM」とは限らない
NTLMを外す話になると、「ドメインに参加していない端末はNTLMしか使えない」と考えがちです。これは正確ではありません。
無料動画では、ワークグループのPCから、サーバー側でNTLMを拒否したファイルサーバーへアクセスしています。最初はエラーになりますが、10分52秒から、cmdkey で ユーザー名@ドメイン名 の形式（UPN）の資格情報を登録すると開けるようになり、11分49秒からの klist で、Kerberosのチケットを受け取っていることが確かめられます。前提は、DNSでドメインコントローラーを探せて、ドメインコントローラーと通信できることです。
この前提は、Azure Filesのようなクラウドのファイル共有でも同じ形で現れます。メンバー限定の後編では、17分49秒から、ドメインに参加していない端末でもUPN形式の資格情報でチケットを受け取れるが、ドメインコントローラーへの到達は必要、という制約を整理しています。19分33秒からは、Microsoft Entra IDがKerberosのチケットを発行する構成（Microsoft Entra Kerberos）へ話が進みます。「ドメインコントローラーに届かないからNTLM」という理由（Reason ID 9）を、構成の選び方で減らす考え方です。チケットの発行元が変わる仕組みは、図とデモで追ったほうが理解しやすい内容です。
直す順番：監査、優先順位、簡単なものから、試験的なブロック、ベンダー
FAQは、先行した組織がうまくいった進め方を5段階でまとめています（動画では28分32秒から）。
- 監査：クライアント、サーバー、ドメインコントローラーで強化されたNTLM監査を有効にし、数週間分のデータを取る。まれにしか動かない処理もあるので、数日で判断しない
- 優先順位付け：結果を原因別（SPNの不足、NTLMを決め打ちしているアプリ、古い機器など）にまとめ、1台ずつではなくまとめて直す
- 簡単なものから直す：足りないSPNを登録する、NTLMv1をやめる、NTLMを決め打ちした古いスクリプトを置き換える
- 試験的にブロックする：重要度の低いサービスなどから、範囲を区切って広げる
- ベンダーに依頼する：他社製品の決め打ちは、ベンダーに問い合わせて対応を計画してもらう
最初からNTLMを全面的にブロックしないことが大切です。Kerberosへの切り替えはこれまでも段階的に進められてきました。RC4の既定無効化もその1つで、こちらはRC4無効化の影響と対処で、止まりやすい相手と見つけ方をまとめています。
まとめ
- 既定で無効になるのは次のメジャーリリースから。いまのWindowsでNTLMが急に止まるわけではない
- ただし2026年10月13日の更新で、MS-CHAPv2のWi-Fi・VPNの自動接続に使われるNTLMv1由来の資格情報が、既定でブロックになった。症状とイベントID 4025で確かめる
- いまやることは、強化されたNTLM監査で「誰が・なぜ・どこで」を洗い出すこと。Server 2019/2022も10月の更新で対象になった
- 「理由」ごとに直す。IPアドレスでの接続とSPNの不備は、待っていても直らない。自分で今すぐ直せる
- ドメインに参加していないことが、NTLMを使う理由になるとは限らない
NTLMの廃止は年単位で続く話です。それでも、監査を入れてIPアドレスでの接続をやめ、SPNを整えるところまでは、次のリリースを待たずに今日から始められます。
