【Windows】Windows ServerのNTLM認証ブロックエラーを解決する方法

今回は、Windows Serverのリモートデスクトップ接続やネットワークアクセスで発生するNTLM認証ブロックエラーの原因判定と解決方法について、実践的なアプローチを解説します。

特にWindows Server 2022以降では、セキュリティ強化により古いNTLM認証方式が段階的に制限されており、従来の設定では接続できなくなるケースが増えています。

本記事では、NTLM認証エラーの具体的なシナリオから、グループポリシーによる設定調整、さらにはセキュリティを損なわない対応方法までを紹介します。

Windows ServerにおけるNTLM認証の役割と制限の背景
NTLM認証ブロックエラーの典型的なシナリオ
エラーメッセージから原因を特定する診断方法
イベントビューアーでNTLM認証エラーを追跡
グループポリシーによる認証設定の調整
NTLMv2への移行と互換性維持のバランス
実務での具体的な設定パターン
まとめ

Windows ServerにおけるNTLM認証の役割と制限の背景

NTLMはWindows認証の基本的なプロトコルであり、古くから存在します。しかし、2004年にはKerberosが導入され、より安全な認証方式として推奨されてきました。それでも、レガシーアプリケーション、特定の設定下でのドメインコントローラー通信、およびワークグループ環境でのホストアクセスなど、NTLMはまだ広く使用されています。

Windows Server 2022とWindows 11では、マイクロソフトがセキュリティを強化する一環として、NTLMv1（古い署名なし）と特定の弱い暗号化方式を段階的に廃止する方針を明確にしました。具体的には：

NTLMv1の廃止：LAN Manager認証の廃止
署名なしNTLMの制限：メッセージ完全性がない接続の制限
128ビット暗号化の強制：弱い暗号化方式の廃止

運用経験上、レガシープリンターやネットワークストレージなど、アップデート不可能なデバイスとのNTLM通信がブロックされることが多く、運用の課題となってきました。単純にNTLMを許可すればよいのではなく、どの通信をどこまで許可するかの判断が重要です。

NTLM認証ブロックエラーの典型的なシナリオ

NTLM認証ブロックエラーが発生するシナリオは多様ですが、パターン化できるものが多いです。

シナリオ1：リモートデスクトップ接続エラー

古いクライアント端末からWindows Server 2022へRDP接続を試みた場合、以下のエラーが発生することがあります。

エラーメッセージ：「CredSSP encryption oracle remediation」または「セキュリティレイヤーで認証エラーが発生しました」

これはクライアント側とサーバー側のNTLM設定が不一致している場合に表示されます。具体的には、クライアントが古いNTLM署名を使用しようとしているが、サーバーがこれを受け付けていない状況です。

シナリオ2：ネットワークドライブのマッピングエラー

SMB通信を通じてネットワークドライブをマッピングしようとした場合、アクセス拒否エラーが発生します。

エラーメッセージ：「このコンピューターとの接続はセキュアではない可能性があるため、接続できません」

シナリオ3：アプリケーション認証エラー

カスタムアプリケーションがWindowsの認証APIを使用する場合、NTLM認証方式によってはエラーが発生します。

エラーメッセージ：「Authentication failed」または「NTLM negotiation failed」

エラーメッセージから原因を特定する診断方法

NTLM認証エラーを確実に解決するには、エラーメッセージを正確に解釈する必要があります。

ステップ1：エラーメッセージのキャプチャと記録

接続エラーが発生したら、まずスクリーンショットとエラーメッセージをできるだけ正確に記録します。

powershell
# PowerShellでエラー情報をログに記録
$ErrorActionPreference = "Continue"
Get-EventLog -LogName Security -Newest 20 | Format-Table -AutoSize

ステップ2：NTLMセッションの状態確認

サーバー側で現在のNTLM設定を確認します。

powershell
# NTLMv2の強制設定を確認
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" `
  -Name "LmCompatibilityLevel" | Select-Object LmCompatibilityLevel

