Windows 11 端末を社内の GPO 配布 Wi‑Fi に参加させようとすると、「このネットワークに接続できません」とだけ表示され、Windows 10 では問題なくつながる――そんな現場の声が増えています。本記事では、特に 22H2 以降で多い Credential Guard や証明書まわりの原因と、再発しないための設定・運用ポイントを詳しく整理します。
Windows 11 だけが GPO 配布の Wi‑Fi に接続できない理由
まず押さえておきたいのは、「GPO の Wi‑Fi 設定そのものは正しいのに、Windows 11 だけが失敗する」というケースが非常に多いことです。つまり、ネットワーク側（AP や NPS/RADIUS）の設定ミスではなく、クライアント OS 側の仕様変更やセキュリティ強化が原因になっている可能性が高い、という前提で切り分けると効率的です。
| 項目 | Windows 10 | Windows 11（22H2 以降） |
|---|---|---|
| GPO で配布した 802.1X Wi‑Fi プロファイル | 問題なく接続できる | 「このネットワークに接続できません」で失敗 |
| イベントログ（WLAN AutoConfig） | 成功ログのみ、もしくは軽微な警告 | Event ID 12013 / 11006 / 8002 などの認証・証明書エラー |
| 認証方式 | PEAP / EAP‑TLS ともに動作しやすい | Credential Guard やドライバーの影響を受けやすい |
特に、「Windows 10 の同一端末イメージ（もしくは同一ユーザー）では問題なく利用できる SSID なのに、Windows 11 にリプレースした途端につながらない」という場合、GPO や NPS の設定をいじる前に、Windows 11 側の仕様とログを丁寧に確認することが重要です。
イベントログから読み解くエラーの傾向
Wi‑Fi 接続トラブルの解析では、「再現→時刻をメモ→イベントビューアーで絞り込み」が基本です。今回のケースでよく見かけるのが、以下のイベントです。
| ログソース | イベント ID | 概要 | 主な意味合い |
|---|---|---|---|
| WLAN AutoConfig | 12013 | 証明書の選択・検証に失敗 | クライアント証明書が見つからない／条件を満たさない |
| WLAN AutoConfig | 11006 | 802.1X 認証失敗 | EAP ハンドシェイク中に失敗（証明書・資格情報・設定不整合など） |
| WLAN AutoConfig | 8002 | 認証プロセス全体の失敗 | RADIUS 側とのやり取りが最終的に失敗したことを示唆 |
これらのイベントは、Windows 11 のセキュリティ強化（Credential Guard / VBS）や証明書ストアの挙動と組み合わさることで、Windows 10 では問題にならなかったシナリオを顕在化させます。
WLAN AutoConfig ログの確認手順
- イベントビューアーを開く（
eventvwr.msc）。 - 左ペインで「アプリケーションとサービス ログ → Microsoft → Windows → WLAN‑AutoConfig → Operational」を開く。
- 右側の「現在のログをフィルター」で、イベント ID に
12013,11006,8002を指定して絞り込み。 - ユーザーに再現してもらい、その時刻前後のイベントを時系列で追う。
さらに、コマンドプロンプトまたは PowerShell から netsh wlan show wlanreport を実行すると、HTML 形式の詳細レポートを確認できます。どのフェーズ（接続試行、認証、IP 取得など）で失敗しているかを把握しやすくなるため、イベントログと併せて確認すると原因に早くたどり着けます。
主な原因候補と考え方
現場で多く報告されている原因パターンは次の 4 つです。
- Credential Guard（VBS）による PEAP / MS‑CHAPv2 など機械認証のブロック
- Wi‑Fi ドライバー（特に Intel AX シリーズ）の不具合
- クライアント証明書の残存／不一致
- NPS/RADIUS 側との EAP 設定不整合
Credential Guard（VBS）が PEAP / MS‑CHAPv2 をブロックするケース
Credential Guard は、LSA（Local Security Authority）や資格情報を隔離することで、パスワードやハッシュの窃取を防ぐための機能です。Windows 11 では、特定エディションや条件下で 標準で有効化されるケースがあり、これが 802.1X の機械認証に影響することがあります。
典型的には、以下のような構成で問題が表面化します。
- 認証方式：PEAP（EAP‑MSCHAPv2）
- GPO の Wi‑Fi プロファイルで「コンピューター認証」または「ユーザーまたはコンピューター認証」を選択
- Windows 10 では正常にコンピューターアカウントで認証できていた
- Windows 11 22H2 では、Credential Guard が有効な端末のみ接続に失敗
Credential Guard により、レガシーなチャレンジレスポンス方式や一部の資格情報の扱いに制限がかかり、その結果、機械認証フェーズで資格情報が使えず認証が失敗します。イベントログ上は 12013/11006 などのエラーとして表れますが、クライアント証明書自体には問題がないことも多く、原因の切り分けが難しいポイントです。
| 観測される症状 | Credential Guard 由来の可能性 |
|---|---|
| Windows 11（特定機種）のみ、機械認証で失敗する | 高い |
| 同じユーザーが自宅の WPA2‑PSK では問題なく接続できる | 企業向け 802.1X 認証に限定した問題 → CG/VBS 起因の疑い |
| Credential Guard を無効化したテスト機だけ接続が成功する | ほぼ確定 |
Wi‑Fi ドライバーの不具合（Intel AX201/8260 など）
Windows 11 では、新しいドライバー・新しい無線チップセットの組み合わせが増えており、特定バージョンのドライバーで 証明書の列挙や EAP ハンドシェイクが正常に処理できない事例も報告されています。
- Intel AX201 / 8260 / 9560 などのチップセット
- OEM（メーカー）提供バージョンと Windows Update 提供バージョンが混在
- Windows 10 では同じドライバーでも問題が出ないが、Windows 11 環境でのみ不安定
このような場合、ドライバーの更新・ダウングレード・クリーンインストールで改善するケースが多く、GPO や証明書をいじる前に確認しておく価値があります。
旧証明書の残存・証明書不一致
EAP‑TLS など証明書ベースの認証を利用している場合、クライアント側の証明書ストアに問題があると、Windows 11 でのみ不具合が顕在化することがあります。代表例は次のとおりです。
- アーカイブされた古いクライアント証明書が残っており、誤ってそれが選ばれてしまう
- 「クライアント認証」EKU を持たない証明書しか存在しない
- コンピューター証明書がローカルコンピューター ストアではなく、ユーザーストアにだけ存在する
- サーバー側が要求する証明書の条件（発行 CA / サブジェクト / テンプレート）が変わったのに、クライアント証明書が更新されていない
Windows 11 は、セキュリティ強化に伴い証明書の検証がより厳密になった側面もあり、曖昧な状態の証明書ストアがあると、Windows 10 では偶然通っていたものが通らなくなるといった現象が起こります。
NPS/RADIUS 側との EAP 設定不整合
最後に、サーバー（NPS / RADIUS）の EAP 設定とクライアント側 GPO の設定が食い違っているケースです。例えば、次のようなパターンです。
- NPS 側は EAP‑TLS 前提だが、クライアント GPO で PEAP（EAP‑MSCHAPv2）を選択している
- サーバー証明書の検証を必須にしているのに、クライアントがルート CA を持っていない
- サーバー側で一部の古い暗号スイートを無効化した結果、古いクライアントだけ失敗している
Windows 10 と Windows 11 で「たまたま動いている設定」が異なっている場合、OS を跨いだときに問題が顕在化します。特に、Windows 11 専用の SSID を設けずに既存 SSID をそのまま流用している環境では注意が必要です。
優先度付きトラブルシューティングの全体像
ここからは、現場で実際に効果があった対処を、優先度付きのチェックリストとして整理します。
| 優先度 | 対処内容 | 概要 |
|---|---|---|
| ★ | Credential Guard / VBS の無効化テスト | テスト用 GPO で一時的に無効化し、現象が解消するかを確認する |
| ★ | 旧・不要証明書の削除 | アーカイブされた証明書を含めて整理し、クリーンな状態で再接続 |
| ☆ | Wi‑Fi ドライバーの更新／クリーンインストール | OEM 推奨版や安定版ドライバーへの切り替え |
| ☆ | 証明書配布と EAP 設定の再確認 | クライアント証明書が正しいストアに配布されているか、NPS と GPO の EAP 設定が一致しているかを確認 |
| △ | ログの詳細分析 | NPS/RADIUS ログと netsh wlan show wlanreport を突き合わせ、失敗フェーズを特定 |
Credential Guard / VBS を無効化して切り分ける
最も多く報告されている根本原因が Credential Guard であるため、まずは 「無効化したテスト環境で現象が消えるか」を確認するのがおすすめです。
GPO から Credential Guard / VBS を無効化する手順
- ドメイン コントローラーで グループ ポリシー管理コンソール（gpmc.msc） を開く。
- テスト用 OU に適用する新しい GPO を作成、または対象端末だけが入っている OU に限定してリンクする。
- 編集画面で、次のパスを開く。
コンピューターの構成 → 管理用テンプレート → システム → Device Guard - 「Virtualization Based Security を有効にする（Turn on Virtualization Based Security）」 を 「無効」 に設定する。
- 対象の Windows 11 端末で
gpupdate /forceを実行し、再起動する。 - 再起動後、問題の Wi‑Fi SSID への接続を再度試す。
この手順で Wi‑Fi 接続が成功するようになった場合、Credential Guard が 802.1X 認証に干渉していた可能性が極めて高いと判断できます。本番で無効化するかどうかはセキュリティポリシーとのトレードオフになるため、次章の「無効化できない場合の代替案」も併せて検討してください。
旧・不要なクライアント証明書の整理
証明書ベースの認証を利用している場合は、証明書ストアの整理だけで一気に安定するケースも珍しくありません。特に、Windows 10 時代から端末をインプレースアップグレードしている環境では、過去の証明書がアーカイブされたまま残っていることが多いです。
証明書 MMC でアーカイブ済み証明書を整理する
mmc.exeを実行し、空のコンソールを開く。- 「ファイル → スナップインの追加と削除」から、「証明書」スナップインを追加する。
- 「コンピューター アカウント」を選択し、「ローカル コンピューター」を指定して完了。
- 左ペインで「個人 → 証明書」を選択し、右クリック → 「表示オプション」で「アーカイブされた証明書を表示する」にチェックを入れる。
- 期限切れ・アーカイブ済みで、Wi‑Fi 認証に不要な証明書を慎重に確認しながら削除する。
gpupdate /forceを実行し、再度 Wi‑Fi への接続を試す。
加えて、次の点も確認しておきましょう。
- 対象端末の ローカル コンピューター ストアに、クライアント認証（Client Authentication）EKU を持つ証明書が存在するか
- その証明書が、NPS/RADIUS 側で許可されているテンプレートから発行されているか
- ルート CA ／中間 CA が「信頼されたルート証明機関」「中間証明機関」のストアに正しくインポートされているか
証明書の EKU や発行元が要件を満たさない場合、Windows 11 はその証明書を認証に使わず、結果として 12013 等のエラーを出力します。
Wi‑Fi ドライバーを更新・クリーンインストールする
ドライバー関連のトラブルは、目に見えるエラーとしては「証明書エラー」「認証エラー」に見えるため、原因として見落とされがちです。特に同じ機種の中で「あるロットだけ」「あるバージョンだけ」不安定な場合は、ドライバー起因を強く疑うべきです。
ドライバーの確認と更新手順
- 問題の Windows 11 端末で、「デバイス マネージャー」を開く。
- 「ネットワーク アダプター」から対象の Wi‑Fi アダプター（例：Intel(R) Wi‑Fi 6 AX201）をダブルクリック。
- 「ドライバー」タブで、ドライバー バージョン・日付をメモする。
- OEM メーカー（PC ベンダー）のサポートサイトで、同機種向け推奨ドライバー バージョンを確認する。
- 推奨バージョンと異なる場合は、OEM 提供版または Intel 公開の安定版パッケージをダウンロードし、インストールする。
クリーンインストールのポイント
- デバイス マネージャーでアダプターを右クリックし、「デバイスのアンインストール」を選択。
- 「このデバイスのドライバー ソフトウェアを削除する」にチェックを入れて削除する。
- 再起動後、OEM 提供のドライバー パッケージを実行し、インストールする。
ドライバーの入れ替え後に Wi‑Fi 接続が安定するようであれば、ドライバー起因のバグ・相性問題だったと判断できます。本番展開前には、できるだけ同一バージョンのドライバーに揃えてから Windows 11 へ移行することが理想です。
証明書配布と EAP 設定の再確認
Credential Guard やドライバーを疑う前に、そもそもクライアントに必要な証明書が配布されているか、サーバーとクライアントの EAP 設定が一致しているかを整理しておくことも重要です。
証明書配布のチェックポイント
- 対象端末の
certlm.mscで「個人 → 証明書」を開き、コンピューター証明書が配布されているか - 「拡張キーの使用法」に「クライアント認証」が含まれているか
- 有効期限が十分に残っているか（期限ぎりぎりの証明書は早めに更新）
- GPO の自動登録（Autoenrollment）が有効になっているか
NPS/RADIUS とクライアントの EAP 設定突合せ
| 項目 | NPS/RADIUS 側 | クライアント（GPO）側 |
|---|---|---|
| EAP タイプ | EAP‑TLS / PEAP（EAP‑MSCHAPv2）など | 同じものを選択しているか確認 |
| サーバー証明書検証 | 必須にしているかどうか | 「サーバー証明書を検証する」にチェックが合っているか |
| 許可するルート CA | RADIUS サーバーの証明書発行元 CA | クライアントに同じ CA のルート証明書が配布されているか |
| 認証方式 | ユーザー / コンピューター / 両方 | Wi‑Fi プロファイルの「認証モード」と一致しているか |
特に、Windows 11 端末向けに EAP‑TLS へ移行する場合、「ユーザー認証のみなのか」「コンピューター認証も要求するのか」の方針を最初に決めておくと、後からのトラブルが減ります。
ログ・レポートを使って失敗フェーズを特定する
原因の当たりがつきにくい場合は、クライアント側とサーバー側のログを並べてタイムラインを見るのが有効です。
クライアント側で確認する情報
- イベントビューアー → WLAN‑AutoConfig → Operational
netsh wlan show wlanreportで生成される HTML レポート- 必要に応じて、Wi‑Fi アダプターの詳細ログ（ベンダー独自ツールなど）
サーバー側で確認する情報
- NPS ログ（Accounting / Security ログ）
- RADIUS サーバーのイベントログ（EAP エラーコード）
- Wi‑Fi コントローラや AP のログ（認証拒否理由）
クライアント側の 12013/11006 と、サーバー側の EAP エラーコードの時刻を照らし合わせることで、「クライアント証明書の選択で失敗しているのか」「RADIUS 側でポリシー違反になっているのか」を切り分けられます。
Credential Guard を無効化できない場合の代替策
セキュリティポリシー上、Credential Guard / VBS を無効化できない組織も多いはずです。その場合、認証方式を見直すことで、Credential Guard と共存できる構成に移行することを検討します。
EAP‑TLS（証明書ベース認証）への移行
Credential Guard の影響を受けにくい代表的な方式が EAP‑TLS です。クライアント証明書を適切に配布しておけば、パスワードに依存せず安全で安定した認証が実現できます。
- 端末またはユーザーごとに証明書を発行
- Intune / SCEP / AD CS の自動登録機能でローテーションを自動化
- 証明書の失効リスト（CRL）・OCSP の到達性を確保
Windows 11 導入のタイミングで EAP‑TLS へ移行することで、Credential Guard を有効に保ったまま 802.1X を利用できるようになり、長期的な運用も安定します。
パイロット導入での検証ポイント
- パイロット用 OU／グループを作成し、限定した端末・ユーザーで EAP‑TLS を試す
- NPS 側で PEAP と EAP‑TLS を両方許可し、段階的に移行する
- 証明書の更新タイミング（有効期限前後）の挙動を事前に確認
実例ベースの「よくあるパターン」と対策
| ケース | 環境 | 原因 | 対処 |
|---|---|---|---|
| ケース A | Windows 11 22H2 ノート PC、PEAP（EAP‑MSCHAPv2）、GPO で機械認証 | Credential Guard により機械アカウントの認証がブロック | テスト機で Credential Guard を無効化 → 接続成功 → 方針検討の上、一部端末のみ無効化または EAP‑TLS へ移行 |
| ケース B | Windows 10 から 11 へアップグレードした既存端末、EAP‑TLS 認証 | アーカイブされた古いクライアント証明書が優先的に選択される | 証明書 MMC でアーカイブ済み証明書を削除し、再配布。Autoenrollment 設定を見直し |
| ケース C | 新規導入 Windows 11 機のみ不安定、Intel AX201 搭載 | 特定バージョンの Wi‑Fi ドライバーの不具合 | OEM 推奨版ドライバーへ統一し、問題のバージョンを WSUS / Intune でブロック |
設計・運用視点でのチェックリスト
単発の障害対応だけでなく、今後の Windows 11 展開を見据えた設計・運用の見直しも重要です。
| カテゴリ | チェック項目 |
|---|---|
| OS 標準設定 | Credential Guard / VBS の既定状態を把握し、どの SKU・世代で有効化されるかを整理しておく |
| 認証方式 | パスワード依存の PEAP から、証明書ベースの EAP‑TLS への移行計画を立てる |
| 証明書管理 | テンプレート・配布・更新・失効のライフサイクルを文書化し、Intune / GPO で自動化する |
| ドライバー管理 | Wi‑Fi ドライバーの推奨バージョンを決め、WSUS や Intune で統制する |
| 監視・ログ | NPS ログとクライアント側 WLAN レポートを定期的に確認できる運用フローを作る |
まとめ：まずは Credential Guard と証明書・ドライバーを疑う
Windows 11 端末が、GPO で配布した社内 Wi‑Fi（802.1X）に接続できない場合、多くの現場で共通しているのは次のポイントです。
- 最も多い根本原因は Credential Guard / VBS の干渉であり、テスト用 GPO で無効化して切り分ける価値が高い。
- 証明書ストアの整理（アーカイブ済み証明書の削除・EKU の確認）は、Windows 11 への移行時に一度は必ず実施したい。
- Wi‑Fi ドライバーのバージョン不整合は、症状が端末やロットに偏る場合の有力な容疑者となる。
- 企業ポリシー上 Credential Guard を無効化できない場合は、EAP‑TLS と Intune/SCEP 等による証明書自動更新を組み合わせた設計への移行を検討する。
「Windows 10 では問題ないのに、Windows 11 だけつながらない」という状況は、ユーザー体験としてもヘルプデスクとしても非常にストレスの大きいトラブルです。本記事の内容をもとに、Credential Guard → 証明書 → ドライバー → EAP 設定の順で切り分けを行えば、原因にたどり着くまでの時間を大きく短縮できるはずです。
これから Windows 11 を本格展開する組織では、パイロット導入の段階でここまでの観点を一度洗い出し、「再現しやすいテストケース」と「想定される対処パターン」をあらかじめ整備しておくことをおすすめします。
コメント