MENU

NPS（RADIUS）でSSID別に社内LANとゲストWi‑Fiを分離する方法｜Meraki＋ADで1台運用

ネットワーク

社内SSIDとゲストSSIDを同じNPS（RADIUS）で認証しつつ、社内LANへ入れる人とインターネットだけの人を分けたい──Meraki導入時によく出る要件です。本記事では、VLAN/ACLによるネットワーク分離と、NPSのポリシー（Called Station ID・ADグループ）でSSIDごとに制御する手順を、運用のコツまで含めて整理します。

目次

結論：同一NPSでSSID別のアクセス範囲を分けられる

NPS（Network Policy Server）は「認証できるか」「どんな属性（VLANなど）を返すか」を判断する役割で、実際に社内LANへ到達できるかどうかはネットワーク（VLAN/ルーティング/ACL/Firewall）の設計が決め手です。したがって、ネットワーク側で社内用とゲスト用を分離し、NPS側でSSIDやADグループにより認証可否・付与属性を分岐させれば、NPSを1台のまま安全に要件を満たせます。

実現の基本方針

  • 分離の本体：社内VLANとゲストVLANを分け、ゲストVLANはFW/ACLで「インターネットのみ」に制限する
  • 認証の入口：両SSIDともWPA2/WPA3-Enterprise（802.1X）＋RADIUSでNPSへ認証要求を送る
  • 許可の判定：NPSのネットワークポリシーで「どのSSIDから来た認証か」「どのADグループか」を条件にして許可/拒否する

まず押さえる：NPSだけで“アクセス範囲”は完結しない

「NPSで社内LAN可／不可を分ける」という言い方はよくありますが、厳密には役割分担が違います。NPSはRADIUSサーバーなので、やれることは大きく次の2つです。

  • 認証（Authentication）：ID/パスワード、証明書などで本人確認を行う
  • 認可（Authorization）：許可/拒否、VLANなどのRADIUS属性を返す

一方で、社内サーバーへ到達できるか、プリンタへ行けるか、管理ネットワークへ行けるか、といった到達性はVLANとFW/ACLで決まります。よって設計は「ネットワーク分離＋NPSポリシー分岐」のセットが基本になります。

構成イメージ：Meraki＋NPS＋ADの最小モデル

最も分かりやすいのは「SSIDごとにVLANを固定割り当て」し、そのうえでNPSがSSIDとグループを見て許可/拒否する方式です。

[端末] --(SSID:Corp / SSID:Guest)--> [Meraki MR]
   |                                  |
   | 802.1X(EAP)                      | RADIUS(UDP/1812,1813)
   v                                  v
[認証情報]                        [NPS(AD連携)]
                                      |
                                      v
                                   [AD DS]
要素社内SSID（例：Corp）ゲストSSID（例：Guest）
認証方式WPA2/WPA3-Enterprise（802.1X）WPA2/WPA3-Enterprise（802.1X）
認証基盤NPS＋AD（WiFi-Staffグループ）NPS＋AD（WiFi-Guestグループ）
VLAN社内VLAN（例：VLAN10）ゲストVLAN（例：VLAN20）
到達範囲社内LAN＋必要に応じてインターネットインターネットのみ（社内は遮断）
運用ポイント端末証明書（EAP-TLS）を検討すると強固アカウント期限・ログ保管・利用者追跡を重視

設計パターン：固定VLANか、動的VLANか

SSID別の分離は、実装として大きく2パターンあります。どちらも「NPSは1台」で実現できますが、運用やトラブルの出方が変わります。

パターン概要メリット注意点
SSIDごとにVLAN固定Meraki側でSSID→VLANを固定紐付け分かりやすい／原因切り分けが容易／設計が安定同一SSID内で利用者ごとにVLANを分けたい場合は不向き
NPSで動的VLAN割り当てNPSがRADIUS属性でVLAN IDを返す（Merakiが受け入れる設定が必要）同一SSIDでもグループ別にVLANを変えられる／SSID増殖を防げる機器側対応・設定箇所が増える／トラブル時に見落としが増えがち

「社内SSID／ゲストSSIDの2つで分けたい」だけなら、まずはSSIDごとにVLAN固定が最短で堅牢です。将来「同じSSIDで外部委託だけ別VLAN」などが出てきたら、動的VLANを追加検討すると失敗しにくいです。

ネットワーク分離の作り方：ゲストは“インターネットのみ”をネットワークで担保する

