【図解】NTLM認証とは？仕組み・今も残るユースケース・廃止される理由を初心者向けに解説

ファイルサーバのアクセスログやドメインコントローラのイベントを見ていると、「NTLM」という文字をよく見かけます。Active Directoryの標準の認証はKerberosのはずなのに、なぜ今もNTLMが動いているのか。Microsoftが「NTLMを既定で無効にする」と発表したとき、自分の環境で何が止まるのか。気になっている方も多いと思います。

この記事では、NTLMの仕組みをメッセージ1つずつ追ったうえで、今もNTLMが使われている場面、廃止される理由、そしてNTLMを減らしていく進め方を整理します。

NTLMを一言でいうと

NTLM（NT LAN Manager）は、Windowsで使われてきた「チャレンジ／レスポンス方式」の認証プロトコルです。サーバが毎回ちがう乱数（問題）を出し、クライアントはパスワードから作った値でその問題を計算して答えを返します。サーバは答えが正しいかどうかで、相手が本当にパスワードを知っているかを判断します。

パスワードそのものはネットワークに流れません。ただし、ドメインのアカウントの場合、ファイルサーバはユーザーのパスワード情報を持っていないので、受け取った問題と答えをDC（ドメインコントローラ）に転送して答え合わせを頼みます。この「DCに転送して確かめる」点が、NTLMを理解するうえでいちばん大事なところです。

登場人物	役割
クライアント	ユーザーが使うPC。パスワードから作ったNTハッシュを使って、サーバの問題に答えます。
サーバ	ファイルサーバやWebサーバなど、アクセスされる側です。問題を出し、答えをDCに転送して確かめてもらいます（ローカルアカウントなら自分で確かめます）。
DC	ドメインのユーザーのNTハッシュを持っていて、答え合わせをします。結果と一緒に、ユーザーの所属グループなどの情報もサーバに返します。

NTLMの歴史と種類

NTLMは1993年のWindows NTとともに登場しました。さらに古いLAN Manager（LM）の方式を置き換えるものでしたが、今の基準で見るとNTLMv1の計算も弱く、Windows NT 4.0 SP4で改良版のNTLMv2が使えるようになりました。Windows 2000からはActive Directoryの標準の認証がKerberosになり、NTLMは「Kerberosが使えないときの代わり（フォールバック）」という位置づけになっています。

そして2024年6月、MicrosoftはNTLM全体（LANMAN、NTLMv1、NTLMv2）を非推奨にしました。NTLMv1はWindows 11 24H2とWindows Server 2025で削除され、2026年1月には「次のメジャーリリースでネットワークのNTLMを既定で無効にする」というロードマップが公表されています。

方式	応答の作り方	今の扱い
LM（LAN Manager）	大文字にしたパスワードをもとにしたLMハッシュとDES	非常に弱く、現在は使わない
NTLMv1	NTハッシュ（MD4）を3つのDES鍵に分けて、サーバの乱数を暗号化	Windows 11 24H2／Windows Server 2025で削除
NTLMv2	NTハッシュとユーザー名からHMAC-MD5で鍵を作り、サーバの乱数・時刻・クライアントの乱数などを計算	非推奨。今もフォールバックとして動いている

Windowsのグループポリシー「ネットワーク セキュリティ: LAN Manager 認証レベル」の既定値は3（NTLMv2の応答だけを送る）です。この記事でも、特に断りがなければNTLMv2を前提に説明します。

NTLMの仕組み

出発点はNTハッシュ

NTLMの計算はすべて「NTハッシュ」から始まります。NTハッシュは、パスワードをUTF-16LEという文字コードに変換し、MD4というハッシュ関数にかけた16バイトの値です。ローカルアカウントならそのPCのSAM、ドメインのアカウントならADのデータベースに保存されています。

NTハッシュにはソルト（ユーザーごとのランダムな値）が混ざらないので、同じパスワードからはいつも同じ値ができます。そして、NTLMの応答はNTハッシュさえあれば計算できます。つまりNTハッシュは、実質的にパスワードと同じ価値を持つ情報です。これが後で説明するPass-the-Hash攻撃の原因になります。

