図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか

「うちはKerberos環境です」と言われる社内ネットワークでも、監査ログを取ると必ずNTLMが出てきます。しかも出てくるのは、たいていKerberosに対応しているはずのアプリです。

ここでいう「NTLMに落ちる」とは、認証がエラーで止まることではなく、Kerberosを使えずにNTLMへ切り替わることです。業務が動いていても、期待した認証方式が使われているとは限りません。

この記事では、まずNTLMとKerberosが何を材料に、誰を確かめるのかを図で比べます。その違いが分かると、接続先の名前やアカウントの種類によってNTLMに切り替わる理由も、リレー攻撃やPass-the-Hashが成立する理由も、同じ仕組みから説明できます。

読み進める順序は、仕組みの違い → 切り替わる条件 → 防御と移行の判断です。障害調査が目的なら、先に「NTLMで動いている」のか「認証自体が止まっている」のかを分け、1章の目的別ガイドから6章へ進んでください。

自社環境の棚卸し手順(監査ポリシーの設定、イベントの追い方、直す順番)は、対になる記事「NTLM廃止で業務アプリは止まるか」にまとめています。

1. まず結論

最初に押さえるのは、認証の材料、NTLMへ切り替わる条件、安全性と移行の方針の3点です。

仕組みの違いを押さえる

NTLMはハッシュをもとに応答を作り、Kerberosは接続先を指定したチケットを使います。 NTLMの資格情報は、ドメイン名・ユーザー名・パスワードの一方向ハッシュです。¹ NTLMv2では、そのハッシュから導いた鍵で、サーバーのチャレンジ・時刻・クライアント側のチャレンジ・ターゲット情報を材料にHMACを計算します(2.2節)。²

一方、KerberosはSPN(接続先のサービス名)をもとにサービスチケットを発行し、「誰が、どのサービスに対して」を確かめます。³ この違いから、相互認証、ドメインアカウント認証時のDCへの問い合わせ、他サービスへの委任という3つの差が生まれます(5章)。⁴

切り替わりと認証エラーを分ける

「NTLMで動く」と「Kerberosのエラーで止まる」は、調べる入口が違います。 NTLMへ切り替わる主な原因は、IPアドレス直打ち、SPN未登録、ワークグループ、DCに到達できない経路です。とりわけ、接続先の名前からSPNを引けるかが重要です(6章)。⁵⁶

これに対して、時刻ずれのようにKerberosが選ばれたあとで失敗する問題は、認証そのものが止まる問題です。失敗したから必ずNTLMでやり直される、と考えてはいけません(6.5節)。⁷

安全性と移行の方針を押さえる

NTLMv2でも、リレー攻撃とPass-the-Hashの問題は残ります。 リレーは認証のやり取りが宛先を縛らないこと、Pass-the-Hashはハッシュそのものが認証の材料になることに由来します。接続先でSMB署名やチャネルバインディングを要求しているかも含め、7章で成立条件を確認します。⁸¹

NTLMv1はWindows 11 バージョン24H2とWindows Server 2025で削除済みです。NTLMv2はまだ動作しますが、非推奨の対象です(8章)。⁹ アプリはNTLMを直接指定せず、Kerberosを優先して選ぶNegotiateを使い、そのうえでKerberosが成立する名前・SPN・接続経路を整えます。¹

目的・症状から読む

本記事は仕組みと判断の説明です。監査設定や棚卸しを実施する手順は、冒頭で案内した実務編へ進んでください。

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

2. NTLMは何をしているのか

この章では、先に応答を作る側と、検証する側を分けます。ドメインアカウントでの3者のやり取りを見たあと、NTLMv2の実際の計算と、ローカルアカウントでの違いを確認します。

NTLM(Windows Challenge/Response)は、その名のとおりチャレンジ/レスポンス方式の認証プロトコルです。マイクロソフトの説明を要約すると、資格情報は対話型ログオン時に得られたドメイン名・ユーザー名・パスワードの一方向ハッシュで構成され、パスワードを回線に流さずに認証するために、認証を要求する側が「安全に保管されたNTLM資格情報にアクセスできること」を証明する計算を行います。¹

ここで重要なのは、認証の材料はパスワードそのものではなく、パスワードのハッシュだということです。この一点が、後で見るPass-the-Hashの成立条件になります。

2.1. ドメインアカウントなら3者が登場する

すでにログオン済みのユーザーが、ドメインアカウントでサーバー上のリソースへアクセスする場面を考えます。これは非対話型認証で、登場するのは次の3者です。¹

ポイントは、リソースサーバーがドメインユーザーの応答を自力で検証するのではなく、DCに計算を頼むことです。

図1とその下の7ステップは、Microsoftの概要ページが示す概念上の手順です。NTLMv2の正確な応答計算は2.2節で扱います。「誰が誰に検証を頼むか」を図1で読み、「どう計算するか」を図2で読むと混同せずに追えます。¹

sequenceDiagram
    autonumber
    participant C as クライアント
    participant S as サーバー
    participant DC as ドメインコントローラー

    Note over C: ログオン時にパスワードの<br/>ハッシュを計算し、パスワード本体は破棄
    C->>S: ユーザー名(平文)
    S->>C: 8バイトの乱数(チャレンジ)
    Note over C: チャレンジを<br/>パスワードのハッシュで暗号化
    C->>S: レスポンス
    S->>DC: ユーザー名 / チャレンジ / レスポンス
    Note over DC: SAMからハッシュを取り出し<br/>同じ計算をする
    DC-->>S: 一致すれば認証成功
    S-->>C: アクセスを許可

