合同会社小村ソフト
相談する
メニュー

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

· 更新日: · · NTLM, Kerberos, Windows, Active Directory, セキュリティ, 認証, 情報システム

更新履歴(4件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

この記事の知識マップに含まれる関係を見直しました。本文より広い主張になっていたもの(条件付きでしか成り立たない関係、「防ぐ」ではなく「軽減する」にあたる関係、前提ではなく推奨にあたる関係)を、条件付きに改めるか、より正確な述語に置き換えています。本文の主張は変えていません。
記事の冒頭に「この記事の知識マップ」を追加しました。本文で扱う概念どうしの関係を一枚の図で見渡せます。関係の全一覧(根拠のURL・確度・確認日つき)と主要概念の定義は知識マップ詳細ページにまとめ、機械可読データをJSON-LDとTurtleで公開しています。 更新前のバージョンを見る (DOI: 10.5281/zenodo.21733186)
外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
NTLMv2の応答計算のフロー図を追加しました(図が1つ増えたため以降の図番号と本文中の参照も振り直しています)。うまくいかないときの章に「条件 → なぜ落ちるか → 直し方」の3列表を追加し、「Kerberosが失敗する」と「NTLMに落ちる」の区別を結論の独立した項目に格上げしました。Kerberosの図に略号の凡例、委任の3方式への言及も加えています。
初版公開
この記事を引用する(DOI: 10.5281/zenodo.21639640)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村 豪(2026)「図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか」合同会社小村ソフト. https://doi.org/10.5281/zenodo.21639640 https://staging.comcomponent.com/blog/ntlm-kerberos-explained/

DOI(最新版)
10.5281/zenodo.21639640
DOI(この版)
10.5281/zenodo.21739456

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

なぜそうなるのかは、2つのプロトコルが「何を証明しようとしているのか」を並べて見ると一目で分かります。この記事は、NTLMとKerberosの動きを図で押さえ、どういう条件でNTLMに落ちるのか、そしてなぜマイクロソフトがNTLMをやめようとしているのかを、公式ドキュメントの裏付けつきで整理するものです。

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

1. まず結論

  • NTLMは「パスワードのハッシュを持っていること」だけを証明します。資格情報はドメイン名・ユーザー名・パスワードの一方向ハッシュで、1 いまのWindowsが使うNTLMv2では、そのハッシュから導いた鍵で「サーバーのチャレンジ+時刻+クライアント側のチャレンジ+ターゲット情報」に対するHMACを計算して返します(2.2節)。2
  • Kerberosは「誰が、どのサービスに対して」を証明します。接続先のサービス名(SPN)を鍵にしてチケットを発行するので、宛先が違うチケットは使えません。3
  • 決定的な差は3つです。相互認証の有無、(ドメインアカウントの認証で)サーバーがドメインコントローラーへ問い合わせるかどうか、委任ができるかどうか。いずれもマイクロソフトが明記しています(5章)。4
  • NTLMに落ちる最大の理由は「名前」です。Kerberosは接続先の名前からSPNを引けないと始まりません。IPアドレス直打ち、SPN未登録、ワークグループ、DCに到達できない経路が四大要因です(6章)。56
  • 「Kerberosが失敗する」と「NTLMに落ちる」は別の現象です。前者はKerberosが選ばれたうえでエラーになる状態(時刻ずれなど)で、認証そのものが止まります。後者はKerberosを始められずに静かにNTLMへ切り替わる状態で、業務は動いたまま残ります。障害の切り分けはこの二択から始めてください(6.5節)。7
  • リレー攻撃が成立するのは、NTLMに「誰に対して認証しているか」を縛る仕組みがないからです。Pass-the-Hashが成立するのは、認証に必要なものがハッシュそのものだからです(7章)。81
  • NTLMv1はすでに削除されています。Windows 11 バージョン24H2とWindows Server 2025が対象です。NTLMv2は非推奨ですが、まだ動きます(8章)。9
  • アプリが書くべきはNegotiateです。NegotiateはKerberosとNTLMのどちらかを選び、認証に関わるシステムのいずれかがKerberosを使えない場合を除いてKerberosを選びます。1

この記事の知識マップ

NTLMはパスワードのハッシュを持っていることだけをチャレンジ/レスポンスで証明するプロトコルで、相互認証を持たず宛先を縛りません。Kerberosは接続先のSPNを鍵にチケットを発行し、相互認証と宛先の縛りを提供します。NegotiateはKerberosを優先しますが、SPNが引けない・ワークグループ・DCに届かないといった条件でNTLMへ落ち、この設計の隙がリレー攻撃とPass-the-Hashを成立させます。

NTLMとKerberosの知識マップNTLMとKerberosという2つの認証プロトコルの仕組みの違い(チャレンジ/レスポンスとチケット、相互認証の有無、ドメインコントローラーへの依存、委任)、NegotiateがNTLMへ落ちる条件(SPN・名前解決・ワークグループ・DC到達性)、リレー攻撃とPass-the-Hashが成立する理由とSMB署名による防御、NTLMv1/NTLMv2の非推奨・削除状況の関係を示す図利用する利用する前提とする前提とする前提とする利用する利用する前提とする実装を担う原因になり得る原因になり得る防止する防止する両立しない前提とする前提とするの後継前提とするの後継利用する利用する利用する原因になり得る軽減する実装を担うで構成できるで確認できる前提とする前提とする前提とする軽減する軽減する推奨される対応前提とする前提とするNTLMKerberosNegotiateSPNKDCActive Directory(AD DS)TGT(チケット許可チケット)Kerberosサービスチケット相互認証NTLMリレー攻撃Pass-the-HashSMB署名ワークグループ構成ドメインコントローラーKerberosの時刻同期要件NTLMv2NTLMv1NTハッシュSMBクライアント側のNTLMブロックKerberosの委任「NTLMを制限する」ポリシー群NTLM/OperationalログIAKerbローカルKDCTryIPSPN

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

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

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

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

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

すでにログオン済みのユーザーがドメインアカウントでサーバー上のリソースにアクセスする場面(非対話型認証)では、クライアント・サーバー・ドメインコントローラーの3者が関わります。このときサーバー自身は認証の計算をせず、ドメインコントローラーに代わりに計算してもらうのが特徴です。1

ドメインコントローラーサーバークライアントドメインコントローラーサーバークライアントログオン時にパスワードのハッシュを計算し、パスワード本体は破棄チャレンジをパスワードのハッシュで暗号化SAMからハッシュを取り出し同じ計算をするユーザー名(平文)18バイトの乱数(チャレンジ)2レスポンス3ユーザー名 / チャレンジ / レスポンス4一致すれば認証成功5アクセスを許可6

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

マイクロソフトが概念として示している手順は次のとおりです(実際の計算は後述するとおりNTLMv2で変わりますが、登場人物と役割分担はこの図のままです)。1

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

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

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

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

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

これを鍵にするこれを鍵にするパスワードMD4(UNICODE(パスワード))= NT ハッシュ大文字化したユーザー名+ ドメイン名HMAC_MD5応答鍵 NTOWFv2応答バージョン / 時刻 /クライアント側の8バイトチャレンジ /ターゲット情報(AVペア)tempサーバーのチャレンジHMAC_MD5NTProofStrNtChallengeResponse= NTProofStr + temp

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

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

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

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

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

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

ローカルアカウントの場合は、この図の右側が消えます。リソースサーバーは、アカウントがドメインアカウントならそのドメインのドメインコントローラー上の認証サービスに問い合わせますが、ローカルアカウントならローカルのアカウントデータベースを参照します。10 つまりワークグループ機や、ファイルサーバーのローカルアカウントで共有に繋いでいる場合は、ドメインコントローラーは登場せず、サーバーが自分のSAMを見て自分で判定する2者のやり取りになります。

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

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

図1を眺めると、後で問題になる性質がそのまま読み取れます。

  • サーバーはクライアントに何も証明していない。やり取りは一方通行で、サーバーが「自分は本物である」ことを示す手順がどこにもありません。
  • サーバーは自分でハッシュを持っているときしか判定できない。リソースサーバーは、新しいアクセストークンが必要になるたびに、ドメインアカウントならドメインコントローラーの認証サービスへ問い合わせ、ローカルアカウントならローカルのアカウントデータベースを参照する必要があります。10ドメインアカウントでの認証がドメインコントローラー頼みになるのはこのためです。
  • レスポンスは「そのチャレンジ限り」だが、宛先を縛らない。チャレンジが毎回違うので同じレスポンスの使い回しはできません。しかし「このレスポンスはどのサーバー向けか」を証明する要素がないため、別のサーバーへ横流しされても気づけません。

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

ドメインアカウントでの認証では、パスワードのハッシュを持っているのはドメインコントローラー側のアカウントデータベースだけです。リソースサーバーはそのユーザーのハッシュを知らないので、自力では検証できません。だから認証のたびにドメインコントローラーへ問い合わせる(パススルー認証)必要があります。101(ローカルアカウントなら、サーバーは自分のSAMを引いて自分で判定します。ドメインコントローラーへの依存という以下の話は、ドメインアカウントの場合のものです。)

これは安全性の面でも運用の面でも代償があります。マイクロソフトは、Kerberos以前のNTLM認証ではアプリケーションサーバーがクライアントやサービスを認証するたびにドメインコントローラーへ接続する必要があったのに対し、Kerberosでは更新可能なセッションチケットがパススルー認証を置き換え、サーバーはPAC(特権属性証明書)の検証が必要な場合を除きドメインコントローラーへ行く必要がないと説明しています。4

つまりKerberosへの移行は、セキュリティの話であると同時に、ドメインコントローラーへの依存を減らす話でもあります。

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

Kerberosの発想は、NTLMとはっきり違います。認証のたびに本人確認をやり直すのではなく、最初に一度だけ本人確認をして「チケット」を受け取り、以降はそのチケットを見せる方式です。

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

サービス (SPNで識別)KDC (ドメインコントローラー)クライアントサービス (SPNで識別)KDC (ドメインコントローラー)クライアントAS交換 ── 本人確認とTGTの取得長期鍵で復号できれば本人TGS交換 ── サービスチケットの取得SPNからサービスアカウントを引きその長期鍵でチケットを暗号化AP交換 ── サービスへの提示自分の長期鍵で復号できる= 自分宛のチケットKRB_AS_REQ(ユーザー名 + 長期鍵で暗号化した時刻)1KRB_AS_REPTGT(krbtgtの鍵で暗号化) + セッション鍵2KRB_TGS_REQ(TGT + 接続先のSPN + 認証子)3KRB_TGS_REPサービスチケット + セッション鍵4KRB_AP_REQ(サービスチケット + 認証子)5KRB_AP_REP(相互認証を要求した場合)6

図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はその長期鍵で復号でき、しかもタイムスタンプが妥当なら「本人だ」と判断します。3

KDCはTGT(チケット許可チケット)を返します。TGTはKDC自身の長期鍵(krbtgtアカウントの鍵)で暗号化されているので、クライアントは中身を読めません。あわせて、クライアントとKDCの間で使うセッション鍵が、クライアントの長期鍵で暗号化されて渡されます。3

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

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

ここがNTLMとの決定的な分岐点です。クライアントは接続したいサービスの名前(SPN)をKDCに伝え、TGTと認証子を添えてサービスチケットを要求します。3

KDCは、そのSPNに対応するサービスアカウントを探し、そのアカウントの長期鍵でサービスチケットを暗号化して返します。3 だから、

  • SPNが引けなければ、チケットは発行されません。サービスアカウントにSPNが登録されていなければ、KDCは相手を特定できません。接続先をIPアドレスで指定した場合も、既定ではKerberosが試みられません(6.1節)。
  • チケットは「その宛先専用」です。別のサービスの長期鍵では復号できないので、宛先を変えて使い回すことができません。

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

クライアントはサービスチケットと認証子をサービスに提示します。サービスは自分の長期鍵でチケットを復号し、中のセッション鍵と認可情報を取り出します。復号できたこと自体が「このチケットは自分宛だ」の証明になります。3

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

5. 決定的な違い

観点 NTLM Kerberos
相手の検証 クライアントによるサーバーの検証も、サーバーによる別サーバーの検証もできない。サーバーは本物だと仮定する設計4 接続の両端が、相手が名乗るとおりの相手であることを検証できる4
認証のたびのDC問い合わせ ドメインアカウントなら必要。リソースサーバーは新しいアクセストークンのたびにDCへ問い合わせる(ローカルアカウントなら自分のアカウントデータベースを引く)10 不要(PACの検証が必要な場合を除く)。更新可能なセッションチケットが置き換える4
宛先の縛り なし。レスポンスは「誰に対してか」を証明しない あり。サービスチケットは宛先サービスの長期鍵で暗号化されている3
委任 ローカルでの偽装に必要な認可情報までを提供4 サービスがクライアントの代理として他のサービスへ接続する委任をサポート4
時刻同期 依存しない 依存する(既定の許容差は5分)7
名前解決 相手の名前を問わない(IPアドレスでも成立する) SPNが引けることが前提3
ドメイン外での利用 ワークグループ構成やローカルログオンでは今も必要10 Active Directoryが前提4

「委任」の行は、実務ではさらに枝分かれします。委任には、無制約の委任・制約付き委任(constrained delegation)・リソースベースの制約付き委任(RBCD)といった種別があり、フロントエンドのWebアプリからバックエンドのSQL Serverへユーザーの資格で繋ぐ、といった構成ではどれを選ぶかが設計上の論点になります。この記事では踏み込みませんが、Kerberosの委任を調べるときの次の検索語として覚えておいてください。

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

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

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

つまり「NTLMになった」は、ほとんどの場合「Kerberosが使えなかった」の言い換えです。

いいえ(ワークグループ / ローカルアカウント)はいいいえ(IP アドレス直打ち)はいいいえ(SPN 未登録 / 別名でアクセス)はいいいえ(拠点 / VPN / FW)はいNegotiate で認証を開始ドメインのアカウント？接続先名からSPN を作れる？その SPN は登録済み？KDC に届く？Kerberos で認証NTLM にフォールバック

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

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

条件(こうなっていると落ちる) なぜ落ちるか 直し方
接続先をIPアドレスで指定している(6.1節) 既定では、ホスト名がIPアドレスの場合にWindowsはKerberos認証を試みない11 接続先の設定をFQDNに直す。どうしても不可能な相手にだけ、クライアントの TryIPSPN を1にしてIPアドレスのSPNを手動登録する(最後の手段)11
SPNが登録されていない/DNSの別名でアクセスしている(6.2節) KDCがSPNからサービスアカウントを引けず、そのアカウントの長期鍵でチケットを暗号化できない3 実際にアクセスしている名前で、要求されるサービスクラスのSPNを登録する。CNAMEを使うならその名前のSPNも必要5
ワークグループ機/ローカルアカウントでのアクセス(6.3節) Active Directoryの外なので、そもそもKDCがいない10 ドメイン参加、またはドメインアカウントでのアクセスに切り替える。フェーズ2のローカルKDCで埋まるのは対応するWindows同士の場合だけ6
ドメインコントローラーに到達できない(6.4節) KDCと話せないのでチケットを取得できない6 経路とファイアウォールを見直し、Kerberosに必要な通信がKDCまで届くようにする

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

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

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

ただし、これは既定の挙動であって、絶対の制約ではありません。Windows 10 バージョン1507およびWindows Server 2016以降には、SPNのホスト名としてIPアドレスを使えるようにする仕組みがあります。クライアント側のレジストリ値 TryIPSPN を1にしたうえで、Setspn -s <サービスクラス>/<IPアドレス> <アカウント> の形でIPアドレスのSPNを手動登録すると、IPアドレス宛でもKerberosが成立します。登録するのはクライアントが実際に要求するサービスクラスで、共有フォルダのように HOST にマップされるものは host/192.168.1.1 で足りますが、Webなら HTTP/192.168.1.1、SQL Serverなら MSSQLSvc/192.168.1.1:1433 のようにポートまで含めた別のSPNが必要です。host/ だけ登録しても、要求されるSPNと一致しなければKerberosは成立しません。マイクロソフトはこの機能を、まさにNTLM無効化の影響を減らすためのものと位置づけています。11

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

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

2番目に多い原因です。マイクロソフトは、Kerberosに対応していてもNTLMを使ってしまうアプリの類型として、SPNが正しく構成されていないアプリケーションを挙げています。5

図3のTGS交換で見たとおり、KDCはSPNからサービスアカウントを引いてチケットを暗号化します。SPNが無ければ、KDCは「そのサービスの鍵」を特定できません。DNSの別名(CNAME)や独自のホスト名でアクセスしている場合も、その名前のSPNが登録されていなければ同じことが起きます。アプリは正しく動いているのに、名前だけが登録簿に載っていない、という状態です。

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

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

ここが、NTLMを「単純に禁止する」ことができない理由です。フェーズ2で予定されているローカルKDCは、まさにこの穴を埋めるための機能です。6 ただし、埋まるのは対応するWindows同士の場合だけだと考えてください。古いWindowsや、NAS・複合機のような他社製機器が相手のローカルアカウント認証は、ローカルKDCが来ても自動的にKerberosになるわけではありません。この仕分けは実務編の5章・6章で扱っています。

6.4. KDCに届かない

拠点やVPN越しでドメインコントローラーに到達できない、Kerberosに必要なポートがファイアウォールで塞がれている、といった経路の問題でもフォールバックが起きます。6 KDCと話せなければチケットを取りようがないので、Negotiateは残る選択肢であるNTLMを選びます。

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

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

一方、Kerberosが選ばれて、そのうえで失敗した場合は話が違います。代表例が時刻ずれです。SPNが引けてKDCにも届いていれば、NegotiateはまずKerberosを選びます。そのあと時刻が許容差(既定5分)を超えていれば、事前認証が通らずKerberosのエラーとして失敗します。7 選んだプロトコルが失敗したからといって、Negotiateが自動的にNTLMへ切り替えてやり直すわけではありません(アプリケーションが明示的に別の方式で再試行する場合を除きます)。

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

症状 疑うもの 見る場所
動くが、認証がNTLMになっている 6.1〜6.4(Kerberosを始められていない) NTLM/Operational のイベント8001
認証そのものがエラーで失敗する 時刻ずれ、SPNの重複登録、暗号化タイプの不一致など システムログのKerberosイベント、klist、w32tm /query /status

「NTLMに落ちているのか、Kerberosが壊れているのか」を先に分けてから調べてください。

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

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

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

本物のサーバー攻撃者のサーバー被害者のPC本物のサーバー攻撃者のサーバー被害者のPC攻撃者のサーバーへ誘導する本物のサーバー由来かどうか区別できない署名も channel binding も要求していない場合認証を開始(ユーザー名)1同じユーザーで認証を開始2チャレンジ3そのチャレンジをそのまま転送4応答(ハッシュ由来の鍵で計算)5そのレスポンスをそのまま転送6認証成功 → 被害者として接続確立7

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

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

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

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

つまり図5が描いているのは、署名もチャネルバインディングも掛かっていない、NTLMを受け付ける相手という条件下での成立経路です。裏返せば、これは実務でいますぐ打てる手があるということでもあります。NTLMの棚卸しと並行して、SMB署名の要求状況を確認しておく価値があります。

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

マイクロソフトがSMBクライアント側のNTLMブロックを用意した理由も、まさにこれです。悪意のあるサーバーへNTLM要求を送らせる手口を防ぐことが目的だと説明されています。13 なお、SMB署名まわりの推奨としてマイクロソフトは、セッション鍵が強い状態で始まるようNTLMv2ではなくKerberosを使うこと、そしてIPアドレスやCNAMEレコードで共有に接続しないこと(そうするとKerberosではなくNTLMが使われるため)も挙げています。12 6.1節・6.2節と同じ話です。

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

一方向ハッシュ応答鍵を導出しHMAC を計算パスワードパスワードのハッシュレスポンス認証成功端末からハッシュを窃取平文パスワードは不要

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

NTLMの資格情報はパスワードの一方向ハッシュです。1 NTLMv2では、その MD4(UNICODE(パスワード)) を鍵として応答鍵を導き、さらにその鍵でHMACを計算して応答を作ります。2 計算の形は変わっても、出発点がハッシュであることは変わりません。つまり、認証に必要なものはハッシュであって、平文パスワードではありません。

この帰結は運用上とても重い意味を持ちます。パスワードを長く複雑にしても、ハッシュを盗まれる経路は塞げません。マイクロソフトも、SMBのNTLMブロックが対抗する攻撃として、総当たり・クラッキングと並べてPass-the-Hashを挙げています。13

Kerberosにも長期鍵は存在しますが、日常の認証で飛び交うのは有効期限のあるチケットとセッション鍵です。3 盗まれたときの有効射程が違います。

8. NTLMv1・NTLMv2と「削除」

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

現在の扱いは次のように分かれています。

バージョン 状態 意味
LANMAN / NTLMv1 / NTLMv2 すべて非推奨(2024年6月)9 積極的な機能開発の対象外。ただし次期Windows Serverと次の年次リリースのWindowsでも動作する
NTLMv1 削除済み(Windows 11 24H2 / Windows Server 2025)9 これらのバージョンでは使えない

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

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

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

マイクロソフトが示している方向は3つです。

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

2つ目は、NTLMが必要になる場面そのものを減らすこと。フェーズ2(2026年後半)で予定されているIAKerbとローカルKDCが、これに当たります。6 6.3節で見た「ローカルアカウントだからKerberosが使えない」「ドメインコントローラーに届かないからKerberosが使えない」という2つの穴を、プロトコル側で埋めにいく試みです。ただし埋まる範囲には限りがあります。IAKerbが解くのはドメインコントローラーへの到達性であって、相手の対応可否ではありません。ローカルKDCも、対応するWindows同士でなければ効きません。他社製のNASや複合機が相手なら、フェーズ2を待っても状況は変わらないので、機器の更改・ドメイン参加・別プロトコルへの切り替え・例外管理のいずれかを自分で選ぶ必要があります。

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

この順番には意味があります。「使う理由をなくしてから、既定を変える」という順序なので、いま自社に残っているNTLM依存のうち、フェーズ2で解決を期待できるもの(対応するWindows同士のローカルアカウント認証、DC到達性)と、自分で直さなければならないもの(IPアドレス直打ち、SPN未登録、そして古いWindowsや他社製機器が相手のローカルアカウント認証)を仕分けておくと、無駄な工事をしなくて済みます。最後のものを「フェーズ2待ち」に分類してしまうと、既定無効化が来たときに障害として表面化します。仕分けの具体的な手順は実務編にまとめました。

10. まとめ

  • NTLMは「パスワードのハッシュを持っていること」を、チャレンジ/レスポンスで証明するプロトコルです。判定は、ドメインアカウントならドメインコントローラーが代行し、ローカルアカウントならサーバー自身が自分のSAMを引いて行います。110
  • Kerberosは「誰が、どのサービスに対して」を証明します。サービスチケットは宛先サービスの長期鍵で暗号化されるので、宛先を変えて使い回せません。3
  • 決定的な差は、相互認証の有無、認証のたびのDC問い合わせ、委任の可否です。4
  • NTLMに落ちるのは、ほぼ「Kerberosを始められなかった」ときです。IPアドレス直打ち、SPN未登録、Active Directoryの外、KDCに届かない、の4つが主因です。5611
  • 一方、時刻ずれのようにKerberosが選ばれたあとで失敗する問題は、NTLMへの落下ではなく認証エラーとして表れます。イベント8001を探しても見つかりません。7
  • リレー攻撃が成立するのは、NTLMのレスポンスが宛先を縛らないからです。Pass-the-Hashが成立するのは、認証に必要なものがハッシュそのものだからです。8113
  • NTLMv1はすでに削除済み(Windows 11 24H2 / Windows Server 2025)、NTLMv2を含む全バージョンが非推奨です。9
  • アプリが書くべきはNegotiateです。そのうえで、接続先の名前をFQDNに揃え、SPNを登録することが、Kerberosを成立させる実務の中身になります。15

関連記事

関連する相談領域

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

参考リンク

</content>

  1. Microsoft Learn, Microsoft NTLM. NTLMがWindows Challenge/Responseと呼ばれる認証プロトコルであり、認証・整合性・機密性をアプリケーションに提供するセキュリティパッケージであること、NTLM資格情報が対話型ログオン時に得られるドメイン名・ユーザー名・パスワードの一方向ハッシュで構成されること、暗号化されたチャレンジ/レスポンスによりパスワードを回線に流さずに認証し、認証を要求する側は安全に保管されたNTLM資格情報にアクセスできることを証明する計算を行うこと、非対話型認証がクライアント・サーバー・ドメインコントローラーの3者で行われること、その具体的な手順(クライアントがパスワードのハッシュを計算して平文パスワードを破棄する、ユーザー名を平文で送る、サーバーが8バイトの乱数=チャレンジを生成して送る、クライアントがチャレンジをハッシュで暗号化してレスポンスを返す、サーバーがユーザー名・チャレンジ・レスポンスをドメインコントローラーへ送る、ドメインコントローラーがSAMデータベースのハッシュで同じ計算をして突き合わせる)、そしてアプリケーションはNTLMセキュリティパッケージに直接アクセスすべきではなくNegotiateセキュリティパッケージを使うべきであり、NegotiateはKerberosとNTLMのどちらかを選択し、認証に関わるシステムのいずれかがKerberosを使えない場合を除いてKerberosを選択することについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  2. Microsoft Learn, [MS-NLMP]: NTLM v2 Authentication. NTLMの認証バージョンはプロトコルでネゴシエートされず、認証の前にクライアントとサーバーの双方で構成しておく必要があること、NTLM v2の応答鍵が NTOWFv2(Passwd, User, UserDom) = HMAC_MD5( MD4(UNICODE(Passwd)), UNICODE(大文字化したUser + UserDom) ) と定義されること、クライアントが8バイトのチャレンジを生成すること、temp が応答バージョン・8バイトのGMT時刻・クライアントチャレンジ・ServerName(AUTHENTICATE_MESSAGEのNTLMv2_CLIENT_CHALLENGEに含まれるAvPairs構造体)などの連結であること、NTProofStr = HMAC_MD5( ResponseKeyNT, サーバーのチャレンジ + temp ) として計算され NtChallengeResponse が NTProofStr と temp の連結になること、SessionBaseKey = HMAC_MD5(ResponseKeyNT, NTProofStr) であること、そして検証側について、認証するユーザーアカウントがActive Directoryにホストされている場合はチャレンジ/レスポンスの組をドメインコントローラーへ送って検証し、DCがNTOWF v2 / LMOWF v2 を使って期待値を計算して突き合わせること、DCが STATUS_NTLM_BLOCKED を返した場合サーバーは STATUS_NOT_SUPPORTED を返すこと、アカウントがサーバーにローカルにホストされている場合はサーバーがローカルに保管しているOWFから期待値を計算して突き合わせることについて。 ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, How the Kerberos Version 5 Authentication Protocol Works. AS交換において、クライアントがユーザープリンシパル名・アカウントのドメイン名と、ユーザーの長期鍵(パスワードから導出される鍵)で暗号化した事前認証データ(タイムスタンプを含む)をKDCへ送り、KDCが長期鍵で復号して検証したうえで、KDC自身の長期鍵(krbtgtアカウントの鍵)で暗号化したTGTと、ユーザーの長期鍵で暗号化したセッション鍵を返すこと、TGTがセッション鍵・認可データ(ユーザーSIDとグループSID)・有効期間とフラグを含むこと。TGS交換において、クライアントが対象サーバー名(SPN)・TGT・セッション鍵で暗号化した認証子(タイムスタンプとチェックサムを含む)をKDCへ送り、KDCがTGTを自身の長期鍵で復号してセッション鍵を取り出し、認証子のタイムスタンプがポリシーで定めた範囲内にあることを検証したうえで、対象サービスの長期鍵で暗号化したサービスチケットと、TGSセッション鍵で暗号化した新しいセッション鍵を返すこと。クライアント/サーバー交換(AP交換)において、クライアントがサービスチケットと認証子をサービスへ提示し、サービスが自分の長期鍵でチケットを復号してセッション鍵と認可データを取り出し、相互認証が要求されている場合はクライアントのタイムスタンプをセッション鍵で暗号化して返すことでサービス自身の身元を証明すること。そして長期鍵とセッション鍵の違い(長期鍵はパスワードやサービスアカウントから導出されセッションをまたいで持続し、セッション鍵は短命でチケットの期限とともに破棄される)について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  4. Microsoft Learn, Kerberos authentication overview in Windows Server. Windows ServerがKerberos version 5認証プロトコルと、公開鍵認証・認可データの転送・委任のための拡張を実装していること、KerberosクライアントがSSP(セキュリティサポートプロバイダー)として実装されSSPI経由でアクセスされること、KDCがドメインコントローラー上の他のセキュリティサービスと統合されておりActive Directory Domain Servicesのデータベースをセキュリティアカウントデータベースとして使うこと、Kerberosがサービスによる委任(フロントエンドサービスがクライアントの識別情報で他のコンピューター上のバックエンドサービスへ接続する仕組み)をサポートする一方、NTLMとKerberosが提供するのはサービスがローカルでクライアントを偽装するために必要な認可情報であること、Kerberos以前のNTLM認証ではアプリケーションサーバーがクライアントやサービスを認証するたびにドメインコントローラーへ接続する必要があったのに対しKerberosでは更新可能なセッションチケットがパススルー認証を置き換えPACの検証が必要な場合を除きサーバーがドメインコントローラーへ行く必要がないこと、そして相互認証について、Kerberosではネットワーク接続の両端のいずれもが相手が名乗るとおりの相手であることを検証できるのに対し、NTLMはクライアントによるサーバーの身元検証も、あるサーバーによる別のサーバーの身元検証も可能にせず、サーバーが本物であると仮定できるネットワーク環境向けに設計されたものでありKerberosはそのような仮定を置かないことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  5. Microsoft Learn, Viewing events for assessing NTLM usage. イベントログのNTLM監査情報がNTLM v1とv2のどちらに関するものかを判別でき、その方法がセキュリティログのログオンイベントで「認証パッケージ」を検索し「詳細な認証情報」の「パッケージ名 (NTLM のみ)」を見ることであること、NTLMを制限する監査およびブロックのポリシーがNTLMの2つのバージョンに対して同じ効果を持つこと、理屈のうえではKerberosに対応していてもNTLMを使ってしまうアプリケーションの4類型(さまざまなセキュリティ構成やプロバイダーを選択できるアプリ、SPNが正しく構成されていないアプリ、設定ミスやベンダーのドキュメントによりDNS名ではなくIPアドレスを使っているアプリ、レガシーなコードベースにNTLM専用部分を持つアプリ)、ドメインコントローラーのイベント8004からメンバーサーバーのイベント8003、クライアントのイベント8001へとたどる調査手順と各イベントの項目、イベント8001の「ターゲット サーバー」がNetBIOS形式でもFQDN形式でもなければKerberosは使われないこと、そしてSMB経由の通信ではPIDが常に4(SYSTEM)になるためProcess Monitorで呼び出し元プロセスを特定する必要があることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  6. Microsoft Japan Windows Technology Support Blog, NTLM の廃止に向けた対応について. NTLM廃止が3つのフェーズ(フェーズ1=利用状況の可視化と監査、フェーズ2=2026年後半に予定されるNTLM依存シナリオへの対応機能、フェーズ3=次期メジャーリリースでのネットワークNTLM認証の既定無効化)で進むこと、フェーズ2でIAKERB(プロキシ機能に対応したプロトコル)とローカルKDC(ローカル認証に対応する機能)の提供が予定されていること、アプリケーションではNegotiateを使うべきこと、そしてNTLMが使われる代表的な原因としてIPアドレス指定でのサーバーアクセス、Kerberosに必要なポートのファイアウォールによる制限、SPN未登録、信頼関係先への認証、ワークグループ環境での認証が挙げられることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  7. Microsoft Learn, Registry entries about Kerberos protocol and Key Distribution Center (KDC) configuration. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters 配下の各設定について。とくに SkewTime の既定値が5分であり、これがKerberos認証を受け付けるサーバーやKDCとクライアントコンピューターとの間で許容される最大の時刻差であること、この値がチケットの再利用可否の判定にも使われること、およびSPNキャッシュの有効期限(SpnCacheTimeout、既定15分)がクライアントとメンバーサーバーで「SPNが見つからなかった」という否定的キャッシュエントリの整理に使われ、ドメインコントローラーではSPNキャッシュが無効であることについて。 ↩ ↩2 ↩3 ↩4 ↩5

  8. Microsoft Learn, Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. 設定値が「すべて許可する」「すべて監査する」「すべて拒否する」「未定義」の4つであること、推奨手順としてまず「すべて監査する」を選び運用ログを確認してから例外リストを作るべきこと、監査およびブロックのイベントが「アプリケーションとサービス ログ\Microsoft\Windows\NTLM」に記録されること、そしてNTLMおよびNTLMv2認証がSMBリレー・中間者攻撃・総当たり攻撃を含むさまざまな悪意ある攻撃に対して脆弱であり、環境からNTLM認証を減らし排除することでWindowsがKerberos version 5のようなより安全なプロトコルやスマートカードのような別の認証機構を使うようになること、サーバーやドメインコントローラーがNTLM要求を処理する場合にのみこれらの攻撃が成立しうることについて。 ↩ ↩2 ↩3

  9. Microsoft Learn, Deprecated features in the Windows client. LANMAN、NTLMv1、NTLMv2を含むすべてのバージョンのNTLMが積極的な機能開発の対象外であり非推奨であること(告知は2024年6月)、NTLMの利用は次期Windows Serverと次の年次リリースのWindowsでも動作し続けること、NTLMの呼び出しはKerberosでの認証を試み必要なときだけNTLMにフォールバックするNegotiateの呼び出しに置き換えるべきこと、そして2024年11月の更新としてNTLMv1がWindows 11 バージョン24H2およびWindows Server 2025から削除されたことについて。あわせて、この一覧に載る機能は積極的に開発されておらず将来の更新で削除される可能性があるという、非推奨(deprecated)と削除(removed)の位置づけの違いについて。 ↩ ↩2 ↩3 ↩4 ↩5

  10. Microsoft Learn, NTLM overview in Windows Server. NTLM認証がMsv1_0.dllに含まれる認証プロトコル群であり、LAN Managerバージョン1・2とNTLMバージョン1・2を含むこと、チャレンジ/レスポンス機構によってサーバーやドメインコントローラーに対しアカウントのパスワードを知っていることを証明する方式であること、リソースサーバーが新しいアクセストークンを必要とするたびに、ドメインアカウントならそのアカウントのドメインのドメインコントローラー上の認証サービスへ問い合わせ、ローカルアカウントならローカルのアカウントデータベースを参照しなければならないこと、ワークグループのメンバーとして構成されたシステムのWindows認証とドメインコントローラー以外でのローカルログオン認証には依然としてNTLMが使われ使われなければならないこと、Active Directory環境ではKerberos version 5が推奨される認証方式であるがマイクロソフト製・非マイクロソフト製のアプリケーションがNTLMを使うことがあること、そしてNTLMの使用を減らすには配備済みアプリケーションの要件の把握と他のプロトコルを使うための構成の両方が必要であることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  11. Microsoft Learn, Configuring Kerberos for IP Address. Windows 10 バージョン1507およびWindows Server 2016以降、KerberosクライアントをSPN内のIPv4/IPv6ホスト名に対応させられること、既定ではホスト名がIPアドレスの場合Windowsはそのホストに対してKerberos認証を試みず、NTLMなど有効な他の認証プロトコルにフォールバックすること、アプリケーションがIPアドレスを直書きしているためにNTLMへフォールバックし、NTLMを無効化していく環境で互換性の問題を起こしうること、その影響を減らすためにSPNのホスト名としてIPアドレスを使える機能が導入され、クライアント側のレジストリ値 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters の TryIPSPN(REG_DWORD、既定では存在しない)を1にすることで有効になり、IPアドレスでKerberos保護されたリソースへアクセスする必要のある各クライアントに設定が必要であること、SPNが service/hostname[:port] の形式であること、そしてIPアドレスは一時的なものでありリースの期限切れと更新にともなう競合や認証失敗を招きうるため通常はホスト名の代わりに使わず、IPアドレスベースのSPN登録は手動作業でDNSベースのホスト名に切り替えることが不可能な場合にのみ使うべきであること、登録には Setspn -s <service>/<ip.address> <domain-user-account> を使い、SPNはActive Directory内で一度に1つのアカウントにしか登録できないためDHCP利用時はIPアドレスを静的に予約することが推奨されることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  12. Microsoft Learn, Overview of Server Message Block signing in Windows. SMB署名がすべてのSMBメッセージにセッション鍵とAESで生成した署名を付け、署名にはメッセージ全体のハッシュに加えて元の送信者と意図した受信者の識別情報が含まれること、転送中に改ざんされれば署名と一致しなくなり、これによってリレー攻撃およびなりすまし攻撃から保護されること、SMB 2/3の署名と暗号化の安全性がセッション鍵に依存し、署名が送信者と受信者の身元を確認してリレー攻撃を防ぐこと、セッション鍵がパスワードから導出されるため長く複雑な非辞書のパスワードが望ましいこと、セッション鍵が強い状態で始まるようNTLMv2ではなくKerberosの利用が推奨されること、IPアドレスやCNAMEレコードで共有に接続するとKerberosではなくNTLMが使われるため避けるべきであること、ドメインコントローラーが既定でSYSVOLやNETLOGONへの接続元にSMB署名を要求し、クライアント側のUNC Hardeningがさらにその2つの共有についてKerberosを要求すること、署名が事前認証整合性の一部としてダウングレード攻撃の防止にも使われること、ポリシーの場所とレジストリ値(RequireSecuritySignature)、およびWindows 11 バージョン24H2以降で署名・暗号化に対応しない相手を検出する監査(Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning など、SMBClient/Audit の 31998・31999、SMBServer/Audit の 3021・3022)が使えることについて。 ↩ ↩2 ↩3

  13. Microsoft Learn, Block NTLM connections on SMB in Windows Server 2025. SMBクライアントがリモートへの送信接続でNTLM認証をブロックできること、これにより悪意あるサーバーへNTLM要求を送らせる手口を防ぎ、総当たり・クラッキング・Pass-the-Hash攻撃に対抗できること、Kerberosがチケット方式によってサーバーの身元を検証できるためNTLMより安全であり、組織の認証プロトコルをKerberosへ切り替えるうえでNTLMブロックが必要であること、一方でNTLMを完全に無効化しなくてもこの保護層だけを有効にできること、前提条件がWindows Server 2025以降またはWindows 11 バージョン24H2以降のSMBクライアントとKerberosを使えるSMBサーバーであること、そしてこれがSMBクライアント側の機能であることについて。 ↩ ↩2 ↩3

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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

お問い合わせ
ブログ一覧に戻る