5つのやり取りをシーケンスで見る

ドメインのアカウントでファイルサーバにアクセスするときの流れを、シーケンス図にまとめます。クライアントとサーバの間で3つのメッセージ、サーバとDCの間で2つのやり取りがあります。メッセージ名はMicrosoftの仕様書（MS-NLMP）の呼び方で、Wiresharkでもこの名前で表示されます。

NTLMのメッセージは、単独で流れるのではなく、SMBのセッション確立やHTTPのヘッダの中に入れて運ばれます。ここから、1つずつ「誰から誰へ、何を送っているか」を見ていきます。

NEGOTIATE：「NTLMで認証したい」と伝える

クライアントからサーバへ、NEGOTIATEメッセージを送ります。中身は「自分が使える機能」を表すフラグの集まりで、NTLMv2の応答を使えるか、署名や暗号化に対応しているか、などを伝えます。この時点では、ユーザーを表す情報はまだ入っていません。

CHALLENGE：サーバが問題を出す

サーバからクライアントへ、CHALLENGEメッセージを返します。いちばん大事なのは、8バイトの乱数（サーバチャレンジ）です。この乱数は毎回変わるので、過去の答えを盗み見て使い回すことはできません。

あわせて、TargetInfoと呼ばれる情報も入ります。サーバ名、ドメイン名、時刻などで、NTLMv2ではクライアントがこれを応答の計算に含めます。

AUTHENTICATE：答えを返す

クライアントからサーバへ、AUTHENTICATEメッセージを送ります。ユーザー名、ドメイン名、端末名と、NTハッシュを使って計算した応答（NTLMv2応答）が入っています。あわせて、3つのメッセージが途中で書き換えられていないことを示すMIC（Message Integrity Code）も付きます。

NTLMv2応答は、次の2段階で作ります。まずNTハッシュを鍵にして、ユーザー名とドメイン名からユーザーごとの鍵（NTOWFv2）を作ります。次にその鍵で、サーバの乱数、時刻、クライアントが作った乱数、TargetInfoをまとめてHMAC-MD5にかけ、16バイトのNTProofStrを作ります。

パススルー認証：サーバがDCに確認を頼む

ドメインのアカウントの場合、サーバはユーザーのNTハッシュを持っていません。そこで、ユーザー名、自分が出した乱数、クライアントの応答をDCに送り、答え合わせを頼みます。これをパススルー認証といいます。

この通信には、Netlogonのセキュアチャネルを使います。セキュアチャネルは、サーバがドメインに参加したときに作られるコンピュータアカウントの資格情報で保護された、サーバとDCの間の専用の通り道です。

結果を返す：DCからサーバへ

DCは自分が持っているNTハッシュで同じ計算をし、答えが一致すれば成功をサーバに返します。このとき、ユーザーのSIDや所属グループのSIDなどのユーザー情報と、セッション鍵（SessionBaseKey）も一緒に返します。

サーバはユーザー情報からアクセストークンを作り、フォルダのACLと照合してアクセスを許可するかを決めます。セッション鍵は、SMB署名など、その後の通信の保護に使います。なお、このユーザー情報の形は、Kerberosのチケットに入るPAC（次の記事で説明します）と同じ系統の構造です。

ローカルアカウントの場合

サーバ自身のローカルアカウント（例：NASやワークグループのPCのユーザー）でアクセスするときは、STEP 4と5がありません。サーバは自分のSAMにあるNTハッシュで同じ計算をし、その場で答え合わせをします。ドメインに参加していない機器どうしでNTLMが使われ続けているのは、このためです。

今もNTLMが使われている場面

ADのドメイン環境では、Windowsはまず Kerberos を試し、使えなかったときにNTLMに切り替えます（Negotiateという仕組みです）。そのため、管理者が意識しないうちに、さまざまな場面でNTLMが使われています。Microsoftも、NTLMが残る原因として「NTLMを直接指定しているアプリ」「Kerberosの前提が欠けている」「NTLMしか使えない古い機器」「ローカルアカウント」の4つを挙げています。