図1: NTLMの非対話型認証(ドメインアカウントの場合)

図1を手順で追うと、次の7ステップになります。NTLMv2の応答計算そのものは、次の2.2節で読み替えます。

1. (対話型認証のみ)ユーザーがドメイン名・ユーザー名・パスワードを入力する。クライアントはパスワードの暗号学的ハッシュを計算し、実際のパスワードは破棄する。
2. クライアントはユーザー名を平文でサーバーに送る。
3. サーバーは8バイトの乱数(チャレンジ、ノンス)を生成してクライアントに送る。
4. クライアントはこのチャレンジをユーザーのパスワードのハッシュで暗号化し、結果(レスポンス)を返す。
5. サーバーはユーザー名・クライアントに送ったチャレンジ・受け取ったレスポンスの3点をドメインコントローラーに送る。
6. ドメインコントローラーはユーザー名からSAMデータベースのパスワードハッシュを取り出し、それでチャレンジを暗号化する。
7. 自分で計算した結果とクライアントのレスポンスを比較し、同一なら認証成功。

2.2. 実際の計算 ── NTLMv2はもう少し込み入っている

上の7ステップは、マイクロソフトが概要ページで説明している基本形です。いまのWindowsが実際に使うNTLMv2は、「チャレンジをパスワードのハッシュで暗号化する」よりもう一段複雑です。仕様([MS-NLMP])では次のように定義されています。²

応答鍵を作り、チャレンジなどからHMACを計算する

• 応答鍵は NTOWFv2 = HMAC_MD5( MD4(UNICODE(パスワード)), 大文字化したユーザー名 + ドメイン名 )
• クライアントは、応答バージョン・時刻・クライアント側で生成した8バイトのチャレンジ・ターゲット情報(AVペア)を連結した temp を作る
• 応答の核となる NTProofStr = HMAC_MD5( 応答鍵, サーバーのチャレンジ + temp )

材料と処理の流れだけを取り出すと、次の1枚になります。

