本記事はマイクロソフト社員によって公開されております。
こんにちは。Windows Commercial Support Directory Services チームです。
今回は、先般非推奨となった NTLM の廃止に向けた対応について、ご参考としていただける情報についてご案内いたします。
今後の対応について、現時点で詳細が未確定な部分もございますので、必要に応じてブログの内容はアップデートする予定です。
1. NTLM 廃止の背景
Windows 認証のセキュリティを向上させるため、弊社は NTLM 認証を使う必要があるシナリオに対処して、最終的に NTLM を無効化し、すべての認証をよりセキュアな Kerberos で行えるようにする目標がございます。
NTLM はチャレンジ/レスポンス方式を採用した認証プロトコルとなりますが、古くから利用されている背景もあり、
近年では多くの脆弱性や問題が確認され、また、相互認証のようなセキュリティ的に強度の高い実装はされておらず最新の暗号アルゴリズムにも対応しておりません。
このように、NTLM では最新のセキュリティ要件に対応することができなくなってしまっていることから、
生体認証やパスワード レスといったセキュリティ強度の高い認証方式を採用でき、より拡張性がある Kerberos の利用を標準化させることで、全ての Windows ユーザーの認証におけるセキュリティ レベルを向上させたいという背景がございます。
現在、弊社では Kerberos を使用できないシナリオや、NTLM にフォール バックするシナリオに対処するため、
Kerberos を使用した初期認証とパススルー認証 (IAKERB) および Kerberos 用のローカル鍵配布センター (Local KDC) といった新機能の導入も計画しております。
最終的な目標は、NTLM を使用するシナリオを全て排除することとなりますが、後述の NTLM 廃止に向けた対応についてご確認いただき、お客様環境においても移行の準備をご検討いただけますと幸いです。
2. NTLM 廃止までのスケジュール
弊社は NTLM が機能開発の対象ではなくなり、非推奨の機能であることを 2024 年 6 月に公開情報に明記しました。
詳細につきましては、以下の公開情報をご参照ください。
将来的な Kerberos への完全移行を目標に、段階的な NTLM の廃止も計画されておりますが、2024 年 8 月時点では方向性が示されるまでとなり詳細なロードマップは公開されておりません。
なお、上記公開情報のとおり、非推奨ではあるものの Windows / Windows Server の次期バージョンでは引き続き機能いたします。
また、今後既定で NTLM が無効となった後も、システムやアプリケーションの互換性を確保するための一時的な措置として、管理者により有効に戻すことのできる機能の準備も検討されています。
今後公開される情報が更新されましたら、本ブログにおいてもご案内させていただきます。
3. NTLM 廃止後の代替機能
NTLM の廃止に伴い、より安全で信頼性の高い認証プロトコルである Kerberos への完全移行が求められます。
弊社では、この移行をスムーズに進めるために、IAKERB および Local KDC を活用した対応策を導入予定です。
機能を利用するための要件や設定方法については現時点で公開されておりませんが、各機能の概要について以下にご案内いたします。
また、IP アドレスを指定した接続において Kerberos を利用する方法が既に用意されておりますので、本機能についても後述いたします。
IAKERB
アプリケーション サーバーへのアクセスに Kerberos が用いられる場合、クライアントは事前に KDC へ接続してチケットを入手する必要があります。
複雑なネットワーク構成の環境においては、このクライアントと KDC 間のネットワーク接続が課題となる場合があり、NTLM を利用せざるを得ない要因ともなっています。
IAKERB は Kerberos の拡張プロトコルであり、Kerberos チケットの取得において事前に KDC へ接続しなければならない状況に対応するもので、多様なネットワーク トポロジにおける Kerberos の利用をサポートします。
IAKERB では、クライアントが KDC にアクセスできない場合、アプリケーション サーバーがプロキシとして機能し、KDC と通信を行います。具体的には、クライアントがアプリケーション サーバーに Kerberos 認証要求を送信し、アプリケーション サーバーがその要求を KDC に転送します。
KDC は応答をアプリケーション サーバーに返し、それがクライアントに伝えられます。
Local KDC
ローカル アカウントやオフラインのコンピューターにおける認証においては、現状は NTLM を利用せざるを得ないシナリオが存在します。Local KDC は、このようなローカル アカウントやオフライン コンピューターの Kerberos 認証をサポートするための機能です。
各 Windows コンピューターに KDC の機能を持たせることで、ローカル ユーザー アカウントに対する Kerberos 認証を実現します。
これにより、ドメインに参加していないコンピューターや、オフラインのコンピューターに対して Kerberos 認証を利用させることが可能となります。
IP アドレス指定の接続で Kerberos を利用させる
クライアントがリソースにアクセスする際、ホスト名ではなく IP アドレスを指定した場合、Kerberos は用いられずに NTLM で認証される動作となります。
ユーザーによる操作であればホスト名を指定する運用に変えることもできますが、アプリケーションでハードコードされている状態であれば、NTLM が利用できなくなることで影響が及ぶことが考えられます。
このような状況に対応するために、IP アドレスが指定された場合も Kerberos を用いるように変更できる機能が用意されておりますので、本機能を利用するための設定方法を以下にご案内いたします。
なお、本機能を利用できる OS バージョンは Windows 10 バージョン 1507、Windows Server 2016 以降となります。
[1] クライアント側でのレジストリ設定
リソースへのアクセス元となるクライアント側で、以下のレジストリを設定します。
キー：HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
名前：TryIPSPN
種類：REG_DWORD
値：1上記レジストリは、以下のコマンドで設定が可能です。
1 | reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v TryIPSPN /t REG_DWORD /d 1 /f |
[2] SPN の登録
SPN (Service Principal Name) は、Kerberos 認証においてサービスを識別するために利用される識別子です。
ドメインのアカウントの属性値として、この SPN を登録する必要があります。
以下のコマンドで設定が可能です。<サービス> の箇所には対象のコンピューターでホストするサービスに対応する値を指定する必要があります。
1 | Setspn -s <サービス>/<IP アドレス> <ドメイン アカウント> |
Negotiate SSP
アプリケーションの実装において NTLM が利用されている場合、Kerberos が利用されるように変更を行う必要があります。
AcquireCredentialsHandle 関数を呼び出す際に NTLM の利用がハードコーディングされている場合、これを Negotiate に置換いただくことで対応が可能です。
Negotiate の利用により、Kerberos が利用可能な場合には自動的に使用し、そうでない場合には NTLM にフォールバックするため、
移行の過渡期においてもセキュリティと互換性の両方を確保できます。
4. NTLM 廃止に向けた対応について
NTLM 廃止に向けて、認証に NTLM が利用されているかどうかを判断する場合、以下のような NTLM の監査に関するグループ ポリシーを利用することが有効となります。
対象のグループ ポリシーのパス
[コンピューターの構成] - [ポリシー] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー]
グループ ポリシー名 および 設定
(1) [ネットワーク セキュリティ: NTLM を制限する: このドメイン内の NTLM 認証を監査する] の値を「すべて有効にする」
(2) [ネットワーク セキュリティ: NTLM を制限する: 着信 NTLM トラフィックを監査する] の値を「すべてのアカウントに対して監査を有効にする」
(3) [ネットワーク セキュリティ: NTLM を制限する: リモート サーバーに対する送信 NTLM トラフィック] の値を「すべて監査する」
上記グループ ポリシーを設定した状態で NTLM 認証が行われると、ポリシーに従い、イベント ログに後述する監査イベントが記録されます。
この監査イベントを確認することで、NTLM 認証を行っている状況を判断していただくことが可能です。
対象のイベントはイベント ビューアーの以下イベント ログから確認が可能です。
[Applications and Services Log] - [Microsoft] - [Windows] - [NTLM] - [Operational]
(1) [ネットワーク セキュリティ: NTLM を制限する: このドメイン内の NTLM 認証を監査する] の値を「すべて有効にする」
こちらのポリシーをドメイン コントローラーに設定すると、ドメイン内のメンバー コンピューターからの NTLM 認証要求について以下の監査イベントを出力します。
通常、アクセス元、アクセス先コンピューター名と、認証に利用されたユーザー名が記録されます。
ログの名前: Microsoft-Windows-NTLM/Operational
ソース: Microsoft-Windows-Security-Netlogon
イベント ID: 8004
タスクのカテゴリ: NTLM の監査
レベル: 情報
キーワード:
ユーザー: SYSTEM
コンピューター: <ドメインコントローラー>
説明:
ブロックされているドメイン コントローラーの監査: このドメイン コントローラーへの NTLM 認証を監査します。
セキュリティで保護されたチャネル名: <アクセス先コンピューター名>
ユーザー名: <NTLM 認証を行ったユーザー名>
ドメイン名: <Domain Name>
ワークステーション名: <アクセス元コンピューター名>
セキュリティで保護されたチャネルの種類: 2(2) [ネットワーク セキュリティ: NTLM を制限する: 着信 NTLM トラフィックを監査する] の値を「すべてのアカウントに対して監査を有効にする」
こちらの設定を行うと、設定が適用されたコンピューターに対して NTLM 認証を試行した場合に以下の監査イベントを出力します。
ログの名前: Microsoft-Windows-NTLM/Operational
ソース: Microsoft-Windows-NTLM
イベント ID: 8002
タスクのカテゴリ: Auditing NTLM
レベル: 情報
キーワード:
ユーザー: SYSTEM
コンピューター: <コンピューター名>
説明:
NTLM server blocked audit: Audit Incoming NTLM Traffic that would be blocked
Calling process PID:
Calling process LUID:
Calling process user identity:
Calling process domain identity:
Mechanism OID: 以下の ID 8003 のイベントでは、Workstation の値から、NTLM 認証要求元のコンピューター名を確認することが可能です。
ログの名前: Microsoft-Windows-NTLM/Operational
ソース: Microsoft-Windows-NTLM
イベント ID: 8003
タスクのカテゴリ: Auditing NTLM
レベル: 情報
キーワード:
ユーザー: SYSTEM
コンピューター: <コンピューター名>
説明:
NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
User:
Domain:
Workstation:
PID:
Process:
Logon type:
InProc:
Mechanism: (3) [ネットワーク セキュリティ: NTLM を制限する: リモート サーバーに対する送信 NTLM トラフィック] の値を「すべて監査する」
こちらの設定は、設定が適用されたコンピューターから、任意のコンピューターに対して NTLM 認証を試行した場合に以下の監査イベントを出力します。
このイベントには、通常、NTLM 認証を試みたユーザー名やアクセス先が出力されます。
ログの名前: Microsoft-Windows-NTLM/Operational
ソース: Microsoft-Windows-NTLM
イベント ID: 8001
タスクのカテゴリ: Auditing NTLM
レベル: 情報
キーワード:
ユーザー: SYSTEM
コンピューター: <コンピューター名>
説明:
NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server:
Supplied user:
Supplied domain:
PID of client process:
Name of client process:
LUID of client process:
User identity of client process:
Domain name of user identity of client process:
Mechanism OID: 5. NTLM が利用されるシナリオ例
NTLM は主に次のようなシナリオで使用されます。
(1) ホスト名では無く、IP アドレスを利用してサーバーへアクセスして認証を行っている
(2) ファイアウォールが Keberos に必要なポートを制限している場合
(3) アクセス先の SPN がドメインコントローラーへ登録されていない
(4) 信頼関係 (外部信頼) 先に関する認証
(5) オンプレミス ドメインに所属していないワークグループ環境内での認証
具体的には、ファイル サーバーへアクセスする際や、リモート デスクトップで他のコンピューターへアクセスする際に、アクセス先を IP アドレスで入力している場合は NTLM での認証となります。
またそれぞれ Kerberos が利用できない場合などは、NTLM にフォールバックされます。
その他、OS 関連では以下に機能毎の認証に関する公開情報がございますため、必要に応じてご参照いただけますと幸いでございます。
SMB
WinHTTP
Failover Clustering
WinRM
印刷
6. 参考リンク
本対応に関して Global のエンジニアからも情報が公開されておりますので、ご参考としていただけますと幸いでございます。
更新履歴
2024/08/22 : 本ブログの公開