場面	NTLMになる理由	Kerberosにするには
IPアドレスでアクセス	Kerberosはサービスを名前（SPN）で指定する仕組みで、既定ではIPアドレスに対してKerberosを試しません	FQDNでアクセスするよう直します。どうしても無理な場合は TryIPSPN とIPのSPN登録
ワークグループ・ローカルアカウント	KDCがいない（ローカルアカウントのチケットを出す人がいない）	ドメインに参加させる。今後はLocalKDCで対応予定
SPNの不備	SPNが未登録・重複・別名（CNAME）と食い違うと、チケットを取れない	setspn -Q と setspn -X で確認して直す
DCに届かない	社外からVPNなしで接続、DMZのサーバなど、クライアントがKDCと通信できない	VPNやKDCプロキシ。今後はIAKerbで対応予定
信頼のない別ドメイン	信頼関係がないドメインのアカウントでは、Kerberosのチケットを取れない	信頼関係を作る。Microsoftは今後のリリースでの対応を予定
NTLMを直接指定するアプリ	アプリがNegotiateではなくNTLMを名指しで使っている	アプリの修正（Negotiateを使うようにする）、ベンダーへの確認
非Windows・古い機器	NAS、複合機のSMB送信、古いLinuxやアプライアンスがNTLMにしか対応していない	ファームウェアの更新、Kerberos対応機種への入れ替え

この中から、現場でよく相談を受ける4つの場面を詳しく見ていきます。

IPアドレスでアクセスしている

いちばん多いのがこのパターンです。\\fs01.corp.example\share のように名前で指定すると、クライアントは cifs/fs01.corp.example というSPNのチケットを取りにいけます。ところが \\10.0.0.10\share のようにIPアドレスで指定すると、Windowsは既定でKerberosを試さず、NTLMで認証します。

ドライブの割り当て、ショートカット、バッチファイル、業務アプリの接続文字列などにIPアドレスが書かれていることはよくあります。Microsoftも「プラットフォーム側の対応を待たず、今のうちにIPアドレスでの認証をなくしていくこと」を勧めています。Windows 10 1507／Windows Server 2016以降では、クライアントのレジストリ TryIPSPN と、IPアドレスのSPN登録でKerberosを使うこともできますが、クライアントごとの設定が必要で、IPアドレスの固定も前提になります。

クライアント（管理者のコマンドプロンプト）：IPアドレスでもKerberosを試すようにする設定

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v TryIPSPN /t REG_DWORD /d 1 /f

DC：IPアドレスのSPNを、サービスを動かすアカウントに登録する（例）

setspn -s host/10.0.0.10 fs01

Webプロキシの認証

社内からインターネットに出るときに、Webプロキシでユーザーを認証している企業は多いと思います。ユーザー名とグループでURLフィルタやログを分けるためです。このとき、プロキシはHTTPの407応答で認証を求め、ブラウザは Proxy-Authorization ヘッダにNTLMのメッセージを入れて送ります。プロキシは受け取った応答をDCに確認し、ユーザーとグループを特定します。

HTTPのNTLMは、③〜⑤を同じTCP接続のままやり取りする必要があります。途中で接続が切れると認証をやり直すことになるので、プロキシの前段にロードバランサがある構成では、接続の扱いに注意が必要です。

プロキシの認証は、Negotiate（Kerberos）に切り替えるのが難しい場面の代表です。理由は次のとおりです。

Kerberosにしにくい理由	内容
プロキシのSPNと鍵が必要	HTTP/proxy.corp.example のSPNをADのアカウントに登録し、その鍵（keytabなど）をプロキシ装置に入れる作業が必要です。
プロキシを名前で指定する必要がある	ブラウザのプロキシ設定やPACファイル、WPADでプロキシをIPアドレスで書いていると、SPNを組み立てられずNTLMになります。
複数台・負荷分散	複数のプロキシを1つの名前で見せる場合、全台で同じアカウントの鍵を使うよう設計する必要があります。
ドメイン外の端末	ドメインに参加していない端末やWindows以外の端末は、KerberosのチケットをもらえずNTLMやBasic認証に頼りがちです。