flowchart TD
    PW["パスワード"] --> MD4["MD4(UNICODE(パスワード))<br/>= NT ハッシュ"]
    UD["大文字化したユーザー名<br/>+ ドメイン名"] --> H1["HMAC_MD5"]
    MD4 -->|"これを鍵にする"| H1
    H1 --> KEY["応答鍵 NTOWFv2"]

    MAT["応答バージョン / 時刻 /<br/>クライアント側の8バイトチャレンジ /<br/>ターゲット情報(AVペア)"] --> TEMP["temp"]

    SC["サーバーのチャレンジ"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"これを鍵にする"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

図2: NTLMv2の応答ができるまで(パスワード → NTハッシュ → 応答鍵 → HMAC)

つまり実際には、サーバーのチャレンジだけでなく、クライアント側の乱数・時刻・宛先情報も混ぜたHMACを計算しています。検証側も同じ計算を再現します。アカウントがActive Directoryにあるならチャレンジと応答の組をドメインコントローラーへ送って検証し、サーバーにローカルなアカウントならサーバーが自分で保管しているOWFを使って期待値を計算します。²

計算が複雑になっても、変わらない2点

この記事の議論にとって重要なのは、複雑になっても次の2点が変わらないことです。

1. 鍵の材料は、いまもパスワードのハッシュです。NTOWFv2 の出発点は MD4(UNICODE(パスワード))、つまりNTハッシュそのものです。² だからPass-the-Hashは成立します(7.2節)。
2. クライアントは、サーバーが本物かを検証していません。NTLMには相互認証がない、というマイクロソフトの説明はNTLMv2でも変わりません。⁴

以降の説明は、この2点に乗っています。

2.3. ローカルアカウントなら2者で完結する

ローカルアカウントの場合は、図1の右側(ドメインコントローラー)が消えます。

リソースサーバーは、アカウントがドメインアカウントならそのドメインのドメインコントローラー上の認証サービスに問い合わせますが、ローカルアカウントならローカルのアカウントデータベースを参照します。¹⁰

つまりワークグループ機や、ファイルサーバーのローカルアカウントで共有に繋いでいる場合は、ドメインコントローラーは登場せず、サーバーが自分のSAMを見て自分で判定する2者のやり取りになります。

この違いは、6.3節で扱う「ローカルアカウントだからKerberosが使えない」という依存の棚卸しに直結します。ドメインコントローラーの監査ログを見ても、この経路のNTLMは出てきません。

2.4. この設計から出てくる3つの帰結

ここまでのやり取りから、後の障害や攻撃につながる性質を3つ取り出せます。

2行目の問い合わせが必要なのは、リソースサーバーが新しいアクセストークンを必要とするたびです。ドメインアカウントではDCの認証サービスへ、ローカルアカウントではローカルのアカウントデータベースへ確認します。¹⁰

また、チャレンジが毎回変わるため、同じレスポンスをそのまま使い回すことはできません。しかし、いま受け取ったチャレンジと応答を別のサーバーとの間で中継することは、それだけでは防げません。この違いを7章で見ます。

3. なぜサーバーはドメインコントローラーに聞くのか

NTLMは、ハッシュを持つ側に検証を頼む

ドメインユーザーのパスワードハッシュは、DC側のアカウントデータベースにあります。リソースサーバーはそのユーザーのハッシュを知らないため、受け取ったレスポンスを自力では検証できません。

そこで、ユーザー名・チャレンジ・レスポンスをDCに渡して判定を頼むのが、パススルー認証です。ドメインアカウントでのNTLM認証がDCへの問い合わせを必要とするのは、この役割分担によります。¹⁰¹

ローカルアカウントなら、ハッシュの確認先はサーバー自身のSAMです。「NTLMはDCに聞く」という説明は、ドメインアカウントの場合に限ります。

Kerberosは、チケットで問い合わせを置き換える

Kerberosは、更新可能なセッションチケットで、このパススルー認証を置き換えます。Microsoftは、NTLMではアプリケーションサーバーが認証のたびにDCへ接続する必要があったのに対し、Kerberosではその問い合わせが不要になると説明しています。⁴

ただし、PAC(特権属性証明書)の検証が必要な場合は例外です。「KerberosならサーバーからDCへの通信が一切ない」という意味ではありません。

つまり、Kerberosへの移行には、相手を確かめるという安全性の改善に加え、認証のたびのDCへの依存を減らすという運用上の意味もあります。次の章で、チケットがその役割を果たす仕組みを見ます。

4. Kerberosは何をしているのか

NTLMが認証のたびに応答を検証してもらうのに対し、Kerberosは先に本人確認をしてチケットを受け取り、そのチケットを次の認証に使う方式です。図3は、最初の本人確認からサービスへ接続するまでの一連の流れを示します。

KDC(鍵配布センター)はドメインコントローラー上で動作し、Active Directory Domain Servicesのデータベースをセキュリティアカウントデータベースとして使います。⁴

図を読む前に、名前とチケットを分ける

図3は、本人確認をしてTGTを得る → SPNを指定してサービスチケットを得る → サービスに提示するという3段階です。TGTとサービスチケットを同じものとして読まないことがポイントです。

sequenceDiagram
    autonumber
    participant C as クライアント
    participant KDC as KDC (ドメインコントローラー)
    participant S as サービス (SPNで識別)

    Note over C,KDC: AS交換 ── 本人確認とTGTの取得
    C->>KDC: KRB_AS_REQ<br/>(ユーザー名 + 長期鍵で暗号化した時刻)
    Note over KDC: 長期鍵で復号できれば本人
    KDC-->>C: KRB_AS_REP<br/>TGT(krbtgtの鍵で暗号化) + セッション鍵

    Note over C,KDC: TGS交換 ── サービスチケットの取得
    C->>KDC: KRB_TGS_REQ<br/>(TGT + 接続先のSPN + 認証子)
    Note over KDC: SPNからサービスアカウントを引き<br/>その長期鍵でチケットを暗号化
    KDC-->>C: KRB_TGS_REP<br/>サービスチケット + セッション鍵

    Note over C,S: AP交換 ── サービスへの提示
    C->>S: KRB_AP_REQ<br/>(サービスチケット + 認証子)
    Note over S: 自分の長期鍵で復号できる<br/>= 自分宛のチケット
    S-->>C: KRB_AP_REP(相互認証を要求した場合)

図3: Kerberosの3つの交換(AS / TGS / AP)

凡例 ── AS = Authentication Service(認証サービス)、TGS = Ticket Granting Service(チケット許可サービス)、AP = Application(アプリケーション)。メッセージ名の _REQ は要求、_REP は応答です。たとえば KRB_TGS_REQ は「チケット許可サービスへの要求」を意味します。

4.1. AS交換 ── 一度だけの本人確認

送るもの: 長期鍵で暗号化した時刻

クライアントはKDCに、ユーザー名・ドメイン名と、自分の長期鍵(パスワードから導出される鍵)で暗号化したタイムスタンプを送ります。これが事前認証(pre-authentication)です。KDCはその長期鍵で復号でき、しかもタイムスタンプが妥当なら「本人だ」と判断します。³

受け取るもの: TGTとセッション鍵

KDCからは、役割の違う2つのものが返ります。どちらも「クライアントが受け取るもの」ですが、クライアントが中身を読めるかどうかは違います。³

TGTを持つことと、TGTの中身を読めることは別です。この区別が、次の「TGTと認証子を添えて要求する」という手順につながります。

時刻がずれると、Kerberos自体が失敗する

ここで押さえておきたいのは、タイムスタンプが認証の一部になっていることです。Kerberosが時刻同期に厳しいのはこのためで、既定で許容される時刻差は5分です。⁷ ここを外すと事前認証が通らず、Kerberos認証そのものがエラーで失敗します(Windowsの時刻同期は「Windowsの時刻同期(w32time)ガイド」にまとめています)。この「Kerberosが失敗する」と「NTLMに落ちる」は別物です。区別は6.5節で扱います。

4.2. TGS交換 ── 「どのサービスに繋ぐか」を申告する

TGTを得たら、次は接続先のサービス向けのチケットを要求します。ここで初めて、「どのサービスに繋ぐか」という名前(SPN)が中心になります。³

クライアントはKDCへ、接続先のSPN・TGT・認証子を送ります。KDCはSPNに対応するサービスアカウントを探し、そのアカウントの長期鍵でサービスチケットを暗号化して返します。³

この流れを逆から読むと、6章で扱う問題が見えてきます。

• SPNが引けなければ、チケットを発行できません。 サービスアカウントにSPNが登録されていないと、KDCは誰の鍵を使えばよいか特定できません。IPアドレスでの接続も、既定ではKerberosを試みない条件です(6.1節)。
• チケットは宛先向けに作られます。 そのサービスの長期鍵で暗号化されているため、別の長期鍵を持つサービスでは復号できません。宛先を変えて使い回せないのは、このためです。

4.3. AP交換 ── サービスへの提示と相互認証

最後は、KDCではなく接続先のサービスとのやり取りです。ここも、サービス側の確認とクライアント側の確認を分けて読みます。

サービス側: 自分宛のチケットを開く

クライアントはサービスチケットと認証子を提示します。サービスは自分の長期鍵でチケットを復号し、セッション鍵と認可情報を取り出します。自分の鍵で復号できることが、そのチケットが自分宛であることの確認になります。³

クライアント側: 相互認証を要求した場合に相手を確かめる

クライアントが相互認証を要求していた場合、サービスは受け取ったタイムスタンプをセッション鍵で暗号化して返します。クライアントはその応答を検証し、相手が本物のサービスであることを確認します。³

サービスがクライアントを確認するだけでなく、クライアントもサービスを確認できる。 これが、NTLMにはない相互認証です。

5. 決定的な違い

2〜4章の仕組みを、運用や設計で効く観点から比較します。DCへの問い合わせはドメインアカウントかローカルアカウントかで違い、KerberosにもPAC検証という例外があります。 条件を含めて読んでください。

委任を使う設計は、さらに方式を選ぶ

委任は、たとえばフロントエンドのWebアプリが、ユーザーの代理としてバックエンドのSQL Serverへ接続するための仕組みです。サーバー内でユーザーを偽装することと、別のサービスまでユーザーの代理で進むことは分けて考えます。⁴

さらにKerberosの委任には、無制約の委任、制約付き委任(constrained delegation)、リソースベースの制約付き委任(RBCD)があります。「Kerberosを使う」と決めるだけでなく、どの委任方式を使うかが設計上の論点です。

本記事では方式ごとの設定には踏み込みません。この3つの名称は、委任が必要な構成を調べるときの次の検索語として押さえてください。

名前とドメインの条件が、次の切り分けにつながる

この表の下2行が、そのまま「NTLMに落ちる理由」になります。Kerberosの強さ(宛先を縛る、相手を検証する)は、名前が正しく引けることの上に成り立っているからです。

6. なぜNTLMに「落ちる」のか

この章では、「業務は動いているが、認証がNTLMになっている」理由を調べます。接続先の名前、SPNの登録、アカウント、KDCへの経路の順に確認してください。認証そのものがエラーになる場合は、先に6.5節で別の切り分けが必要かを確認します。

アプリケーションが直接NTLMを指定していなくても、NTLMは使われます。Negotiateがそう振る舞うからです。マイクロソフトの説明では、NegotiateはKerberosとNTLMのどちらかを選択し、認証に関わるシステムのいずれかがKerberosを使えない場合を除いてKerberosを選択します。¹

つまり、Negotiateを使っていても、Kerberosを成立させる条件が揃わなければNTLMが選ばれます。アプリがKerberosに対応していることと、その接続でKerberosが使われることは別です。

以下の図と表は、NTLMが利用できる構成での代表的な分岐です。NTLM自体が制限されている場合に、必ず認証が成功するという意味ではありません。まず切り替わる理由を調べ、認証方式への制限は8章・9章と併せて確認します。

flowchart TD
    START["Negotiate で認証を開始"]
    Q1{"ドメインの<br/>アカウント？"}
    Q2{"接続先名から<br/>SPN を作れる？"}
    Q3{"その SPN は<br/>登録済み？"}
    Q4{"KDC に<br/>届く？"}
    KRB["Kerberos で認証"]
    NTLM["NTLM にフォールバック"]

    START --> Q1
    Q1 -->|"いいえ<br/>(ワークグループ / ローカルアカウント)"| NTLM
    Q1 -->|はい| Q2
    Q2 -->|"いいえ<br/>(IP アドレス直打ち)"| NTLM
    Q2 -->|はい| Q3
    Q3 -->|"いいえ<br/>(SPN 未登録 / 別名でアクセス)"| NTLM
    Q3 -->|はい| Q4
    Q4 -->|"いいえ<br/>(拠点 / VPN / FW)"| NTLM
    Q4 -->|はい| KRB

図4: NegotiateがNTLMへ落ちる分岐

四大要因を、条件・理由・直し方の3列で先に並べておきます。詳細は6.1節以降で扱います。

6.1. IPアドレスで接続している

既定の動作: IPアドレスではKerberosを試みない

いちばん多い原因です。マイクロソフトは、既定ではホスト名がIPアドレスの場合、Windowsはそのホストに対してKerberos認証を試みず、NTLMなど有効な他の認証プロトコルにフォールバックすると明記しています。¹¹ 監査ガイドの側でも、イベント8001の「ターゲット サーバー」がNetBIOS形式でもFQDN形式でもなければKerberosは使われない、と書かれています。⁵

そして、そうなってしまう理由も挙げられています。設定ミスやベンダーのドキュメントのせいで、DNS名ではなくIPアドレスを使っているアプリケーションです。⁵ 「名前解決が不安定だから」と過去にIPへ書き換えた設定が、そのまま残っているケースも実務では非常に多く見ます。

例外: TryIPSPNと、実際に要求されるSPNを設定する

IPアドレスではKerberosを試みないのは、既定の動作であって、絶対の制約ではありません。 Windows 10 バージョン1507およびWindows Server 2016以降には、SPNのホスト名にIPアドレスを使える仕組みがあります。¹¹

必要なのは、次の両方です。

1. クライアント側でレジストリ値 TryIPSPN を1にする。
2. Setspn -s <サービスクラス>/<IPアドレス> <アカウント> の形で、IPアドレスを使ったSPNを手動登録する。

登録するSPNは、クライアントが実際に要求するサービスクラスと一致させます。元の接続先が同じIPアドレスでも、サービスによって必要な名前は違います。

host/ だけ登録しても、要求されるSPNと合わなければKerberosは成立しません。Microsoftはこの機能を、NTLM無効化による互換性への影響を減らすものと位置づけています。¹¹

まずFQDNへ直し、例外は最後の手段にする

とはいえ、これは第一選択ではありません。マイクロソフト自身が、IPアドレスは一時的なものでありリースの期限切れと更新にともなう競合や認証失敗を招きうるため通常はホスト名の代わりに使わず、IPアドレスベースのSPN登録は手動作業であり、DNSベースのホスト名に切り替えることが不可能な場合にのみ使うべきだとしています。¹¹ 監査で見つかったIPアドレス直打ちは、まずFQDNへ直すことを考えてください。TryIPSPN は、それがどうしてもできない相手に対する最後の手段です。

6.2. SPNが登録されていない

次に見るのは、実際にアクセスしている名前が、SPNとして登録されているかです。Microsoftは、Kerberos対応なのにNTLMを使うアプリの類型として、SPNが正しく構成されていないアプリを挙げています。⁵

図3のTGS交換では、KDCがSPNからサービスアカウントを引き、その長期鍵でチケットを暗号化します。SPNがなければ「そのサービスの鍵」を特定できません。

DNSの別名(CNAME)や独自のホスト名で接続しているときも、その名前のSPNが未登録なら同じことが起きます。名前でサーバーに辿り着けることと、その名前でKerberosのチケットを得られることは別です。

確認するのは、アプリの接続先に書かれた名前と、その名前に対して要求されるサービスクラスのSPNです。アプリが正しく動いていても、使っている名前だけが登録簿に載っていない場合があります。

6.3. そもそもActive Directoryの外にいる

いまNTLMが必要な経路を見つける

ワークグループ構成の端末や、ローカルアカウントでの共有アクセスは、Kerberosの土俵にありません。マイクロソフトも、ワークグループのメンバーとして構成されたシステムのWindows認証と、ドメインコントローラー以外でのローカルログオン認証には、NTLMが使われ、使われなければならないとしています。¹⁰

ローカルKDCで埋まる範囲と、埋まらない範囲を分ける

ここが、NTLMを「単純に禁止する」ことができない理由です。フェーズ2で予定されているローカルKDCは、まさにこの穴を埋めるための機能です。⁶

ただし、埋まるのは対応するWindows同士の場合だけだと考えてください。古いWindowsや、NAS・複合機のような他社製機器が相手のローカルアカウント認証は、ローカルKDCが来ても自動的にKerberosになるわけではありません。この仕分けは実務編の5章・6章で扱っています。

6.4. KDCに届かない

拠点やVPN越しでDCへ到達できない、あるいはKerberosに必要な通信がファイアウォールで止められる場合も、NTLMへ切り替わる原因になります。⁶ KDCから必要なチケットを取得できない場面では、Kerberosを使うための準備ができないからです。

ここでは「DCに届くか」を、誰からの通信かまで分けてください。

「クライアントがKDCへ届かない」と「NTLMならDCが不要」は同じ話ではありません。 3章で見たとおり、ドメインアカウントのNTLMではサーバー側からDCへの問い合わせが必要です。¹⁰ NTLMが選ばれても、その検証経路まで失われていれば認証は完了できません。

6.5. 「Kerberosの失敗」と「NTLMへの落下」を混同しない

Kerberosを始められない場合と、選ばれたあとに失敗する場合

最後に、紛らわしいけれど別物の話を切り分けておきます。ここまでの6.1〜6.4は、いずれも「Kerberosを始められなかった」ケースです。始められないからNegotiateはNTLMを選びます。

一方、Kerberosが選ばれたあとで失敗する問題は、別に調べます。代表例は、4.1節でも触れた時刻ずれです。

SPNを引けてKDCにも届けば、NegotiateはまずKerberosを選びます。しかし時刻差が許容範囲(既定5分)を超えていると、事前認証が通らず、Kerberosのエラーとして失敗します。⁷

「Kerberosが使えないからNTLMを選ぶ」ことと、「選んだKerberosが失敗したのでNTLMでやり直す」ことは同じではありません。Negotiateが必ず後者まで行うわけではなく、アプリケーションが明示的に別方式で再試行する場合は別に考える必要があります。

症状を分けてから、ログやコマンドを選ぶ

実務上の意味は単純です。時刻ずれの障害を、イベント8001を探して追いかけても見つかりません。症状も違います。

「NTLMに落ちているのか、Kerberosが壊れているのか」を先に分けてから調べてください。ここでいう「動くがNTLM」という症状は、NTLMが利用できる構成での話です。NTLMへの制限やブロックは8章・9章と分けて確認します。

7. 攻撃から見た差 ── リレーとPass-the-Hash

リレーとPass-the-Hashは、どちらもNTLMの問題として語られますが、使われるものが違います。

まず中継が通る条件を7.1節で、次にハッシュを盗まれた場合の問題を7.2節で見ます。

マイクロソフトはポリシー設定のドキュメントで、NTLMおよびNTLMv2認証は、SMBリレー、中間者攻撃、総当たり攻撃を含むさまざまな悪意ある攻撃に対して脆弱であると明記しています。⁸ なぜそうなるのかは、図1を見ると説明できます。

7.1. リレー攻撃 ── 宛先を縛らないことの帰結

sequenceDiagram
    autonumber
    participant V as 被害者のPC
    participant A as 攻撃者のサーバー
    participant T as 本物のサーバー

    Note over V,A: 攻撃者のサーバーへ誘導する
    V->>A: 認証を開始(ユーザー名)
    A->>T: 同じユーザーで認証を開始
    T-->>A: チャレンジ
    A-->>V: そのチャレンジをそのまま転送
    Note over V: 本物のサーバー由来かどうか<br/>区別できない
    V->>A: 応答(ハッシュ由来の鍵で計算)
    A->>T: そのレスポンスをそのまま転送
    Note over T: 署名も channel binding も<br/>要求していない場合
    T-->>A: 認証成功 → 被害者として接続確立

図5: NTLMリレーの成立(署名・チャネルバインディングのない相手の場合)

リレーは、パスワードやハッシュを盗まなくても成立する

攻撃者はパスワードもハッシュも知る必要がありません。チャレンジとレスポンスを右から左へ流すだけです。これが成立するのは、クライアント側に「この応答が本当に意図した相手へ渡っているか」を確かめる手段がないからです。

成立するかどうかは、接続先の防御で変わる

ただし、どんな相手にでも中継が通るわけではありません。中継されたやり取りが使えるセッションになるかどうかは、接続先の防御次第です。

• SMB署名を要求している相手には通りません。マイクロソフトは、SMBのすべてのメッセージに付く署名がメッセージ全体のハッシュを含み、送信者と受信者の身元を確認するため、リレー攻撃を防ぐと明記しています。¹² なお、ドメインコントローラーは既定で接続元にSMB署名を要求します。¹²
• Extended Protection for Authentication(チャネルバインディング)を強制しているサービスにも通りません。認証をその下のTLSチャネルに縛るため、別のチャネルへ中継した認証が通らなくなります。

図5の前提は、NTLMを受け付け、署名もチャネルバインディングも要求していない相手です。NTLMを使う接続すべてに、無条件でこの中継が通ると読んではいけません。

ここで確認するのは、防御機能に「対応しているか」だけでなく、実際に要求・強制しているかです。NTLMの棚卸しと並行して、SMB署名を要求する設定になっているかを確認する価値があります。

Kerberosへの移行と、SMB側の防御を合わせて考える

Kerberosでは、そもそも同じ形の中継ができません。サービスチケットは宛先サービスの長期鍵で暗号化されているため、別のサービスに持ち込んでも復号できません。³ さらに、クライアントは相互認証によって相手が本物かどうかを確認できます。⁴

マイクロソフトがSMBクライアント側のNTLMブロックを用意した理由も、まさにこれです。悪意のあるサーバーへNTLM要求を送らせる手口を防ぐことが目的だと説明されています。¹³

なお、SMB署名まわりの推奨としてマイクロソフトは、セッション鍵が強い状態で始まるようNTLMv2ではなくKerberosを使うこと、そしてIPアドレスやCNAMEレコードで共有に接続しないこと(そうするとKerberosではなくNTLMが使われるため)も挙げています。¹² 6.1節・6.2節と同じ話です。

7.2. Pass-the-Hash ── ハッシュがパスワードと等価であること

flowchart LR
    P["パスワード"] -->|"一方向ハッシュ"| H["パスワードのハッシュ"]
    H -->|"応答鍵を導出し<br/>HMAC を計算"| R["レスポンス"]
    R --> AUTH["認証成功"]
    STEAL["端末から<br/>ハッシュを窃取"] --> H
    NOTE["平文パスワードは<br/>不要"] -.-> STEAL

図6: 認証に必要なのはハッシュであって、平文パスワードではない

ハッシュから応答を作れることが問題になる

NTLMの資格情報の材料は、パスワードの一方向ハッシュです。¹ NTLMv2でも、MD4(UNICODE(パスワード)) を鍵として応答鍵を導き、その鍵でHMACを計算して応答を作ります。²

つまり、計算が複雑になっても出発点は変わりません。ハッシュを手に入れた攻撃者は、平文パスワードを解読しなくても、そのユーザーとして認証するための計算ができます。

パスワードの複雑さだけでは、この経路を塞げない

長く複雑なパスワードにすることと、ハッシュを盗まれたあとに使わせないことは別です。パスワードを複雑にしても、ハッシュを盗んで利用する経路は残ります。 MicrosoftはSMBのNTLMブロックで対抗する攻撃として、総当たり・クラッキングに加えてPass-the-Hashを挙げています。¹³

Kerberosにも長期鍵はあります。ただし、日常の認証でやり取りするのは有効期限のあるチケットとセッション鍵です。³ 何を盗まれたかによって有効な範囲が違う、という点まで含めて比べる必要があります。

8. NTLMv1・NTLMv2と「削除」

NTLMは1つのプロトコルではなく、LAN Managerバージョン1・2とNTLMバージョン1・2を含む認証プロトコルの一群です。¹⁰

ここで区別するのは、非推奨と削除です。非推奨は積極的な機能開発の対象外であること、削除は対象バージョンで使えないことを意味します。

次の表は、2024年6月の非推奨告知と、その後のNTLMv1削除を並べたものです。1行目の「動作する」という告知を、2行目の対象OSでもNTLMv1が使えるという意味に読まないでください。 NTLMv1については、その後の削除が適用されます。⁹

NTLMv1しか使えない相手を最優先で洗い出す

つまり「NTLMv2だから当面は放置してよい」ではありません。ただし優先順位ははっきりしていて、NTLMv1しか話せない機器やホストが最優先です。監査で NTLM V1 が記録されているホストは、そのまま新しいWindowsに上げると認証が通らなくなります。バージョンの見分け方(セキュリティログの「パッケージ名 (NTLM のみ)」を見る)は、実務編の記事の4.4節で扱っています。⁵

制限ポリシーは、v1とv2の両方に効く

なお、NTLMを制限する監査およびブロックのポリシーは、NTLMv1とNTLMv2の両方に同じ効果を持ちます。⁵ 制限を掛けるときにバージョンで挙動が変わることはありません。

9. これからどうなるのか

移行の方向は、アプリの呼び出しを変える → NTLMが必要な場面を減らす → ネットワーク認証の既定を変える、の順で捉えると分かりやすくなります。

以下のIAKerb・ローカルKDCの提供時期や既定無効化は、引用したMicrosoftのロードマップにある計画として説明します。提供済みの機能や、すべての機器で自動的に使える機能として扱うものではありません。⁶

1つ目: アプリケーション側でNegotiateを使う

NTLMの呼び出しはNegotiateの呼び出しに置き換えるべき、というのが非推奨告知そのものに含まれる指示です。⁹ アプリケーションはNTLMセキュリティパッケージに直接アクセスすべきではない、とも明記されています。¹

2つ目: NTLMが必要になる場面そのものを減らす

フェーズ2(2026年後半)で予定されているIAKerbとローカルKDCが、これに当たります。⁶ 6.3節で見た「ローカルアカウントだからKerberosが使えない」「ドメインコントローラーに届かないからKerberosが使えない」という2つの穴を、プロトコル側で埋めにいく試みです。

ただし埋まる範囲には限りがあります。IAKerbが解くのはドメインコントローラーへの到達性であって、相手の対応可否ではありません。ローカルKDCも、対応するWindows同士でなければ効きません。

他社製のNASや複合機が相手なら、フェーズ2を待っても状況は変わらないので、機器の更改・ドメイン参加・別プロトコルへの切り替え・例外管理のいずれかを自分で選ぶ必要があります。

3つ目: ネットワークNTLM認証の既定を変える

フェーズ3では、次期メジャーリリースでネットワークNTLM認証が既定で無効になる計画です。⁶ ただしポリシーで再度有効にできる、という前提も示されています。

いま行うこと: 新機能で対応が期待できる依存と、自分で直す依存を仕分ける

この計画は、「NTLMを使う理由をなくしてから、既定を変える」という順序です。自社の依存も、次のように分けておくと、待つべきものと先に直すものを混同せずに済みます。

古いWindowsや他社製機器との認証を、一律に「フェーズ2待ち」へ入れないことが重要です。自動的にKerberosへ変わるわけではなく、放置すると既定無効化の段階で障害として表面化します。

具体的な棚卸しと仕分けの手順は、実務編にまとめています。

10. まとめ

最後に、判断の順序に沿って整理します。

仕組み: ハッシュによる応答か、宛先向けのチケットか

NTLMは、パスワードのハッシュをもとにチャレンジへの応答を作ります。検証するのは、ドメインアカウントならDC、ローカルアカウントならサーバー自身のSAMです。¹¹⁰

Kerberosは、宛先サービスの長期鍵で暗号化されたチケットを使います。³ 相互認証、認証のたびのDCへの問い合わせ、委任という違いを押さえると、2つの方式を使い分ける前提が見えます。⁴

切り分け: NTLMで動くのか、認証自体が止まるのか

NTLMへ切り替わっているなら、IPアドレス直打ち・SPN未登録・Active Directoryの外・KDCへの到達性という4つの条件を確認します。⁵⁶¹¹

一方、時刻ずれのように、Kerberosが選ばれたあとで認証エラーになる問題は別です。NTLM/Operationalのイベント8001だけを追うのではなく、Kerberos側のイベントや時刻同期を調べます。⁷ 「動くからKerberos」「止まったからNTLMへ落ちた」と判断しないことが、調査の出発点です。

対応: 防御を確認し、Negotiateと名前の整備へ進む

NTLMのやり取りを中継するリレーと、盗んだハッシュを使うPass-the-Hashは、成立する理由も必要な材料も違います。⁸¹¹³ 接続先の防御条件を確認しながら、NTLM依存そのものを減らしていきます。

NTLMv1はWindows 11 24H2 / Windows Server 2025で削除済みで、NTLMv2を含む全バージョンが非推奨です。⁹ アプリではNegotiateを使い、接続先をFQDNへ揃え、SPNを登録する。¹⁵ そのうえで、新機能による対応が期待できる依存と、自分で直す必要がある依存を分けて移行を進めてください。

関連記事

• NTLM廃止で業務アプリは止まるか ── 監査ログの取り方と、依存を潰す順番
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• Windowsの時刻同期(w32time)ガイド
• Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める
• PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する
• WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動
• 情報セキュリティ10大脅威 2026 ── ランキングの眺め方と、中小企業が本当に対策すべきもの

関連する相談領域

合同会社小村ソフトでは、認証方式の見直しにともなうWindows業務アプリの改修や、Kerberos/NTLMまわりの認証トラブルの原因調査を扱っています。

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

参考リンク

</content>

関連する記事

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

関連トピック

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

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

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

よくある質問

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

NTLMとKerberosは、結局のところ何が違うのですか？

いちばん大きな違いは「相手を確かめられるかどうか」です。マイクロソフトは、NTLMではクライアントがサーバーの身元を検証することも、あるサーバーが別のサーバーの身元を検証することもできない、と明記しています。NTLMは「サーバーは本物である」と仮定できる環境向けに設計されたもので、Kerberosはその仮定を置きません。2つ目の違いは、サーバーがドメインコントローラーに問い合わせる必要があるかどうかです。NTLMでは、ドメインアカウントでの認証の場合、アプリケーションサーバーはクライアントを認証するたびにドメインコントローラーへ接続します(サーバーにローカルなアカウントなら、サーバーが自分のアカウントデータベースを引いて自分で判定するので、ドメインコントローラーは登場しません)。Kerberosでは更新可能なセッションチケットがこのパススルー認証を置き換えるため、サーバーはPACの検証が必要な場合を除きドメインコントローラーへ行きません。3つ目は、Kerberosがサービスによる委任(クライアントの代理として他のサービスへ接続する仕組み)をサポートしていることです。

Kerberosに対応しているはずなのに、なぜNTLMになってしまうのですか？

Kerberosは「接続先の名前」を鍵にしてチケットを発行する仕組みなので、名前が引けないと成立しません。クライアントは接続先のSPN(サービスプリンシパル名)をKDCに提示してサービスチケットを要求しますが、既定ではホスト名がIPアドレスの場合にWindowsはKerberos認証を試みませんし、サービスアカウントにSPNが登録されていなければKDCはチケットを発行できません。マイクロソフトの監査ガイドも、イベント8001の「ターゲット サーバー」がNetBIOS名でもFQDN形式でもなければKerberosは使われない、と書いています(IPアドレスについては、クライアントにTryIPSPNを設定してIPアドレスのSPNを手動登録すれば例外的にKerberosを成立させられますが、DNS名に変えられない場合の最後の手段とされています)。ほかに、ワークグループ機やローカルアカウントでの認証(そもそもActive Directoryの外)、ドメインコントローラーに到達できない拠点、信頼関係のない相手への認証も、Kerberosが成立しない条件です。NegotiateはKerberosが使えないときにNTLMを選ぶので、これらの場合に「落ちる」ことになります。

NTLMリレー攻撃とは何ですか？なぜ成立するのですか？

攻撃者が自分のサーバーへ被害者を誘導し、そこに届いたNTLMの認証やり取りを、そのまま本物のサーバーへ中継して被害者になりすます攻撃です。成立する理由は、NTLMのチャレンジ/レスポンスに「誰に対して認証しているか」を縛る仕組みがないからです。クライアントはサーバーが出したチャレンジをもとに応答を計算して返すだけで、その応答が本物のサーバー宛なのか攻撃者が中継してきたものなのかを、クライアント側で確かめる手段がありません。マイクロソフト自身も、NTLMおよびNTLMv2認証がSMBリレー、中間者攻撃、総当たり攻撃を含むさまざまな悪意ある攻撃に対して脆弱であるとポリシー設定のドキュメントに明記しています。ただし、どんな相手にでも中継が通るわけではありません。接続先がSMB署名を要求していれば署名が送信者と受信者の身元を確認するためリレーは成立しませんし、Extended Protection for Authentication(チャネルバインディング)を強制しているサービスでも同様です。裏を返せば、署名も channel binding も掛かっていない、NTLMを受け付ける相手が狙われます。Kerberosでは、サービスチケットがそのサービスの長期鍵で暗号化されているため、宛先の違うチケットを別のサービスへ持ち込んでも復号できません。

Pass-the-Hashは、パスワードを解読しなくてもなりすませるということですか？

そのとおりです。NTLMの資格情報は、ドメイン名・ユーザー名・パスワードの一方向ハッシュで構成されます。いまのWindowsが使うNTLMv2では、応答鍵がパスワードのMD4ハッシュ(NTハッシュ)を鍵とするHMACとして導出され、その鍵でサーバーのチャレンジ・時刻・クライアント側のチャレンジ・ターゲット情報をまとめたものに対するHMACを計算します。単純にチャレンジを暗号化するだけではありませんが、出発点がパスワードのハッシュであることは変わりません。つまり認証に必要なのはハッシュであって平文パスワードではありません。したがって、端末のメモリなどからハッシュを取り出せた攻撃者は、パスワードを解読しなくてもそのユーザーとして認証できてしまいます。パスワードを長く複雑にしても、この経路は塞げません。マイクロソフトがSMBクライアント側のNTLMブロック機能を用意した理由の1つにも、Pass-the-Hash攻撃への対抗が挙げられています。

NTLMv2を使っていれば、当面は安全ではないのですか？

NTLMv2はNTLMv1より強くはありますが、非推奨の対象からは外れていません。マイクロソフトの非推奨機能一覧は、LANMAN、NTLMv1、NTLMv2を含むすべてのバージョンのNTLMが積極的な機能開発の対象外であり非推奨である、としています。制限ポリシーの動作も同じで、監査およびブロックのポリシーは2つのバージョンに対して同じ効果を持つと説明されています。一方でNTLMv1については扱いが異なり、非推奨ではなく削除の段階に入っていて、Windows 11 バージョン24H2およびWindows Server 2025からは削除されています。したがって「NTLMv2だから当面は放置してよい」ではなく、「NTLMv1は今すぐ期限、NTLMv2は既定無効化に向けて棚卸しを進める」という整理になります。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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