# レジストリキーの意味：
# 0 = LM and NTLM
# 1 = NTLM v2 responses only
# 2 = LM response and NTLMv2 response only
# 3 = NTLMv2 response only (デフォルト設定）
# 4 = NTLMv2のみ、LMなし
# 5 = NTLMv2のみ、LMとNTLMv1なし（推奨）

ステップ3：SMB署名設定の確認

powershell
# SMB署名の設定確認
Get-SmbServerConfiguration | Select-Object EncryptData, RejectUnencryptedAccess

# 詳細なSMB設定
Get-SmbServerConfiguration | Select-Object *Signing*, *Encrypt*

イベントビューアーでNTLM認証エラーを追跡

NTLM認証エラーの詳細は、Windows イベントビューアーのセキュリティログに記録されます。

NTLM関連イベントログの確認

powershell
# イベントビューアーを起動
eventvwr.msc

# 又は PowerShellで確認
Get-EventLog -LogName Security -InstanceId 4624, 4625, 4776 -Newest 50 | `
  Format-Table -Property TimeGenerated, EventID, Message -AutoSize

重要なイベントID：

4624：アカウントのログイン成功
4625：アカウントのログイン失敗
4776：ドメインコントローラーへの資格情報の検証（Kerberos、NTLM）

イベント4625を確認することで、認証失敗の具体的な理由が判明します。

powershell
# ログイン失敗イベントの詳細確認
Get-EventLog -LogName Security -InstanceId 4625 -Newest 1 | Format-List *

具体的な失敗理由のコード

コード	意味
0xC000006D	ユーザー名またはパスワードが不正
0xC0000069	ログオンマシンの時刻がドメインコントローラーと不一致
0xC000006F	ユーザーが有効な時間帯でない
0xC0000070	ワークステーション制限に違反

グループポリシーによる認証設定の調整

NTLM認証の制限を段階的に調整することで、セキュリティと互換性のバランスを取ることができます。

ステップ1：グループポリシーエディターを開く

powershell
# ローカルグループポリシーエディター起動
gpedit.msc

ステップ2：NTLM関連ポリシーの場所

グループポリシーエディター内で以下のパスを辿ります：


コンピューターの構成
  > 管理用テンプレート
    > Windows コンポーネント
      > ネットワーク セキュリティ

主要なNTLMポリシー設定

1. 「LAN Manager 認証レベル」

パス：ネットワークセキュリティ > LAN Manager 認証レベル
推奨値：「NTLMv2 応答のみを送信する」（レベル5）
互換性維持が必要な場合：「LM と NTLMv2 応答のみを送信する」（レベル2）

powershell
# PowerShellでレジストリ設定を直接変更
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" `
  -Name "LmCompatibilityLevel" -Value 5 -Force

2. 「すべてのドメインパスワード同期（NTLM）を拒否」

パス：ネットワークセキュリティ > すべてのドメインパスワード同期（NTLM）を拒否
有効：レガシーアプリケーション対応時のみ

3. 「LAN Manager ハッシュの保存（次の変更時）を許可しない」

パス：ネットワークセキュリティ > LAN Manager ハッシュの保存（次の変更時）を許可しない
有効：推奨（セキュリティ強化）

ステップ3：設定適用後の確認

powershell
# グループポリシーの強制更新
gpupdate /force

# 設定が適用されたか確認
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel"

NTLMv2への移行と互換性維持のバランス

実務では、セキュリティと互換性のバランスを取ることが重要です。段階的な移行戦略を紹介します。

フェーズ1：現状把握（1-2週間）

まず、どのシステムがNTLMv1またはLM認証を使用しているかを特定します。

powershell
# Windowsファイアウォール設定でNTLM通信をログ記録
netsh advfirewall set allprofiles logging inbound enable
netsh advfirewall set allprofiles logging outbound enable