プロキシ製品の多くはNegotiateとNTLMの両方に対応していますが、上の準備ができていないと、ブラウザはNTLMで認証を続けます。プロキシの基本は 【図解】フォワードプロキシとリバースプロキシの違い、NTLMでプロキシ認証を設定した例は 【Fortigate】プロキシ認証（Explicit Proxy＋NTLM認証） で紹介しています。

Wi-Fi・VPNのMSCHAPv2

社内Wi-Fiの802.1X認証で、PEAP-MSCHAPv2を使っている環境は今も多くあります。NPS（RADIUSサーバ）がDCにユーザーの確認を頼む流れは、NTLMのパススルー認証とよく似ています。そして、MSCHAPv2の応答の計算は、NTLMv1と同じ関数（NTハッシュとDES）を使っています。

MicrosoftはMSCHAPv2について、NTLMv1と同じ弱い暗号への攻撃を受けると説明しており、Credential Guardを有効にするとMSCHAPv2はシングルサインオンに使えなくなります。NTLMv1の廃止に関連して、Wi-Fi、有線LAN、VPNのSSOに影響が出る場合があることも案内されています。長い目で見ると、証明書を使うEAP-TLSへの移行が本筋です。RADIUSの仕組みは 【図解】RADIUSプロトコルがよくわかる！ で解説しています。

NTLMを直接使うアプリ・機器

アプリケーションが認証方式としてNTLMを名指ししている場合、KerberosのSPNやDCが整っていても、NTLMしか使われません。古い業務アプリ、スクリプト、組み込み機器、他社製のアプライアンスなどがこれに当たります。Microsoftは、ソースコードの中から NTLM や NTLMSSP の文字列を探し、Negotiateに置き換えることを勧めています。他社製品の場合は、ベンダーに対応予定を確認するのが近道です。

なぜNTLMは危ないのか

Microsoftは、NTLMを廃止する理由として「サーバを確かめられない」「リプレイ・リレー・Pass-the-Hash攻撃に弱い」「暗号が弱い」「ログで使われ方が見えにくい」を挙げています。それぞれを見ていきます。

相手のサーバが本物か確かめられない

NTLMでは、サーバがクライアントを確かめるだけで、クライアントはサーバが本物かどうかを確かめません。NTLMは「サーバは正しい」という前提で作られているためです。これが次のリレー攻撃の土台になります。Kerberosでは、サーバもチケットを開けられることで自分が本物だと示せます（相互認証）。

NTLMリレー攻撃

攻撃者は、偽のサーバにクライアントを接続させ（細工したリンクや名前解決の乗っ取りなど）、クライアントとのNTLMのやり取りを、そのまま本物のサーバに中継します。クライアントは正しいパスワードで正しく計算した答えを返すので、本物のサーバは攻撃者を「そのユーザー」として受け入れてしまいます。

対策は、認証とその後の通信を結び付けることです。SMB署名を必須にすると、セッション鍵を知らない攻撃者は正しい署名を付けられません。LDAPやHTTPでは、認証をTLSの通信路に結び付ける拡張保護（EPA、LDAPではチャネルバインディング）を有効にします。

プロトコル	主な対策
SMB	SMB署名を必須にする（Windows Server 2025では送信側で既定で必須）。SMBクライアントのNTLMブロック
LDAP	LDAP署名の要求と、LDAPSでのチャネルバインディング（CBT）の要求
HTTP（IIS、AD CSのWeb登録など）	HTTPSと拡張保護（EPA）

Pass-the-Hash

NTLMの応答はNTハッシュだけで計算できるので、パスワードを知らなくても、NTハッシュを盗めばそのユーザーとして認証できます。管理者がサインインしたことのあるPCが乗っ取られ、メモリ（LSASS）からNTハッシュを抜き取られると、そのハッシュで別のサーバへ次々とログオンされます。ランサムウェアの侵入後に、社内で被害が広がる典型的な流れです。

対策としては、Credential GuardでLSASSの資格情報を保護する、ローカル管理者のパスワードをLAPSでPCごとに変える、特権アカウントを一般のPCにサインインさせない、といった組み合わせが基本です。Protected Usersグループのメンバーは、NTLMでの認証そのものができなくなります。