ゲストSSIDを安全にするコツは、「認証」だけに頼らず、ゲストVLAN自体が社内へ行けない状態をネットワークで作ることです。ADにゲストユーザーを作成しても、もし端末が感染していたら社内へ横展開されるリスクがあります。これをVLANとFWで論理的に止めます。

推奨するゲストVLANの制御例

制御項目推奨理由
社内向けRFC1918宛通信原則ブロック横展開・情報漏えいの入口を塞ぐ
DNSゲスト専用DNS（外部/プロバイダ/社内DMZ）へ限定内部DNSを叩かせない（内部名解決の漏えい対策）
DHCPゲストVLAN内で完結（Meraki DHCPまたはDHCPサーバー）社内DHCPに依存させない
管理系（SNMP/SSH/RDPなど）ブロック管理面の侵害リスクを下げる
必要な例外会議室の無線共有機器など、必要最小限だけ許可例外は必ず根拠と期限を持たせる

Meraki環境では、SSIDのファイアウォール（L3/L7）や上位FW/ルータのACLで実現します。特に「インターネットのみ」は、“社内への到達経路を全部塞ぐ”発想が重要です。

Meraki側の設定ポイント：SSIDを分け、RADIUSを同じNPSへ向ける

Meraki MRはクラウド管理ですが、802.1XのRADIUS通信自体はAPとNPS間で行われます。したがって、APからNPSへUDP/1812（認証）・1813（アカウンティング）を到達可能にしておきます（環境により1645/1646を使う場合もありますが、基本は1812/1813です）。

設定の流れ（イメージ）

  1. SSIDを2つ作成：Corp（社内用）／Guest（ゲスト用）
  2. 両SSIDの認証方式：WPA2/WPA3-Enterprise（RADIUS）を選択し、RADIUSサーバーにNPSのIPと共有シークレットを設定
  3. VLANの割り当て：
    • Corp SSIDは社内VLAN（例：10）へブリッジ
    • Guest SSIDはゲストVLAN（例：20）へブリッジ、またはNATモードを採用（設計方針に合わせる）
  4. 上位スイッチ：AP接続ポートをトランクにし、必要なVLAN（10/20など）を許可
  5. ゲスト制御：MerakiのSSIDファイアウォールまたは上位FWで社内宛を遮断

「NPSのポリシー分岐」は、この時点ではまだ作りません。まずはMerakiからNPSへ認証要求が届き、ログでSSID判別に使える属性（Called Station IDなど）が見える状態を作るのが近道です。

NPS側の設定手順：SSIDとADグループでポリシーを分ける

ここからが本題です。NPSは1台のままで、ネットワークポリシー（Network Policy）を複数作り、条件と優先度で分岐させます。

事前準備チェック

  • NPSをADドメイン参加させ、NPSをActive Directoryに登録しておく（NPSコンソールから実施）
  • PEAP/EAP-TLSを使うなら、NPSサーバー証明書を用意（社内CAまたは信頼された証明書）
  • 時刻同期（NTP）を正しく（証明書認証の失敗原因の定番）

RADIUSクライアント（Meraki AP）の登録

NPSは「誰からのRADIUS要求を受けるか」をRADIUSクライアントで管理します。Merakiでは、基本的にAP（MR）の管理IPからNPSへRADIUS要求が飛ぶため、NPSにAPを登録します。

  • RADIUSクライアント名：サイト名＋AP名など運用で追える命名にする
  • アドレス：APのIP
  • 共有シークレット：Meraki側で設定したものと一致させる（長くランダム推奨）

AD側のグループ設計

「野良ゲストを避けたい」「ゲストもADに作って認証させたい」要件では、ADグループの分離が効きます。最低限、次の2グループを用意します。

グループ名（例）対象ポイント
WiFi-Staff社員・常駐など社内LANに入れてよい利用者可能なら端末証明書（EAP-TLS）も併用して強度を上げる
WiFi-Guest来訪者・短期利用者（インターネットのみ）アカウント期限を必須にし、棚卸しを運用に組み込む

「ゲストもADユーザー」は、発行/失効の運用がすべてです。作りっぱなしが最大のリスクになるため、後段で運用テンプレートも紹介します。

SSIDを見分ける代表的な条件：Called Station IDを使う

SSIDごとにポリシーを切り替えるとき、現場で最もよく使われるのがCalled Station IDです。多くの機器で「APのMACアドレス＋SSID」のような形式でRADIUS属性に入ります（表記はベンダー・ファームウェアで差が出ます）。

まずログで“実際の値”を確認する

