NTLMとは？ わかりやすく10分で解説

NTLM（NT LAN Manager）は、Windows環境で長く使われてきた認証プロトコル群です。チャレンジ・レスポンス方式により、平文パスワードをネットワーク上に送らずに本人確認を行います。一方で、リレー攻撃やパス・ザ・ハッシュなどの攻撃に悪用されやすく、現在のActive Directory環境ではKerberosの利用を優先する構成が基本です。

NTLMを完全に排除できない環境では、利用状況を監査し、互換性上必要な範囲だけに限定します。あわせて、通信保護、SMBでのNTLMブロック、特権アカウントの分離、ログ監視を組み合わせ、段階的にKerberosやNegotiateへ移行する設計が求められます。

NTLMとは

NTLMは、Windows認証で使われてきた認証プロトコル群です。ユーザーやコンピューターがネットワーク上のリソースへアクセスする際、サーバーまたはドメインコントローラーに対して、アカウントに対応する秘密情報を知っていることをチャレンジ・レスポンスで証明します。

現在のActive Directory環境では、Kerberosが推奨される認証方式です。ただし、ワークグループ構成、非ドメインコントローラーでのローカルログオン、古いアプリケーションや機器との互換性などを理由に、NTLMが使われる場面は残ります。

NTLMが使われてきた背景

NTLMは、初期のWindowsネットワークで広く使われ、その後も互換性維持のために残ってきました。NTLM認証プロトコルには、LAN Manager、NTLMv1、NTLMv2が含まれます。

現在は、NTLM全体を新規設計の前提にするべきではありません。NTLMv1は、Windows 11 version 24H2およびWindows Server 2025以降で削除されています。Windows Serverでは、LANMANとNTLMv2も非推奨であり、NTLMv2は動作を継続するものの、将来のWindows Serverで削除予定とされています。

そのため、既存環境では「どこでNTLMが使われているか」を把握し、KerberosやNegotiateへ移行できる箇所から段階的に置き換える方針が妥当です。

NTLM認証の流れと通信保護

NTLMは、パスワードそのものを送信せずに本人確認を行うため、チャレンジ・レスポンス方式を使います。ただし、認証の成立と、認証後の通信保護は別の論点です。

チャレンジ・レスポンス方式

チャレンジ・レスポンス方式は、NTLM認証の中心となる仕組みです。サーバーがクライアントへチャレンジと呼ばれるランダム値を送り、クライアントはアカウントの秘密情報をもとにレスポンスを生成して返します。サーバーまたはドメインコントローラーはレスポンスを検証し、正当なユーザーやコンピューターかどうかを判断します。

この方式では、平文パスワードはネットワーク上を流れません。しかし、攻撃者が端末やサーバーから認証に使える資格情報を取得した場合や、認証のやり取りを別のサーバーへ中継できる場合、侵害範囲の拡大に悪用される可能性があります。

セッションセキュリティ

NTLMには、認証後の通信を保護する仕組みとして、メッセージ署名による改ざん検知や、条件に応じた暗号化があります。ただし、NTLMを使えば通信が常に暗号化されるわけではありません。実際の保護範囲は、利用するプロトコル、設定、アプリケーションの実装に依存します。

機密性が必要な通信ではTLSやSMB暗号化を使い、改ざん検知やリレー対策ではSMB署名を有効にするなど、NTLMとは別の保護策を組み合わせます。Windows Server 2025およびWindows 11 version 24H2以降では、SMBクライアントでNTLM認証をブロックする構成も選択できます。

NTLMのバージョン

NTLMには、LAN Manager系の方式、NTLMv1、NTLMv2があります。実務では、NTLMv1への依存が残っていないか、NTLMv2であってもリレー攻撃などの構造的なリスクを過小評価していないかを確認します。

NTLMv1

NTLMv1は初期の方式で、現在の基準では暗号学的に弱い方式です。推測、解析、再利用を狙う攻撃に対して不利になりやすく、Windows 11 version 24H2とWindows Server 2025以降では削除されています。

古い機器やアプリケーションのためにNTLMv1相当の認証へ依存していないかを確認し、該当する依存関係を解消します。移行できない機器がある場合でも、例外範囲、到達経路、利用アカウント、ログ監視を明確にし、放置しない運用にします。

NTLMv2

NTLMv2は、NTLMv1の弱点を改善する目的で導入された方式です。レスポンス生成の仕組みは強化されていますが、NTLM自体が持つ中継可能性を完全に解消するものではありません。

NTLMv2を使っていることを、安全性の十分条件として扱うべきではありません。KerberosやNegotiateへの置き換え、NTLM利用状況の監査、SMBでのNTLMブロック、通信保護、特権資格情報の保護をあわせて検討します。

NTLMのセキュリティ課題

NTLMは、平文パスワードを送らない点では一定の利点があります。一方で、侵害後の横方向の展開、認証情報の悪用、中継によるなりすましに使われやすい課題があります。

パスワードハッシュの悪用

NTLMでは、パスワードそのものではなく、パスワードから導かれる情報を使って認証が行われます。攻撃者が端末やサーバーからハッシュなどの資格情報を取得できた場合、パスワードを知らなくても認証へ悪用できる場合があります。これが、パス・ザ・ハッシュの代表的なリスクです。

これは、単純にネットワーク盗聴で平文パスワードが流れるという話ではありません。端末侵害後に資格情報を抜き取り、別のサーバーへアクセスする横方向の展開で問題になりやすい攻撃です。

リレー攻撃

NTLMの代表的な脅威として、攻撃者が認証のやり取りを中継し、別のサーバーに対して本人になりすましてアクセスを成立させるリレー攻撃があります。過去のレスポンスをそのまま使う単純なリプレイ攻撃ではなく、認証処理をリアルタイムで中継する点が特徴です。