応答の解析と、弱い暗号

ネットワーク上で応答を盗み取られると、攻撃者は手元で時間をかけてパスワードを総当たりできます。NTLMv1はDESを使っているので特に弱く、NTLMv2でもパスワードが単純なら割り出されるおそれがあります。MD4やHMAC-MD5といった古い暗号の上に作られていることも、廃止の理由の1つです。

DCへの負荷と、見えにくさ

NTLMでは、サーバが認証するたびにDCへの問い合わせが発生します。また、これまでのNTLMのログでは「どのプロセスが、なぜNTLMを使ったのか」まで分かりませんでした。これは次の章で紹介する「強化されたNTLM監査」で改善されています。

弱点	何が起きるか	主な対策
相互認証がない	偽のサーバにだまされる	Kerberosへの移行
リレー	応答を中継され、別のサーバにログオンされる	SMB署名、EPA、チャネルバインディング
Pass-the-Hash	盗まれたNTハッシュでログオンされる	Credential Guard、LAPS、特権アカウントの分離
弱い暗号	盗んだ応答からパスワードを割り出される	NTLMv1の廃止、長いパスワード、Kerberosへの移行

廃止へのロードマップ

Microsoftは、NTLMを一度に消すのではなく、段階を踏んで減らしていく計画を公表しています。2026年1月の発表では、次の3つのフェーズが示されました。日程は変わる可能性があると明記されているので、最新の情報は Microsoftの案内（aka.ms/ntlm） で確認してください。

フェーズ	内容
フェーズ1：見える化	強化されたNTLM監査で、誰が・なぜ・どこでNTLMを使っているかを把握する。Windows 11 24H2以降とWindows Server 2025で利用できる
フェーズ2：主な原因の解消	DCに届かない場合のIAKerb、ローカルアカウント用のLocalKDC、Windowsの部品がKerberosを先に試すようにする改修。2026年後半にWindows Server 2025とWindows 11 24H2以降向けに提供予定
フェーズ3：既定で無効	次のメジャーリリースで、ネットワークのNTLMを既定で無効にする。必要ならポリシーで再び有効にできる

「既定で無効」は、NTLMをWindowsから削除するという意味ではありません。NTLMの部品はしばらく残り、どうしても必要な環境では管理者がポリシーで有効に戻せます。また、今使っているWindows Server 2019／2022／2025やWindows 10／11で、ある日突然NTLMが止まるわけでもありません。完全な削除は、依存がなくなってからの長期的な目標とされています。

IAKerbとLocalKDC

NTLMが残る大きな理由である「DCに届かない」と「ローカルアカウント」に対して、Microsoftは2つの仕組みを用意しています。IAKerbは、クライアントがDCと直接通信できないときに、接続先のサーバがKerberosのやり取りをDCまで中継する仕組みです。LocalKDCは、Windowsの中に小さなKDCを組み込み、ローカルアカウントにもKerberosのチケットを出せるようにする仕組みです。

どちらもWindows Insiderのプレビュービルドで提供されていて、Windows Server 2025とWindows 11向けに一般提供される予定です（2026年9月時点の案内）。

NTLMを減らす進め方

NTLMを減らす作業は、「どこで使われているか分からない」ところから始まることがほとんどです。Microsoftが紹介している進め方を、5つのステップに整理します。

監査：どこで、なぜ使われているかを知る

Windows 11 24H2以降とWindows Server 2025では、強化されたNTLM監査を使えます。クライアント、サーバ、DCのそれぞれで、NTLMを使ったアカウントとプロセス、相手のマシン名とIPアドレス、そしてKerberosではなくNTLMになった理由（SPNがない、DCに届かない、ローカルアカウント、IPアドレス指定など）が記録されます。NTLMv1の使用など、安全でない認証は警告レベルのイベントとして記録されます。