Called Station IDは機器依存なので、いきなり条件に打ち込まず、次のどれかで確認してから条件を作るのが確実です。

  • NPSのイベントビューア（カスタムビュー → サーバーロール → ネットワーク ポリシーとアクセス サービス）
  • NPSのアカウンティング（テキストログ/SQL）でRADIUS属性を確認
  • 検証用端末で社内SSID/ゲストSSIDそれぞれに接続し、ログを比較する

ログに次のような差が見えたら、SSID判別ができます（例です）。

  • 社内SSID接続時：Called Station ID = AA-BB-CC-DD-EE-FF:Corp
  • ゲストSSID接続時：Called Station ID = AA-BB-CC-DD-EE-FF:Guest

NPSネットワークポリシーの作り方：許可ポリシーを2本作り、順序で分岐

NPSの肝は「ネットワークポリシーの順序（優先度）」です。上から順に評価され、最初に条件一致したポリシーが適用されます。意図しない“広い許可ポリシー”が上位にあると、ゲストが社内SSIDへ入れてしまう事故が起きます。

ポリシー設計の基本ルール

  • 具体的（条件が狭い）なポリシーを上に置く
  • 最後は「その他は拒否」になるように作る（暗黙拒否でもよいが、運用では明示拒否が分かりやすい）
  • SSID判別だけでなく、ADグループ条件を必ず併用する（SSID名が似ている、別拠点が増える、などで事故が起きやすい）

推奨のポリシー例

ポリシー名（例）条件（Conditions）結果狙い
Corp-SSID-AllowCalled Station ID が「Corp」を含む Windows グループ = WiFi-Staffアクセス許可（必要ならVLAN属性付与）社内SSIDはスタッフだけ
Guest-SSID-AllowCalled Station ID が「Guest」を含む Windows グループ = WiFi-Guestアクセス許可（ゲストVLANへ）ゲストSSIDはゲストだけ
WiFi-Default-DenyNAS Port Type = Wireless – IEEE 802.11（など無線を示す条件）アクセス拒否ポリシー漏れを確実に落とす

この構成にしておくと、たとえばゲストアカウントを持つ人が社内SSID「Corp」を選んでも、グループ条件で弾かれます。逆も同様です。SSIDとグループを二重化しているのが事故を防ぐポイントです。

動的VLANを使う場合：NPSからVLAN IDを返す（必要なRADIUS属性）

将来的に「同じSSIDで社内/外部委託を分けたい」「拠点ごとに社内SSIDのVLANを変えたい」などが出たら、NPSから動的VLANを返す設計が有効です。Meraki側でRADIUSからのVLAN指定を受け入れる設定（RADIUS override等）が必要になるため、対応可否は導入機種・設定方針で確認してください。

NPSで動的VLANを返すときに使う代表的な標準属性は次のとおりです。

属性名設定値の例意味
Tunnel-TypeVLANトンネル種別（VLAN指定）
Tunnel-Medium-Type802媒体種別（イーサネット系）
Tunnel-Private-Group-ID10 / 20VLAN ID（数値 or 文字列）

運用上は、「社内SSIDでも、実はVLANはNPSが返している」という状態になると現場が混乱しがちです。最初は固定VLANで安定させ、動的VLANは必要になってから段階的に導入すると失敗しにくいです。

ゲストをADで認証させる運用設計：作成と失効の仕組みがすべて

ゲストをADユーザーで認証させると、「誰がいつ使ったか」を追跡でき、オープンWi-Fiや共通パスワード方式より監査性が上がります。一方で、運用を雑にすると、使われないアカウントが残り続け、むしろリスクになります。ここは設計段階でルール化しておくのが安全です。

おすすめの運用ルール

  • 専用OUを作る：例）OU=WiFiGuests。棚卸しや一括無効化がしやすい
  • アカウント有効期限を必須：来訪日＋数日など、最初から期限を入れる
  • 命名規則：例）guest_会社名_YYYYMMDD_連番。後追い調査が楽になる
  • パスワードの配布経路を決める：口頭、紙、事前メールなど。スクリーンショット共有は避ける
  • ゲストは必ずWiFi-Guestに入れる：グループに入っていないと繋がらない設計にする

アカウント作成を標準化する（PowerShell例）

手作業で属性を入れ忘れる事故を減らすには、作成をテンプレ化するのが効果的です。以下は一例です（環境に合わせて読み替えてください）。

New-ADUser `
  -Name "guest_ABC_20251231_01" `
  -SamAccountName "guest_ABC_20251231_01" `
  -AccountPassword (Read-Host -AsSecureString "Password") `
  -Enabled $true `
  -Path "OU=WiFiGuests,DC=example,DC=local" `
  -AccountExpirationDate (Get-Date).AddDays(3)