リレー攻撃は、中間者攻撃の一種として理解できます。成立すると、機密情報の閲覧、共有フォルダーへのアクセス、権限次第では設定変更や追加の侵害拡大につながります。

サーバー認証の弱さ

NTLMは、Kerberosと比べてサーバー側の正当性確認が弱くなりやすい方式です。攻撃者がクライアントを不正なサーバーへ誘導できると、NTLM認証のやり取りを悪用される可能性があります。

このリスクを下げるには、Kerberosを優先できる構成にし、SMBでのNTLMブロック、SMB署名、TLS、不要な名前解決プロトコルの削減、到達経路の制限を組み合わせます。

NTLMを残す場合の対策

NTLMをすぐに排除できない環境では、利用状況を把握し、段階的に制限しながら、残る通信を保護します。互換性を理由に放置するのではなく、どのサーバー、アプリケーション、アカウントでNTLMが使われているかを記録し、移行対象を切り分けます。

優先して確認する項目

実務では、次の順に確認すると判断しやすくなります。

• Kerberosを優先できる構成かを確認し、NTLMへのフォールバックを必要範囲に限定する
• NTLMv1または同等に弱い認証方式への依存がないかを確認する
• NTLM利用状況を監査し、クライアント、サーバー、アプリケーション、アカウントを特定する
• 通信経路はTLSやSMB暗号化などで保護し、NTLMだけで通信保護を完結させない
• SMBでNTLMが不要な範囲では、SMBクライアントのNTLMブロックを検討する
• 管理者権限を使う端末と通常業務端末を分け、特権資格情報の露出を抑える
• 最小特権の原則に沿って、NTLMでアクセスできる範囲を絞る

代表的なリスク別の対策

パス・ザ・ハッシュやリレー攻撃のリスクを下げるには、認証方式だけでなく、端末防御、特権運用、プロトコル設定を組み合わせます。

• NTLMの利用状況を監査し、不要なNTLM認証を段階的に制限する
• SMB署名やSMB暗号化を使い、改ざんや中継の余地を減らす
• Windows Server 2025やWindows 11 version 24H2以降では、SMBクライアントのNTLMブロックを検討する
• 不要なサービス、共有、到達経路を減らし、横方向の移動経路を限定する
• 特権アカウントの利用端末を制限し、通常端末への資格情報残存を避ける
• ログ監視により、想定外のNTLM利用や認証失敗の増加を検知する

NTLM対策の中心は、NTLMを安全な認証方式として使い続けることではありません。KerberosやNegotiateを優先し、NTLMへの依存を減らしながら、残る箇所の通信保護と特権管理を強化することです。

監査から制限へ進める手順

NTLMの無効化や制限は、業務影響を確認せずに実施すると、古いアプリケーションや機器の認証に影響する場合があります。まず監査を有効化し、NTLMを使っている通信を把握します。そのうえで、依存しているアプリケーションやサーバーを分類し、Kerberosへ移行できるもの、設定変更で解消できるもの、短期的に例外として残すものに分けます。

制限をかける前には、非本番環境でNTLMを無効化した構成を試験します。認証失敗、アプリケーションエラー、ファイル共有への接続失敗などを確認し、業務影響と代替策を整理してから本番適用に進みます。

NTLMとKerberos・OAuth/OIDCの違い

認証方式は、社内ネットワーク、Windowsドメイン、Webアプリケーション、クラウドサービスなど、利用場面によって前提が異なります。NTLM、Kerberos、OAuth、OpenID Connect（OIDC）を同じ用途の代替手段として扱うと、設計判断を誤ります。

Kerberos認証プロトコルとの比較

Kerberosは、Active Directory環境で推奨されるチケットベースの認証プロトコルです。Key Distribution Center（KDC）を使い、サービスごとのチケットで認証を行います。NTLMと比べて相互認証や委任を扱いやすく、Windowsドメインの標準的な認証方式として位置付けられています。

NTLMは、Kerberosを使えない構成や、アプリケーション側がNTLMを前提としている場面で残ることがあります。移行を進める際は、単にNTLMを無効化するのではなく、どの通信がNTLMへフォールバックしているかを監査し、Kerberosで成立するように名前解決、SPN、アプリケーション設定を確認します。

OAuth/OIDCとの違い

OAuthやOpenID Connect（OIDC）は、主にWebアプリケーションやクラウドサービスで使われる認可・認証の仕組みです。OAuthはAPIへのアクセス許可を扱う場面で使われ、OIDCはOAuth 2.0の上にID情報を扱う仕組みを加えたものです。シングルサインオンの構成でも利用されます。

NTLMやKerberosは、主にWindows環境のリソースアクセスで使われてきた認証方式です。OAuth/OIDCは、Webやクラウドのアプリケーション連携を前提とするため、役割が異なります。社内のWindows認証を見直す話なのか、クラウドサービスの認証連携を設計する話なのかを分けて検討します。

まとめ

NTLMは、Windows環境で長く使われてきた認証プロトコル群です。チャレンジ・レスポンス方式により、平文パスワードを送らずに本人確認を行います。ただし、NTLMv1はWindows 11 version 24H2およびWindows Server 2025以降で削除され、NTLMv2も非推奨で将来のWindows Serverから削除予定とされています。Active Directory環境ではKerberosを優先し、NTLMは互換性上必要な範囲に限定します。

NTLMを残す場合は、NTLMv1への依存確認、NTLM利用状況の監査、SMB署名やSMB暗号化、SMBでのNTLMブロック、特権アカウントの分離、ログ監視を組み合わせます。NTLMのリスクは、認証方式だけで完結する問題ではありません。端末侵害後の資格情報悪用やリレー攻撃まで含めて、段階的に依存を減らす設計へ移行する必要があります。

FAQ