Azure AD（Entra ID）参加のみ（Intune管理）の端末を、オンプレミスCA（社内認証局）が発行した端末証明書で社内Wi‑Fiへ802.1X（EAP‑TLS / RADIUS / NPS）認証させていると、「証明書で正しく認証できた端末」かつ「ADの特定コンピューターグループに所属する端末」だけを別VLANへ振り分けたい、という要件が出てきます。本記事では、この“2条件を両方満たしたときだけVLANを割り当てる”設計と、NPSでの具体的な実装手順・落とし穴・検証のコツをまとめます。
背景：802.1X（EAP‑TLS）＋NPSで「端末単位のVLAN振り分け」をやりたい
社内Wi‑FiをWPA2/WPA3-Enterpriseで運用している場合、認証基盤としてRADIUS（Windows ServerのNPS）を採用し、端末は802.1Xで認証します。EAP方式としてEAP‑TLS（証明書認証）を使うと、パスワードではなく「証明書（秘密鍵）」の所持を根拠に認証できるため、フィッシング耐性やパスワード漏えい耐性が高いのがメリットです。
さらに、無線LANコントローラやAP（あるいはスイッチ）がRADIUSの動的VLAN（Dynamic VLAN Assignment）に対応していれば、NPSが返すRADIUS属性によって、同一SSIDでも端末属性に応じてVLANを切り替えられます。これにより、次のような“1つのSSIDでの分離”が現実的になります。
- 社員管理端末 → 社内VLAN（社内システムへ到達可能）
- BYOD/未管理端末 → 制限VLAN（インターネットのみ、社内は遮断）
- 特定部門端末 → 専用VLAN（特定ネットワークへ）
今回の要件を「条件」と「結果」に分解する
相談の本質は「証明書認証とADコンピューターグループ所属の“AND条件”でVLANを決めたい」という点です。イメージとしては、次のようなマトリクスになります。
| 判定要素 | 条件 | 望ましい振り分け例 | 狙い |
|---|---|---|---|
| 証明書 | EAP‑TLSで認証成功（社内CAが発行した端末証明書） | 満たすことが前提 | “端末が正規の証明書を保持”を担保 |
| ADグループ | 特定のADコンピューターグループに所属 | 満たす端末だけをVLAN Aへ | “運用上の許可端末”を管理者がコントロール |
そして最終的な要件は、典型的には次のようになります。
| EAP‑TLS認証 | ADコンピューターグループ所属 | 割り当てるVLAN | 扱い |
|---|---|---|---|
| OK | OK | VLAN A | 社内（高権限） |
| OK | NG | VLAN B | 制限（低権限） |
| NG | （判定前に失敗） | 接続拒否 | そもそも802.1X不許可 |
結論：NPSは「証明書認証＋ADコンピューターグループ」を組み合わせたVLAN割り当てが可能
可能です。少なくともWindows Server 2012 R2のNPSで、「コンピューターのみの認証（ユーザー無し）」＋「端末証明書（社内CA発行）でのEAP‑TLS」が成立し、さらにADのコンピューターグループ条件を組み合わせて、RADIUS属性でVLANを返す構成が動作します。
ポイントは、NPSに「1つのポリシー内で“証明書認証済み”を条件として明示」するというより、認証方式を“制約（Constraints）”でEAP‑TLSに固定し、条件（Conditions）でADグループを足す、という設計にすることです。さらに「両方成立ならA／片方だけならB」を作るには、NPSのポリシー評価順序（上から順に最初に一致したものが適用）を活用します。
なぜそれで“AND条件”を作れるのか：NPSの評価順序を使う
NPSのネットワークポリシーは、基本的に上から順に評価されます。そして、条件に一致した最初のポリシーが適用されます。この仕組みを使うと、次のように“実質的なAND条件”を実現できます。
ポリシー（優先度 高）：
条件 = EAP-TLS ＋ ADコンピューターグループ
結果 = VLAN A
ポリシー（優先度 低）：
条件 = EAP-TLS のみ
結果 = VLAN Bつまり、上位ポリシーで「両方」を満たす端末だけを拾い、拾えなかった端末は下位ポリシー（証明書だけOK）に流す、という作り方です。ここで重要なのは、“VLAN B”は「認証に成功したが、ADグループ条件には一致しなかった端末」を収容するためのフォールバックとして機能する点です。
構成の前提とチェックリスト
まず押さえる前提（Wi‑Fi機器側）
NPSがVLANを返しても、受け側（AP/WLC/スイッチ）が動的VLANを解釈して適用できなければ意味がありません。導入前に次を確認してください。
- SSIDが802.1X（WPA2/WPA3-Enterprise）で動作している
- RADIUSの標準属性（Tunnel-*）でのVLAN割り当てに対応している（またはVendor-Specific Attributeが必要）
- 同一SSIDでVLANを動的に切り替える設定（Dynamic VLAN / AAA override等）が有効化できる
証明書（EAP‑TLS）の要件
EAP‑TLSは「クライアント証明書」と「RADIUSサーバ（NPS）側のサーバ証明書」の両方が揃って初めて安定します。最低限の要件を表にまとめます。
| 対象 | 証明書のポイント | よくあるNG |
|---|---|---|
| NPS（サーバ証明書） | サーバ認証（Server Authentication）のEKU 端末が信頼するルート/中間CAでチェーンが組める CN/SANが端末側の検証条件に一致（FQDN推奨） | 自己署名や未信頼CAで端末が拒否 名前不一致で端末が接続しない |
| 端末（クライアント証明書） | クライアント認証（Client Authentication）のEKU 秘密鍵が端末にあり、EAP-TLSで使用可能 可能なら鍵をエクスポート不可/TPM保護に寄せる | EKU不足でNPSが拒否 秘密鍵なし（証明書だけ）で認証失敗 |
「Azure AD参加のみ端末」でADグループ判定を使う前提
ここがこの構成の最重要ポイントです。NPSで「Windows グループ（ADグループ）」を条件にする場合、NPSが参照できるAD上の“主体”（ユーザー/コンピューター）が必要になります。
オンプレADに参加していない（＝Azure AD参加のみ）の端末は、通常はADにコンピューターアカウントが存在しません。そのため、そのままだと“ADコンピューターグループ所属”での判定が成立しません。相談例のように運用上成立させるには、次のどれかが必要になります。
- ハイブリッド参加などで、端末に対応するADコンピューターアカウントが実在する
- 運用上の割り切りとして、ADに“参照用（ダミー）のコンピューターオブジェクト”を用意し、証明書の名前情報と紐付けてグループ管理する
後者を採る場合は、「証明書の識別子」⇔「ADコンピューターオブジェクト」の整合性が崩れると、一気に認証/振り分けが不安定になります。後述の「落とし穴」で具体的に整理します。
ポリシー設計例：2段構えで「両方ならVLAN A、それ以外はVLAN B」
NPSのネットワークポリシー設計は、まず“要件をそのままポリシーに落とす”のがコツです。以下は分かりやすい最小構成です（必要に応じて条件を追加していきます）。
| 優先度 | ポリシー名（例） | 条件（Conditions） | 制約（Constraints） | 返す属性（Settings） |
|---|---|---|---|---|
| 高 | WiFi-EAPTLS-Group-VLAN_A | NAS Port Type = Wireless – IEEE 802.11 Windows グループ = （対象のADコンピューターグループ） （必要に応じて）SSID判定やAP判定 | EAPの種類 = Smart Card またはその他の証明書（EAP‑TLS） 暗号強度など必要な制約 | VLAN AのTunnel属性 |
| 低 | WiFi-EAPTLS-Fallback-VLAN_B | NAS Port Type = Wireless – IEEE 802.11 （必要に応じて）SSID判定やAP判定 | EAPの種類 = EAP‑TLS | VLAN BのTunnel属性 |
ここでの設計思想は明快です。
- EAP‑TLSであることは「制約」で縛る（他方式を許可しない）
- グループ所属は「条件」で判定する（合致したら上位ポリシーに一致）
- 一致しない端末も「認証自体は通す」なら、下位ポリシーで受ける
NPSの具体的な設定手順（最小構成）
ここでは、Windows ServerのNPSを想定した“実装の流れ”を、なるべく迷わない順番で記載します。環境により画面名が多少異なることがありますが、考え方は共通です。
NPSをADに登録し、参照できる状態にする
- NPSサーバをドメインに参加させる（一般的には必須）
- NPSコンソールで 「Active Directoryにサーバを登録」 を実行する
- グループ条件で参照したいADグループ（コンピューターグループ）を用意する
この工程が抜けると、NPSがADグループ条件を評価できず、意図したポリシーに一致しない原因になります。
RADIUSクライアント（AP/WLC/スイッチ）を登録する
- NPSコンソールでRADIUSクライアントを追加
- IPアドレス/名前/共有シークレットを設定
- 必要に応じて「ベンダー名」を指定（基本はRADIUS標準でOK）
共有シークレット不一致は、後述の検証フェーズで「そもそもNPSに届いていない」ように見える典型原因です。最初にここを堅くします。
ネットワークポリシー（VLAN A）を作成する
まずは“両方成立”の上位ポリシーから作ります。
- 新規ネットワークポリシーを作成（例：WiFi-EAPTLS-Group-VLAN_A）
- 条件（Conditions）に以下を設定
- NAS Port Type：Wireless – IEEE 802.11（Wi‑Fiに限定する場合）
- Windows グループ：対象のADコンピューターグループ
- （必要に応じて）Called-Station-ID（SSID判定）やNAS Identifier（拠点/AP群判定）
- 制約（Constraints）→ 認証方法で、「Microsoft: スマートカードまたはその他の証明書」（EAP‑TLS）を有効化
- 設定（Settings）→ RADIUS属性でVLAN属性を追加
VLAN割り当てに使うRADIUS属性（標準属性）
多くの機器は、以下の3つ（Tunnel属性）でVLANを受け取れます。NPSの「標準」属性として追加するのが分かりやすいです。
| 属性名 | 一般的な値 | 意味 | 注意 |
|---|---|---|---|
| Tunnel-Type | VLAN（数値なら13） | トンネル種別（VLAN） | 機器によっては数値指定が必要 |
| Tunnel-Medium-Type | 802（数値なら6） | 媒体（802系） | 無線でも指定するのが一般的 |
| Tunnel-Pvt-Group-ID | VLAN ID（例：10 / 20） | 割り当てるVLAN番号 | 文字列扱いのため、機器要件に合わせる |
加えて、環境によってはFilter-Idを使う設計（ACL名を返す等）もあります。まずは標準のTunnel属性で動作確認し、必要になったら段階的に拡張するのが安全です。
ネットワークポリシー（VLAN B：フォールバック）を作成する
次に“証明書だけOK”の下位ポリシーを作ります。
- 新規ネットワークポリシーを作成（例：WiFi-EAPTLS-Fallback-VLAN_B）
- 条件は、基本的にVLAN Aと同等（NAS Port TypeやSSID判定など）だが、Windows グループ条件は入れない
- 制約は同様にEAP‑TLSのみ許可
- 設定でVLAN BのTunnel属性を返す
ポリシー順序を必ず確認する
最後に、ネットワークポリシー一覧でVLAN A（グループ条件あり）が上、VLAN B（フォールバック）が下になるように順序を調整します。これが逆だと、グループ条件のポリシーに到達せず、常にVLAN Bが適用されます。
ADコンピューターグループを条件にする際の落とし穴
“設計としては合っているのに動かない”場合、原因の多くはここに集中します。
コンピューターグループの基本：入れるのは「コンピューターアカウント」
- ADのグループはセキュリティグループを使う（配布グループは不可）
- メンバーに入れるのはユーザーではなくコンピューター
- 管理画面では「PC名」でも選べますが、内部的にはコンピューターアカウント（末尾に$が付く主体）として扱われます
「AAD参加のみ端末」＋「ダミーのADコンピューターオブジェクト」で成立させる条件
相談例のように“参照用のADコンピューターオブジェクト”で運用する場合、少なくとも次の3点の整合性が必要です。
| 整合性の観点 | 何と何を合わせるか | ズレた時の症状 |
|---|---|---|
| 端末識別子 | 端末がEAPで提示するID（例：host/端末名）と、AD側で参照されるコンピューターオブジェクト | グループ条件に一致せず、常にフォールバックへ落ちる |
| 証明書の名前 | クライアント証明書のSubject/SAN（DNS名等）と、想定する端末名 | 認証成功しても“別端末扱い”になり運用が破綻 |
| 運用の更新 | 端末追加・廃止・再発行のたびに、ADオブジェクトとグループを更新 | 新端末だけVLANが合わない／廃止端末が残る |
この方式は、構成として成立させられる一方で、「ADが“端末台帳”の役割を持つ」ことになります。台帳運用が崩れると、意図しない端末がVLAN Aへ入る、または正規端末がVLAN Bへ落ちる、という形で事故が起きます。運用設計（登録フロー・棚卸し・失効/削除）が重要です。
グループ変更が反映されないように見えるとき
グループへ端末を追加した直後に反映されない場合は、次を疑います。
- ドメインコントローラ間のレプリケーション遅延（特に複数拠点）
- NPSが参照しているDCが想定と違う
- 認証ログ上は「別の主体」で評価されている（ユーザー認証として見られている等）
まずはNPSのログで「誰として評価されたか」を見て、グループ判定が正しい主体に対して行われているかを確認します。
検証とトラブルシューティングの実務テクニック
最初は「認証成功」と「ポリシー一致」を分けて確認する
いきなり「VLANが想定と違う」を追うと沼にハマりやすいです。次の順番で切り分けると速いです。
- EAP‑TLSで認証が成功しているか（まず接続できるか）
- どのネットワークポリシーに一致したか（VLAN AなのかBなのか）
- 返したRADIUS属性をAP/WLCが解釈しているか（機器側の設定/対応）
NPSログで“どのポリシーが適用されたか”を見る
NPSは、許可/拒否の記録に加えて、適用したネットワークポリシー名が確認できます。運用では以下のどちらか（または両方）を有効化しておくと便利です。
- イベントビューア（Network Policy and Access Servicesのログ）
- NPSのアカウンティング（テキストログ：IAS形式）
特に“VLAN AのつもりがBになる”場合、ほぼ確実に「上位ポリシーに一致していない」ので、ログで一致判定を見れば原因の方向性が決まります。
よくある原因と対処
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| 認証が通らない | 証明書チェーン/失効確認（CRL）が失敗、EKU不足、サーバ証明書不一致 | 端末側のサーバ証明書検証条件、NPS側の信頼/失効到達性、証明書テンプレートを確認 |
| 常にフォールバック（VLAN B）になる | ADグループ条件に一致していない、ポリシー順序が逆、主体がユーザーとして評価されている | ポリシー順序を上位へ、ログで評価主体と一致ポリシー名を確認、グループメンバーを見直す |
| RADIUSはVLANを返しているのにVLANが変わらない | AP/WLC側でDynamic VLAN/AAA overrideが無効、属性形式が機器要件と違う | 機器側の設定と、必要ならVSAの有無を確認。まず標準Tunnel属性を正しく返せているか確認 |
| 端末によって挙動が不安定 | 証明書更新/再発行で識別子がズレた、ダミーADオブジェクト運用が追いついていない | 証明書の命名規則を固定し、AD台帳（オブジェクト/グループ）更新フローを整備 |
運用設計のコツ：セキュリティと保守性を落とさないために
“証明書さえあればOK”にしない工夫
EAP‑TLSは強力ですが、裏を返すと「証明書（秘密鍵）の管理」がすべてです。現場で事故が起きやすいのは、次のようなケースです。
- 端末から秘密鍵がエクスポート可能で、別端末へ持ち出される
- 失効確認ができない（CRLへ到達できず、失効済みでも通る運用になっている）
- 証明書の棚卸しがなく、退職/廃棄端末の証明書が残り続ける
対策としては、鍵の保護（TPM/エクスポート不可）、失効確認の到達性確保、短めの有効期限＋自動更新、そしてADグループによる“第2のゲート”（今回の主題）が効きます。
グループでの許可運用を「作業フロー」に落とす
「ADコンピューターグループに入っている端末だけVLAN A」という設計は、実は運用がシンプルです。重要なのは、属人的にしないことです。例えば次のように決めておくと、後で揉めません。
- 端末追加：証明書配布 → ADオブジェクト確認/作成 → グループ追加 → 接続試験
- 端末廃止：グループ削除 → 証明書失効（必要なら）→ 棚卸し反映
- 例外対応：期限付きで別グループ（例：WiFi-Temp-Allow）に入れる
ポリシーが増える時の設計パターン
「部門ごとにVLANが違う」「拠点ごとにVLANが違う」など、要件が増えるとポリシーも増えます。その場合は、次のパターンが管理しやすいです。
- 最上位：厳格（EAP‑TLS＋グループ＋SSID/拠点条件）→ VLAN（部門/拠点）
- 中位：EAP‑TLSのみ（SSID/拠点条件）→ 制限VLAN
- 最下位：それ以外は拒否（もしくは別SSIDへ誘導）
命名規則も重要です。ポリシー名に「SSID」「認証方式」「グループ」「VLAN」を入れると、ログ解析が段違いに楽になります（例：WiFi-SSID1-EAPTLS-GroupX-VLAN10）。
ユーザー認証へ切り替える話は“別問題”として切り分ける
802.1Xの現場では「端末認証（マシン認証）でつないだ後、ユーザーサインインに合わせてユーザー認証へ切り替えたい」「ユーザーが切り替わったらVLANも変えたい」という要望が出がちです。
ただし、このテーマは“再認証のタイミングと、端末/無線機器の挙動”が絡むため、単純にNPSポリシーを増やしただけでは期待通りに動かないケースがあります（NICの再接続や再認証イベントが必要になるなど）。本記事の主題は「端末のみ認証（証明書）＋端末グループでの振り分け」なので、まずはここを安定させ、ユーザー単位の制御が必要になったら別設計（SSID分離、認証方式の再検討、機器側機能の活用など）として扱うのが安全です。
よくある質問
証明書認証が成功していれば、必ずVLAN Aにできますか？
できますが、推奨しません。証明書だけでVLAN Aにすると「証明書を持っている端末＝社内端末」と同一視することになり、鍵管理が崩れた時の影響が大きくなります。証明書＋ADグループの2段階にすると、運用で“許可端末”をコントロールできます。
ユーザーグループ条件で同じことはできますか？
可能です。NPSの条件はユーザーグループにも使えます。ただしユーザー認証に寄せるほど、端末起動時やサインイン前後の挙動（いつ誰として認証されるか）が複雑になります。まずは端末単位で安定させるのが近道です。
VLAN A/Bだけでなく、A/B/C…と増やせますか？
増やせます。やり方は同じで、最も厳しい条件を上に、緩い条件を下に並べます。例えば「Group-Admin → VLAN 10」「Group-Dev → VLAN 20」「それ以外 → VLAN 30」といった形です。
まとめ：実装の勘所は「EAP‑TLSを制約で固定」＋「グループ条件を上位ポリシーに置く」
「NPSで証明書認証できていること」と「ADコンピューターグループ所属」を“両方満たしたときだけ”VLANを割り当てたい場合、NPSのネットワークポリシーを2段構え（上位＝両方、下位＝証明書のみ）にするのが最も分かりやすく、運用もしやすい方法です。
特に、Azure AD参加のみ端末でこの構成を成立させるには、AD側で参照可能なコンピューターオブジェクトをどう持つかが成否を分けます。ダミー運用を選ぶなら、証明書命名規則とAD台帳運用を固め、ログで「どのポリシーに一致したか」を追える状態にしておくと、長期運用でも破綻しにくくなります。
コメント