# ログの確認
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | `
  Where-Object { $_ -match "NTLM" } | Select-Object -First 20

フェーズ2：互換性確認（1週間）

各システムのNTLM対応状況を確認します。

powershell
# リモート接続テスト
# PowerShellリモートで認証方式を確認
$cred = Get-Credential
Invoke-Command -ComputerName TargetServer -Credential $cred `
  -Authentication NegotiateWithImplicitCredential -ScriptBlock {
    Write-Host "接続成功"
}

フェーズ3：段階的な制限強化（2-4週間）

LmCompatibilityLevelを段階的に上げます。

段階1：レベル3（NTLMv2のみ、LMなし）- 1週間監視
  ↓
段階2：レベル4（NTLMv2のみ、LMとNTLMv1なし）- 1週間監視
  ↓
段階3：レベル5（NTLMv2のみ、署名強制）- 最終設定

フェーズ4：例外設定の検討

どうしても古いNTLMが必要な場合、ホストベースの例外を設定します。

powershell
# 特定のホストに対してのみNTLM署名を無視する
# グループポリシーで以下を設定：
# ネットワーク セキュリティ > LAN Manager 認証レベルの例外ホスト

# または、個別のコンピューターで例外設定
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" `
  -Name "LmCompatibilityLevel" -Value 3 -Force

実務での具体的な設定パターン

実務でよく遭遇するシナリオごとの対応方法です。

パターン1：レガシープリンターのNTLM接続

古いプリンターがレベル5（NTLMv2署名強制）に対応していない場合：

powershell
# レベル2に設定（LM と NTLMv2のみ）
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" `
  -Name "LmCompatibilityLevel" -Value 2 -Force

# プリンターのIP設定でNTLMv2を明示的に指定
# （プリンターの管理画面で「NTLM認証」を「NTLMv2」に変更）

パターン2：レガシーアプリケーション互換性

古い業務アプリケーションがNTLMv1署名に対応している場合：

powershell
# レベル3に設定（NTLMv2のみ、LMなし）
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" `
  -Name "LmCompatibilityLevel" -Value 3 -Force

# SMB署名は有効なまま
# 但し、データ暗号化の要件を緩和
Set-SmbServerConfiguration -EncryptData $false -Force

パターン3：Kerberos移行段階での混在環境

NTLMからKerberosへの移行期間：

powershell
# NTLMv2をサポートしつつ、Kerberosを優先
# ドメインコントローラーで以下を設定：

# Kerberosアルゴリズムの強化
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\kdc" `
  -Name "KdcSupportedEncryptionTypes" -Value 2147483645 -Force

# NTLMは使用許可だが、Kerberosが優先
# （GPOで「Kerberos で信頼できないドメイン」の設定）

パターン4：セキュリティ強化環境

セキュリティを最優先する場合：

powershell
# レベル5に設定（推奨）
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" `
  -Name "LmCompatibilityLevel" -Value 5 -Force

# SMB署名を有効化
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# SMBデータ暗号化を有効化
Set-SmbServerConfiguration -EncryptData $true -Force

# 確認
Get-SmbServerConfiguration | Select-Object *Signing*, *Encrypt*

まとめ

Windows ServerのNTLM認証ブロックエラーは、セキュリティとレガシーシステム対応のバランスを求められる実務課題です。本記事で紹介したポイントは以下の通りです：

1. NTLM制限の背景理解：マイクロソフトのセキュリティ方針が段階的な廃止を推進していることを理解することが対応の第一歩です。

2. 段階的な診断アプローチ：イベントログ確認→レジストリ設定確認→グループポリシー調整という順序で進めることで、問題を体系的に解決できます。

3. イベントログの活用：4625（ログイン失敗）イベントを確認することで、具体的な認証失敗の原因を特定できます。

4. 段階的な制限強化：LmCompatibilityLevelを段階的に上げることで、セキュリティと互換性のバランスを取ることができます。

5. 運用フェーズの設定：フェーズ1〜4の段階を踏むことで、トラブルを最小限に抑えながら移行できます。

実務では、全社一律の設定ではなく、システムごとの要件に応じた柔軟な対応が求められます。一時的な制限で対応しつつ、平行してリプレースを検討、進める事をお勧めします。