Windows 11 をドメイン参加端末として展開したら、サインイン画面（ログオン前）で社内の 802.1X（PEAP）Wi-Fi に繋がらない――そんな現象の原因と、最短での解決策（EAP-TLS への移行）と、ログの見方までまとめます。
現象の整理：Windows 10 ではできた「ログオン前 Wi-Fi」が Windows 11 でできない
まず、問い合わせで多い症状を「何が起きているか」に分解します。似たようなトラブルでも、原因が異なると打ち手が変わるためです。
| 観点 | Windows 10 でよく起きていた挙動 | Windows 11 での困りごと |
|---|---|---|
| サインイン画面で社内 Wi-Fi（802.1X/PEAP）に接続 | ユーザー資格情報（ID/パスワード）入力が促され、接続できる | 「このネットワークに接続できません」で失敗し、入力画面が出ない／出ても通らない |
| 初回だけ有線でログオン→以降は Wi-Fi でログオン | 一度ログオンすると資格情報が使われ、次回以降ログオン前でも Wi-Fi が通ることが多い | 初回は有線必須になりやすい。サインアウトすると再びログオン前 Wi-Fi が通らなくなる |
| 切り分けで見たい情報 | クライアントの WLAN ログ／NPS ログなどで追える | 同様に追えるが、Windows 11 固有の「SSO が効かない」要因が混ざる |
ポイントは、単なる「Wi-Fi が不安定」ではなく、ログオン前（サインイン画面）で 802.1X（PEAP）認証が成立しないことです。ログオン後は繋がるのに、ログオン前だけ落ちるパターンが典型です。
まず押さえる：ログオン前 Wi-Fi と 802.1X（PEAP）の仕組み
802.1X の無線（WPA2-Enterprise / WPA3-Enterprise）は、ざっくり言うと次の三者が登場します。
- サプリカント：Windows クライアント（接続したい端末）
- オーセンティケータ：AP / コントローラ / スイッチ（通す・遮断を制御）
- 認証サーバ：RADIUS（代表例：NPS、Cisco ISE、Aruba ClearPass など）
この中で、PEAP（特に内側が MSCHAPv2 の構成）はユーザー名/パスワードに依存します。つまり、ログオン前に Wi-Fi を通したい場合、Windows は「まだログオンしていないのに、認証に使う資格情報をどこから持ってくるか？」という課題を解く必要があります。
ここで鍵になるのが、Windows の 802.1X の Single Sign On（SSO）（旧称 PLAP）です。SSO を有効化すると、ログオン処理の前後で 802.1X 認証を実行でき、ログオン前にネットワークを通して GPO 適用やドメインログオンを成立させる用途で使われます。
Windows 11 で詰まりやすい「2 つの地雷」
実務上、Windows 11 のログオン前 Wi-Fi（802.1X/PEAP）でハマる原因は、だいたい次の 2 つのどちらか（または両方）です。
| 原因候補 | 起きる症状 | なぜ Windows 11 で顕在化しやすい？ |
|---|---|---|
| Wi-Fi プロファイルが「ユーザー単位」になっている | ログオン前は資格情報が紐づかず、接続や認証が成立しない | 手動設定や一部ツールで “Current User” プロファイルになりがち |
| Credential Guard（VBS）により MSCHAPv2 の SSO が効かない | 一度繋がっても、サインアウト/再起動で SSO が効かず、ログオン前に通らない | Windows 11 22H2 以降、要件を満たす端末で Credential Guard が既定で有効化されやすい |
このうち、今回のご相談内容（Windows 10 では “一度有線ログオンすれば以降は OK” だったのに、Windows 11 では毎回ダメになりやすい）に一致しやすいのが、後者の Credential Guard（VBS） です。
原因の第一候補：Credential Guard（VBS）で「PEAP（MSCHAPv2）の SSO」がブロックされる
Microsoft のドキュメントでは、Credential Guard が有効な環境で、パスワードベースの “安全でないプロトコル” に依存する SSO が動作しない既知の問題が説明されています。802.1X（無線/有線）も影響範囲に含まれ、MS-CHAP（MSCHAPv2 系）などは「SSO がブロックされる」扱いになります。
ここが重要です。
- PEAP-MSCHAPv2 は「TLS のトンネルの中で、結局パスワードで認証する」方式
- Credential Guard は資格情報（特に再利用されやすい形の資格情報）の取り扱いを厳しくし、SSO で勝手に流用する挙動を止める
- 結果として、Windows 10 で成立していた「一度ログオンしたら、次からはログオン前でも Wi-Fi 認証が走る」が崩れる
さらに厄介なのが、SSO が効かない場合の “次の動き” です。Microsoft は「MS-CHAP などは SSO がブロックされるが、ユーザーに資格情報を入力させれば使える」と説明しています。ところが、ログオン前の Wi-Fi 接続で資格情報入力ダイアログが出ない設定だと、ユーザーは入力のしようがなく、そのまま「このネットワークに接続できません」になりがちです。
まずは 10 分でやる切り分け：本当に “Credential Guard 起因” か？
Credential Guard が動いているか確認する
Windows 11 側で、Credential Guard（VBS）が有効かどうかを先に確認します。確認方法は複数ありますが、現場で速いのは次の 2 つです。
- msinfo32（システム情報）で “Virtualization-based Security Services Running” を確認
- PowerShell で Win32_DeviceGuard を確認
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
この値に Credential Guard を示す値が含まれていれば、まずは「SSO が効かない前提」で設計し直す必要がある、という判断になります。
Wi-Fi プロファイルが “All User（端末単位）” か確認する
ログオン前に使わせたい Wi-Fi は、原則として端末単位（All User）で配布されている必要があります。手動設定だとユーザー単位になり、ログオン前に参照されないことがあります。
netsh wlan show profiles
一覧に “All User Profile” として SSID が出ているかを見てください。All User でない場合は、GPO（コンピューター構成）または MDM（デバイス構成）で配布するのが基本です。GPO の Wi-Fi 設定は通常、以下にあります。
コンピューターの構成
→ ポリシー
→ Windows の設定
→ セキュリティの設定
→ ワイヤレス ネットワーク (IEEE 802.11) ポリシー
結論：現実的な対処は 2 択になりやすい
今回の要件（ログオン前に 802.1X Wi-Fi を通してドメインログオンしたい）で、かつ PEAP（ユーザー名/パスワード）を前提にしている場合、Windows 11 + Credential Guard の組み合わせだと、回避策は実質的に次の 2 つに収束します。
| 対処 | ログオン前 Wi-Fi | 運用 | セキュリティ | おすすめ度 |
|---|---|---|---|---|
| EAP-TLS（証明書）へ移行 | 成立させやすい（端末証明書で機械認証ができる） | 初期構築は必要だが、以降は自動化しやすい | 強い（パスワード流用を避けられる） | 高 |
| VBS / Credential Guard を無効化 | PEAP の SSO が戻り、症状が消えることがある | 端末管理ポリシーと整合が必要 | 下がる（資格情報窃取耐性が落ちる） | 低（暫定） |
Microsoft も、MSCHAPv2 ベース（例：PEAP-MSCHAPv2、EAP-MSCHAPv2）から、証明書ベース（例：EAP-TLS）へ移行することを推奨しています。Credential Guard は証明書ベース認証をブロックしない、という説明も明記されています。
推奨：EAP-TLS（証明書）へ移行して「ログオン前」を安定させる
ログオン前に確実に Wi-Fi を通すなら、設計としては端末証明書（コンピューター証明書）による機械認証を最初に成立させるのが強力です。ログオン後に必要なら、ユーザー証明書やユーザー認証へ切り替える（または VLAN を切り替える）設計もできます。
EAP-TLS のメリット
- ユーザーのパスワード入力に依存しない（ログオン前でも成立しやすい）
- Credential Guard の影響を受けにくい（“SSO がブロックされる” 問題を回避）
- パスワードをネットワーク認証に流用しないため、セキュリティ的にも筋が良い
構成要素（オンプレ AD を想定）
| 要素 | 役割 | よくある実装 |
|---|---|---|
| PKI | クライアント証明書を配布する | AD CS / 企業内 CA |
| RADIUS | 802.1X の認証・認可を行う | NPS / ISE / ClearPass |
| 配布手段 | Wi-Fi プロファイルを端末に配布する | GPO（推奨）/ Intune 等の MDM |
| クライアント | 端末証明書を保持して EAP-TLS で認証する | Windows 11（ドメイン参加） |
移行の手順（実務での “最短ルート”）
端末証明書の自動配布（GPO の自動登録）を整える
ドメイン参加端末なら、証明書の自動登録（Auto-Enrollment）で「配って終わり」に近い運用ができます。端末に証明書が入ることが、EAP-TLS の前提です。
- クライアント（ローカルコンピューター）に、クライアント認証（Client Authentication）用途の証明書が自動配布される
- クライアントが信頼するルート/中間 CA も配布される
ここができると、キッティングで “有線必須” を短縮できます（最初にドメイン参加を行う手順は別途必要ですが、以後の展開は一気に楽になります）。
NPS（RADIUS）側を EAP-TLS に対応させる
NPS を使う場合の考え方はシンプルです。
- NPS にサーバー証明書（サーバー認証）を設定する
- ネットワークポリシーの認証方法を「証明書（スマートカードまたはその他の証明書）」にする
- 認可（許可/拒否）を AD グループや端末属性で制御する
PEAP のときと比べて “パスワードで照合する” パートが消えるため、Credential Guard の影響を受けにくく、ログオン前の安定性が上がります。
Wi-Fi プロファイル（GPO）を EAP-TLS で配布し、SSO を有効化する
GPO の Wi-Fi プロファイルでは、ログオン前に通したい場合、Single Sign On（SSO）を有効化します。SSO は「ログオンの前後どちらで 802.1X を走らせるか」などを制御できます。
特にログオン前のトラブルで見落とされがちなのが、SSO の追加ダイアログ設定です。SSO の設定には「追加ダイアログを表示してよいか」という項目があり、既定は false と説明されています。パスワード方式で “入力が必要になる” 構成だと、この設定が false のままだと UI が出ず失敗に寄りやすい、という構図になります。
EAP-TLS でも「証明書選択を自動化（Simple certificate selection）」しておくと、ログオン前でもユーザー操作なしで成立しやすくなります（証明書が複数ある環境では選択条件も合わせて整備します）。
機械認証のみ／ユーザー併用の設計パターン
要件次第で、次のどれに寄せるかが変わります。
| パターン | ログオン前 | ログオン後 | 向いているケース |
|---|---|---|---|
| 機械認証のみ（端末証明書） | 強い | そのまま継続 | 端末が社給で、端末単位のアクセス制御で十分 |
| 機械→ユーザー（VLAN 切替など） | 強い | ユーザー属性で制御可能 | ログオン後は部門別 VLAN、権限別 VLAN を使いたい |
| ユーザー認証のみ（PEAP/パスワード） | 弱くなりがち | 成立しやすい | 証明書運用がどうしても難しい（ただし Win11 では注意） |
非推奨だが現実に選ばれる：Credential Guard を無効化する場合
要件・工数・既存インフラの都合で「当面は PEAP 継続、まずは Windows 11 を繋げたい」という局面もあります。その場合、最も即効性が高いのは Credential Guard（VBS）を無効化することです。
ただし、Microsoft も “より即時だが安全性は下がる” 対応として扱っており、無効化はリスクを伴います。社内のセキュリティ基準・監査要件と必ずすり合わせた上で実施してください。
GPO で制御する場合、設定場所の例は次のとおりです（環境によりポリシー名の表示は多少異なります）。
コンピューターの構成
→ 管理用テンプレート
→ システム
→ Device Guard
→ 「仮想化ベースのセキュリティを有効にする（Turn On Virtualization Based Security）」
無効化後は再起動が必要です。UEFI ロック有無など構成により無効化手順が変わる点にも注意してください。
PEAP を続けるなら：ログオン前で “入力画面が出ない” を潰す
Credential Guard が有効なまま PEAP（MSCHAPv2）を継続する場合、「SSO が効かない＝毎セッション手動入力が必要」という方向になりやすいです。したがって、ログオン前に繋げたいなら、少なくとも “入力できる状態” を用意する必要があります。
ここで確認したい設定の例です。
- SSO（Single Sign On）を有効化し、ログオン前に認証を走らせる
- SSO の「追加ダイアログを表示」を許可する（許可しないと UI が出ないことがある）
- PEAP 設定で「Windows のログオン名とパスワードを自動的に使用する」の挙動を把握する
PEAP のプロファイル作成手順の中でも、サーバー証明書検証や、内側の認証方式（EAP-MS-CHAP v2）や「Automatically use my Windows logon name and password」などの設定が登場します。これらは“動けば楽”ですが、Windows 11 + Credential Guard ではその前提（SSO による流用）が崩れやすい点が落とし穴です。
結局のところ、PEAP 継続でログオン前接続を安定させたいなら、プロファイル調整だけで “完全解決” できないケースが多く、EAP-TLS に寄せた方が最短になりがちです。
調査で見るべきログ：クライアントとサーバーを “両側” で追う
「GPO の問題か」「サーバー側（NPS/RADIUS）の問題か」を切り分けるには、クライアントとサーバーのログを同じ時刻で突き合わせるのが最短です。
クライアント側（Windows 11）
| ログ | 場所 | 見るポイント |
|---|---|---|
| WLAN-AutoConfig（Operational） | イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → WLAN-AutoConfig/Operational | 接続試行、802.1X 失敗理由、EAP 関連エラー |
| CAPI2（Operational） | イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → CAPI2/Operational（手動で有効化） | 証明書のチェーン、失効確認、検証失敗など “証明書起因” の手がかり |
少なくとも WLAN-AutoConfig は最優先です。ログオン画面で接続を試みた時刻前後で、認証失敗の理由（Reason Code 等）を拾えます。証明書系（EAP-TLS）に寄せていく場合は、CAPI2 ログが非常に効きます。
サーバー側（NPS/RADIUS）
| ログ | 場所 | 見るポイント |
|---|---|---|
| NPS イベント | （NPS サーバー）Windows セキュリティログ | 認証成功/失敗、理由コード、どのポリシーに当たったか |
| 成功/失敗の代表イベント | イベント ID 6272（成功）/ 6273（失敗） | Reason Code を確認し、証明書・資格情報・ポリシー条件を切り分け |
クライアントが「接続できません」と言っていても、NPS 側にリクエストが来ていないなら、AP/コントローラ〜RADIUS 間（共有シークレット不一致、RADIUS 宛先ミス）など別系統の疑いが濃くなります。逆に NPS が Access-Reject を返しているなら、NPS の Reason Code が原因究明の近道です。
最短で解くための実務手順：おすすめの進め方
- Windows 11 端末で Credential Guard が有効か確認（msinfo32 / PowerShell）。有効なら「PEAP の SSO は期待しない」前提に切り替える。
- Wi-Fi プロファイルが端末単位で配布されているか確認（All User プロファイルか、GPO の 802.11 ポリシーで配布されているか）。
- クライアント（WLAN-AutoConfig）と NPS（6273）を同時刻で突き合わせ、失敗理由を確定する。
- 方針決定：EAP-TLS に移行するか、暫定で Credential Guard を無効化するか。長期的には EAP-TLS が推奨。
よくある落とし穴（EAP-TLS 移行時）
- 証明書が “ユーザー” ストアに入っている：ログオン前に使うなら、基本はローカルコンピューター（端末）ストアでの配布が必要
- クライアントが NPS のサーバー証明書を信頼できない：ルート/中間 CA の配布漏れ、サーバー名不一致、失効確認の問題など
- 証明書が多すぎて選べない：自動選択（Simple certificate selection）と選択条件（EKU/発行元）を整える
- クライアントだけでなく “NPS 側の証明書” も重要：EAP-TLS/PEAP ともにサーバー証明書の整備が前提になる
まとめ：Windows 11 のログオン前 Wi-Fi は「PEAP 継続」がハードモードになりやすい
Windows 11 のドメイン参加端末で、サインイン画面から社内 Wi-Fi（802.1X/PEAP）に繋がらない問題は、GPO だけの問題ではなく、Credential Guard（VBS）による SSO の制限が原因になっているケースが増えています。Windows 11 22H2 以降は要件を満たす端末で Credential Guard が既定で有効化されるため、「Windows 10 では動いていたのに…」が起こりやすいのが現実です。
最終的な落としどころは、次のどちらかになりがちです。
- 推奨：EAP-TLS（証明書）へ移行して、ログオン前接続を安定させる（かつセキュリティも上げる）
- 暫定：Credential Guard を無効化して、PEAP の “従来挙動” を取り戻す（ただしセキュリティ低下に注意）
調査は、クライアント（WLAN-AutoConfig）とサーバー（NPS 6273/6272）を同時刻で追えば、原因の確度が一気に上がります。まずはログを見て「SSO が効いていない」事実を押さえ、EAP-TLS を前提にした設計へ舵を切るのが、遠回りに見えて最短ルートになりやすいです。
コメント