Windows 11 24H2への更新後に802.1X認証が失敗しても、Credential Guardがすべてのパスワード認証を遮断したとは限りません。有線／無線、ユーザー／コンピューター認証、EAP方式、自動サインインと手動入力、端末とRADIUS側のログを分けて確認します。保護機能の一括無効化やOSの即時ロールバックを先に行わず、管理者が原因を特定するための順序を整理します。
Credential Guardで影響するのは何か
MicrosoftのCredential Guardに関する公式資料は、MS-CHAPのシングルサインオン（SSO）がブロックされる一方、ユーザーによる手動の資格情報入力は利用可能と説明しています。PEAP-MSCHAPv2を使っているというだけで、接続方法全体が利用不能になるとは判断しません。
Windows 11では、要件を満たす端末のCredential Guard既定有効化は22H2以降の条件に関わります。「24H2で初めて全端末に有効化された」という説明ではありません。エディション、ハードウェア要件、これまでの設定、管理ポリシーによって状態が異なるため、実際の端末で確認します。
また、ポリシーを［未構成］にすることと無効化は同じではありません。適格な環境では既定動作で有効になる場合があります。接続できないからといって、VBS、Hyper-V、Credential Guardやアプリケーション制御をまとめて停止する手順は使いません。
最初に記録する情報
OSのエディション・バージョン・ビルド、直前の更新、NICとドライバー、有線／Wi-Fi、接続プロファイル、認証方式、ユーザー／コンピューター認証、サーバー名と製品、エラー全文、発生時刻を記録します。別端末や更新前端末と比較するときも、同じネットワーク・同じ認証条件か確認してください。
PEAPという外側の方式だけでなく、内側がMSCHAPv2なのか証明書方式なのかも確認します。サードパーティEAPプラグインを使っている場合は製品名、版、対象OS・CPUアーキテクチャの対応情報が必要です。
自動認証と手動入力を切り分ける
ログオンしたWindowsの資格情報を自動利用する構成で失敗し、認められた手順で手動入力すると接続できる場合は、SSOの影響を調べる材料になります。ただし、手動入力で成功したことだけでCredential Guardが唯一の原因と確定するわけではありません。
資格情報を入力する画面が出ない場合も、クライアントの設定、認証の段階、RADIUS側の拒否、プラグインなどを調べます。入力画面がないことから、Windows Hello方針によるUI廃止や特定DLLの強制終了を推測で断定しないでください。
認証サーバーの証明書検証を無効にして入力を通す方法は避けます。正当なサーバーか確認できない状態で資格情報を入力せず、管理者へ接続先と証明書の確認を依頼してください。
端末側とRADIUS側のログを同じ時刻で比較
端末ではイベントビューアーの有線／無線の自動構成ログなどを確認します。有線はWired-AutoConfig/Operational、無線はWLAN-AutoConfig/Operationalが切り分けの起点です。EAPHostの情報を含め、利用可能なログの表示とエラー内容を確認します。すべての環境で同じイベント番号が必ず出ると決めつけません。
RADIUSとしてWindows NPSを使っている場合は、サーバー側の認証要求と拒否理由も調べます。NPSのセキュリティログでは、拒否6273・許可6272のイベント、適用ポリシー、Reason Codeと説明を確認します。端末から要求が届いていないのか、ポリシーで拒否されたのか、証明書や資格情報で失敗したのかを分けます。スイッチ／アクセスポイント側の記録も、同じ発生時刻で突き合わせます。
情報取得の例として、有線インターフェースとプロファイルは次で確認できます。これは設定変更や認証回避のコマンドではありません。
netsh lan show interfaces
netsh lan show profiles出力やログにはユーザー名、端末名、組織内の接続情報が含まれる場合があります。管理者が必要な範囲を収集し、公開の掲示板にそのまま添付しないでください。パスワード、秘密鍵、認証用の秘密情報は共有しません。
Credential Guardの実際の状態を確認
Microsoftの管理資料に沿って、システム情報の仮想化ベースのセキュリティで実行中のサービスなどから状態を確認します。設定が有効と表示されることと、サービスが実際に動作していることを区別します。確認結果を、認証方式とSSO／手動入力の結果に照らし合わせて判断します。
一時的な保護設定の変更が必要かどうかは、組織のセキュリティ管理者がリスク、対象端末、期間、復旧方法を確認して決める管理作業です。一般記事のコマンドをコピーしてハイパーバイザーを停止することは推奨しません。
サードパーティEAPの問題は製品の対応情報を確認
EAP-GTCや独自モジュールを利用している場合は、提供元が対象Windowsビルドで検証した版を確認します。DLLの署名、アーキテクチャ、登録、UIの動作等は製品固有の情報とログで判断します。
「24H2では最新SDKでの再ビルドが一律必須」「SHA-1や自己署名のモジュールはすべて即終了」といった一般化はしません。未確認のレジストリ値を追加したり、テスト署名モードへ変更したりせず、再現条件とログを提供元へ伝えます。
証明書ベースの認証へ移行するときの条件
MicrosoftはパスワードベースのMSCHAPv2から証明書ベースの認証への移行を推奨しています。ただし、EAP-TLSへ変更すれば準備なしで接続できるわけではありません。クライアントとサーバーの証明書、信頼するCA、有効期限、用途、名前の検証、失効確認、証明書の配布と更新を設計します。
RADIUS/NPSのポリシー、端末の接続プロファイル、スイッチやアクセスポイントとの組み合わせを検証し、限定した対象で接続と更新・失効時の動作を確認します。全端末の準備前に既存方式を一括で無効化すると、業務接続を失うおそれがあります。
TEAPの対応や構成はクライアント・サーバー製品ごとに確認します。Microsoft Entraの証明書ベース認証は、既存の802.1X/RADIUS設定をそのまま置き換えるものではありません。製品を問わず使えるスイッチCLIや、設定ブロックを書き換えるだけの移行手順は示しません。
更新・ロールバックの判断
現在のOSビルドと適用更新を確認し、Microsoftのリリース情報や機器ベンダーの既知の問題で、同じ条件の事象があるか照合します。未確認の「今後の累積更新で修正される」という内部情報や、日付のない修正予定を判断材料にしません。
OSを戻す操作は、利用できる期間、復元用ファイル、データ、アプリ、サポート期限への影響を含む管理判断です。24H2の障害だからといって一律に23H2へ戻す、即時再起動するコマンドを実行する、といった対処は避けます。証拠を確保し、承認した復旧計画に沿って対応してください。
まとめ
Windows 11 24H2で802.1Xが失敗するときは、EAP方式と認証の段階、SSOと手動入力、端末とRADIUSの両ログを切り分けます。Credential Guardの影響を正しく確認し、証明書方式への移行は必要な基盤を整えたうえで段階的に進めます。
公式資料
Credential Guardの考慮事項／802.1Xのトラブルシューティング／EAP-TLS／PEAPの証明書要件／Credential Guardの状態確認／netsh lan／Entra CBA
コメント