KB5127648とNTLMv1：PEAP-MSCHAPv2 Wi-Fi・LAN・VPNが接続できなくなった理由と恒久的な解決策

端的な回答

2026年10月のWindows 11 24H2・25H2・26H2向け累積アップデートであるKB5127648の適用後、WindowsはデフォルトでNTLMv1派生資格情報をシングルサインオンに使用できないようにブロックします。Windows Server 2025も2026年10月のアップデートで同様の変更が適用されます。Credential Guardが無効なデバイスでは、Windowsの資格情報を使用するPEAP-MSCHAPv2またはEAP-MSCHAPv2によるWi-Fi・有線Ethernet（802.1X）・VPN接続が自動的に確立されなくなります。

レジストリ値BlockNtlmv1SSOを0に設定すれば、当面は従来の動作に戻すことができます。Microsoftが推奨する恒久的な解決策は、EAP-TLSによる証明書ベース認証です。

TL;DR

• 変更内容： Microsoftが設定していないすべてのデバイスに対して、WindowsがBlockNtlmv1SSOを強制適用するようになりました。Microsoftはこの変更をメッセージセンター投稿MC1508562で告知し、KB5066470に技術的な詳細を記載しています。
• 影響を受ける環境： Credential GuardなしでMS-CHAPv2ベースのシングルサインオンを使用しているデバイス（主にドメイン参加済みのWindowsクライアント）。
• 暫定的な回避策： BlockNtlmv1SSOを0に設定する。ただしMicrosoft自身が長期的な使用を推奨していない設定です。
• 恒久的な解決策： EAP-TLSへ移行する。SCEPmanを使えば、オンプレミスPKIを構築せずに移行できます。

KB5127648で何が変わったか

MicrosoftはNTLMを段階的に廃止してきました。今回の変更は、多くのネットワークが現在も日常的に依存しているプロトコル、MS-CHAPv2に影響します。MS-CHAPv2はNTLMv1派生の資格情報に基づいており、WindowsはこれらをシングルサインオンのSSOに使用できなくなりました。

Microsoftはこの強制適用をメッセージセンター投稿MC1508562「要対応：NTLMv1ハードニング変更がCredential Guard非搭載デバイスのネットワーク接続に影響する可能性があります」で告知しています。技術的な背景はKB5066470に記載されています。

Microsoftはこれをアップデートの既知の問題ではなく、計画的なセキュリティ強化変更と位置付けています。つまり、この変更は今後も維持されます。

影響を受けているか確認する

以下のすべてに該当する場合、影響を受けている可能性が高いです。

• 2026年10月のアップデート（Windows 11ではKB5127648）が適用されたWindows 11 24H2以降、またはWindows Server 2025を使用している。
• それらのデバイスでCredential Guardが無効になっている。
• Wi-Fi・有線Ethernet（802.1X）・VPNでシングルサインオンを使用するPEAP-MSCHAPv2またはEAP-MSCHAPv2を利用している（「Windowsのログオン名とパスワードを自動的に使用する」が有効なドメイン参加デバイスが典型的）。
• BlockNtlmv1SSOレジストリ値が一度も設定されていない。

デバイスがすでに証明書ベース認証（EAP-TLS）を使用している場合、この変更の影響は受けません。Credential Guardが有効なデバイスはすでにこの動作をブロックしていたため、パスワードベースのSSOはすでに機能していませんでした。この変更はWindows側の変更であるため、macOS・iOS・Android・Linuxのクライアントは影響を受けません。

症状

• デバイスが自動的に接続されなくなり、ユーザーに資格情報の入力を求めるプロンプトが表示される。
• パスワードを手動で入力すれば接続できるが、Windowsが次回のために保存できない。
• ユーザー操作なしに接続していたワークフロー（共有デバイス・キオスクデバイス・自動接続VPNプロファイルなど）が動作しなくなる。
• クライアントはMicrosoft-Windows-NTLM/OperationalにイベントID 4025（「ブロック済み」）を記録する。監査モードではイベントID 4024が記録される。

この障害はクライアント側で発生するため、RADIUSやNPSのログにはほとんど何も表示されないことがあります。まずエンドポイント側でトラブルシューティングを行ってください。

デバイスの確認方法

# BlockNtlmv1SSOが設定されているか確認する（値なし = Windowsが新しい強制デフォルトを使用）
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# NTLMv1派生資格情報の監査（4024）またはブロック（4025）が記録されているか確認する
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

暫定的な回避策：BlockNtlmv1SSOを0に設定する

影響を受けているデバイスを監査モードに戻すことができます。これによりWindowsはNTLMv1派生資格情報の使用を再び許可し、各使用をイベントID 4024として記録します。

コマンドライン

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Intune 修復スクリプト（システムコンテキストで実行）