項目	内容
ログの場所	アプリケーションとサービス ログ ›› Microsoft ›› Windows ›› NTLM ›› Operational
クライアント・サーバの設定	管理用テンプレート ›› システム ›› NTLM の「NTLM 拡張ログ記録」
DCの設定	管理用テンプレート ›› システム ›› Netlogon のドメイン全体のNTLMログのポリシー
従来からある記録	セキュリティログのイベントID 4624（ログオン）の「認証パッケージ」「パッケージ名（NTLMのみ）」、「ネットワーク セキュリティ: NTLM を制限する」系の監査ポリシー

分類：原因ごとにまとめる

集めたログを、マシン単位ではなく原因ごとにまとめます。「IPアドレス指定」「SPNの不備」「NTLMを直指定するアプリ」「古い機器」のように分けると、まとめて直せるものと、ベンダーに相談するものが見えてきます。プロセス名が分かれば、担当者も決めやすくなります。

修正：簡単なものから直す

IPアドレスをFQDNに直す、足りないSPNを登録する、重複したSPNを消す、NTLMv1を使っている機器をなくす、スクリプトのNTLM指定をNegotiateに変える、といった作業から始めます。SPNは次のコマンドで確認できます。

DC：SPNの登録先と重複を確認する

setspn -Q cifs/fs01.corp.example
setspn -X

試験ブロック：一部から止めてみる

影響の小さい範囲から、NTLMを実際に止めてみます。特権アカウントや重要でないサービスから始め、段階的に広げるのがMicrosoftの勧める方法です。Windows Server 2025とWindows 11 24H2以降のSMBクライアントでは、送信側のSMB接続でNTLMをブロックできます。

クライアント（管理者のPowerShell）：SMBクライアントでNTLMをブロックする

Set-SmbClientConfiguration -BlockNTLM $true

グループポリシーでは コンピューターの構成 ›› 管理用テンプレート ›› ネットワーク ›› Lanman ワークステーション の「Block NTLM (LM, NTLM, NTLMv2)」で同じ設定ができます。

既定で無効になる日に備える

他社製品でNTLMを直接使っているものは、ベンダーに対応予定を確認します。IAKerbとLocalKDCが使えるようになったら、DCに届かない端末やローカルアカウントの場面で試します。こうした準備を進めておけば、次のメジャーリリースでNTLMが既定で無効になっても、例外として残すものを最小限にできます。

まとめ

NTLMは、サーバが出した問題にNTハッシュで答え、ドメインのアカウントならDCが答え合わせをする、チャレンジ／レスポンス方式の認証です。パスワードは流れませんが、NTハッシュがパスワードと同じ価値を持つこと、サーバを確かめられないことから、リレーやPass-the-Hashの攻撃に使われてきました。

項目	押さえておくこと
仕組み	NEGOTIATE → CHALLENGE → AUTHENTICATE の3メッセージ。ドメインのアカウントなら、サーバがNetlogonでDCに確認する
NTハッシュ	パスワードをMD4にかけた値。ソルトがなく、これだけで応答を計算できる
今も残る場面	IPアドレス指定、ワークグループ、SPNの不備、DCに届かない、プロキシ認証、MSCHAPv2、NTLM直指定のアプリ・機器
危ない理由	相互認証がない、リレー、Pass-the-Hash、弱い暗号、見えにくさ
今後	2024年に非推奨、NTLMv1は削除。次のメジャーリリースでネットワークのNTLMが既定で無効になる予定
今からできること	強化されたNTLM監査で洗い出し、FQDN化・SPNの整備・Negotiateへの切り替えを進める

NTLMを減らす作業は、そのままKerberosをきちんと動かす作業でもあります。次の記事では、NTLMに代わるKerberosの仕組みを、チケットのやり取りとPACを中心に追っていきます。

次に読む：【図解】Kerberos認証とは？チケットの流れとPAC／【図解】Microsoft Entra Kerberosとは？
関連記事：【図解】RADIUSプロトコルがよくわかる！／【図解】LDAPとは？／【図解】フォワードプロキシとリバースプロキシの違い／【Fortigate】プロキシ認証（Explicit Proxy＋NTLM認証）／【Active Directory】ユーザーのログオン認証の監査を設定する方法