Add-ADGroupMember -Identity "WiFi-Guest" -Members "guest_ABC_20251231_01"

“期限が切れたら自動で使えない”状態に寄せると、運用負担が一気に下がります。さらに強固にするなら、定期的に期限切れアカウントを無効化・削除するジョブを組み込みます。

セキュリティを一段上げるコツ：社内SSIDはEAP-TLSを検討する

ゲストは短期利用で「ID/パスワード（PEAP-MSCHAPv2）」になりがちですが、社内SSIDは中長期の利用者が多く、端末管理もできるケースが多いはずです。その場合、社内SSIDだけでもEAP-TLS（端末証明書）に寄せると、パスワード漏えい・フィッシング・使い回しのリスクを大幅に下げられます。

方式向いている対象強みハードル
PEAP（ID/パスワード）ゲスト、端末管理が難しい利用者導入が容易、既存AD資産を活用パスワード運用の質が安全性を左右
EAP-TLS（証明書）社員PC、管理対象端末なりすましに強い、パスワード漏えいに依存しない証明書配布（AD CS/MDMなど）の設計が必要

「まずはPEAPで開始 → 社内SSIDのみEAP-TLSへ移行」という段階導入が現実的です。SSIDを分けている構成は、段階移行とも相性が良いです。

トラブルシュート：ハマりどころと確認順

SSID別ポリシーは便利ですが、初期構築では“どこで詰まっているか”が見えにくくなります。以下の順で確認すると、遠回りしにくいです。

症状まず確認する箇所よくある原因対処の方向性
そもそも認証要求がNPSに来ないFW/ACL、UDP 1812/1813到達性経路未開通、NAT、誤IP、誤ポート疎通（ping/trace）とFWログ、Merakiイベント確認
共有シークレット不一致NPSのRADIUSクライアント設定コピペミス、APごとに別設定MerakiとNPSのシークレットを統一・再登録
社内SSIDなのにゲストが通るNPSポリシーの順序と条件広い許可ポリシーが上位、グループ条件がないSSID＋グループの二重条件、拒否ポリシー追加
Called Station ID条件が効かないNPSログの属性値表記揺れ、区切り文字違い、大文字小文字ログの実値に合わせて条件を作り直す
証明書エラーで接続できないNPS証明書、端末の信頼証明書期限、SAN不足、ルートCA未配布証明書更新、端末へルート配布、時刻同期

NPSログを“使える形”で残す

ゲストWi-FiをAD認証にする最大の価値は「追跡できる」ことです。NPSのアカウンティングを有効にし、次の情報が後から辿れる状態にしておくと、障害対応にも監査にも効きます。

  • 誰が（ユーザー名）
  • いつ（日時）
  • どこで（APやCalled Station ID、NAS IP）
  • 結果（許可/拒否、適用ポリシー）

ログの保管期間は、社内のセキュリティポリシーに合わせます。ゲストが絡む場合は短すぎると追跡できなくなるので注意してください。

実装テンプレート：最短で安全に動かすためのチェックリスト

最後に、現場でそのままタスク化しやすい形にまとめます。ここまでの内容をこの順で進めると、構築の手戻りが減ります。

  • ネットワーク設計：社内VLANとゲストVLANを決め、ゲストVLANの社内宛遮断（RFC1918ブロック）を先に設計する
  • Meraki：Corp/Guestの2SSIDを作り、両方をNPSへ向ける。SSID→VLANはまず固定で開始する
  • NPS：Meraki APをRADIUSクライアント登録し、テスト接続でログにSSID判別属性が出ることを確認する
  • AD：WiFi-Staff/WiFi-Guestを作り、ユーザーを必ずどちらかへ所属させる
  • NPSポリシー：Corp許可／Guest許可／Default拒否を作り、順序を必ず確認する
  • 運用：ゲストOU・命名規則・期限必須・定期棚卸し・ログ保管を最初から決める

この形にしておけば、NPSは1台のままでも、社内SSIDとゲストSSIDを安全に分離できます。ポイントは「SSID名で分ける」だけで終わらせず、VLAN/ACLで到達性を分離し、NPSポリシーで“許可される人”を絞り込むことです。ここまで作り込むと、ゲストにも認証を必須にしつつ、社内LANの安全性と運用性を両立できます。

ネットワーク
VLAN RADIUS NPS Meraki SSID

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次