# 検出スクリプト：BlockNtlmv1SSOが明示的に0に設定されている場合のみ準拠
$v = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($v -eq 0) { exit 0 } else { exit 1 }

# 修復スクリプト
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null

ドメイン参加済みデバイスの場合は、同じキー・値の名前・種類・データでグループポリシー設定のレジストリ項目を使用してください。

あくまで回避策である理由

• 脆弱なパスを再び開く。 MicrosoftはMS-CHAPv2ベースのエンドポイントが「NTLMv1に影響するリスクと類似したリスクにさらされる」と述べており、この設定は「慎重に評価し、長期的には使用しないこと」を推奨しています。
• Credential Guardが有効なデバイスには効果がない。 これらのデバイスはこの設定に関係なくMS-CHAPv2 SSOをブロックします。
• オフラインのデバイスはポリシーを受信できない。 すでにネットワークアクセスを失ったデバイスは、設定を受け取るために有線またはゲストネットワークが必要になる場合があります。
• アップデートのアンインストールは代替手段にならない。 その月のセキュリティ修正がデバイスに適用されなくなります。

回避策は時間を稼ぐために使用し、終了期限を明記した上で、その期間を移行に充ててください。

恒久的な解決策：パスワードからEAP-TLSへ

MicrosoftはMS-CHAPv2への依存をなくし、Wi-FiおよびVPN接続をEAP-TLSによる証明書ベース認証へ移行することを推奨しています。デバイスまたはユーザーは、パスワードの代わりに証明書と秘密鍵で本人確認を行い、秘密鍵はTPMで保護できます。

障害を解消するだけでなく、ユーザー体験の向上とセキュリティ態勢の強化も実現できます。

多くのネットワークがいまだにパスワードに依存している理由

問題はプロトコルではなく、PKIです。従来の構成にはAD CS・NDES・Intune Certificate Connector・アプリケーションプロキシ・CRL公開・高可用性・パッチ適用が含まれます。ラップトップに証明書を配置するためだけに多くの構成要素が必要となり、多くのチームが長年にわたって移行を先送りにしてきた主な理由です。詳細はMicrosoft ADCSの代替手段（2026年版）をご覧ください。

SCEPmanがPKIの複雑さを解消する方法

SCEPmanは、Azureのキーを使用して自社のAzureテナント内で完全に動作するAzureネイティブな認証局です。

• 迅速な開始： Azure Marketplace・ARMテンプレート・Terraformでデプロイ可能。ほとんどのチームが1時間以内に最初の証明書を発行できます。
• 管理対象デバイス： Microsoft Intune・Jamf Proなどのが SCEPを経由してデバイスとユーザーの証明書を自動的に発行・更新します。
• リアルタイム検証： 証明書はユーザーまたはデバイスオブジェクトに紐付けられ、OCSPで確認されます。IDが変更されると、アクセスは自動的に失効します。
• 既存のネットワークに対応： SCEPmanはCisco・Meraki・HPE Aruba・Fortinet・Juniperなどに対応し、既存のRADIUSサーバーと連携します。
• RADIUSサーバーが不要： RADIUSaaSと組み合わせることで、証明書ベースのWi-Fi・LAN・VPNアクセスに対応した完全なクラウドネイティブソリューションが実現します。

6ステップの移行手順

1. 現状把握。 MS-CHAPv2をまだ使用しているSSID・有線802.1Xポリシー・VPNプロファイルを特定する。イベントID 4024と4025を確認すれば、依存しているデバイスを把握できます。
2. 必要な箇所で時間を稼ぐ。 重要なデバイスにBlockNtlmv1SSOを0に設定するが、終了期限を明記しておく。
3. SCEPmanをデプロイし、そのルートCA証明書をIntune信頼済み証明書プロファイルまたはグループポリシー経由で配布する。
4. 証明書をロールアウト。 Intune・Jamf Proまたは他のMDM SCEPプロファイル経由でデバイス証明書（必要に応じてユーザー証明書も）を発行する。
5. 段階的に切り替える。 RADIUSサーバー（NPS・既存のRADIUSまたはRADIUSaaS）でPEAPと並行してEAP-TLSを有効化し、Wi-Fi・802.1X・VPNプロファイルをグループ単位でEAP-TLSに移行する。
6. クリーンアップ。 MS-CHAPv2ポリシーを削除し、BlockNtlmv1SSOを1に戻すか値を削除してWindowsが再びセキュアなデフォルトを使用するようにする。

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f

まとめ

Microsoftはすでに方針を決定しています。MS-CHAPv2によるパスワードベースのネットワークSSOには、Windows上での将来はありません。KB5127648を数週間回避し続けることもできますが、この機会を活かして証明書ベースのアクセスへ恒久的に移行することを検討してください。

地味なPKI。信頼できる証明書。

SCEPmanを無料で試す

FAQ