Windows Server 2019のNPS(Network Policy Server)にMerakiアクセスポイント約300台をRADIUSクライアントとして登録したい——そんなときに気になるのがStandard/Datacenterで台数制限があるのか、そして現実的な一括登録手段です。本記事では調査の結論と、運用で使える手順・注意点をまとめます。
まず整理：一括で増やしたいのは「ポリシー」か「RADIUSクライアント」か
NPSの運用で混乱しやすいのが、「ネットワークポリシーを大量に作りたい」のか、「RADIUSクライアント（認証要求を投げてくる機器＝APやスイッチなど）を大量に登録したい」のかが、話の途中で混ざってしまう点です。300台規模のMeraki APで詰まりやすいのは、ほとんどの場合後者（RADIUSクライアント登録）です。
| やりたいこと | NPS上の対象 | 増える単位 | 典型的な増やし方 | よくある勘違い |
|---|---|---|---|---|
| APを登録して認証要求を受けたい | RADIUSクライアント | APごと（または送信元IPごと） | APのIPと共有シークレットを登録 | 「APごとにポリシーが必要」と思い込む |
| どのユーザー/端末に許可するか決めたい | ネットワークポリシー | 運用ルールごと | ADグループ・EAP方式・NAS条件で設計 | 「AP台数=ポリシー数」と比例させる |
| 認証要求の振り分けをしたい | 接続要求ポリシー | 経路/用途ごと | プロキシ有無、宛先、クライアント条件で設計 | ネットワークポリシーだけで全部できると思う |
記事の後半では、主に「AP（機器）とIP/MAC等を大量に扱いたい」ケース、つまりRADIUSクライアント登録の一括化にフォーカスして解説します。
Windows Server 2019のNPSに「Standard/Datacenterで台数制限」はあるのか
結論から言うと、Windows Server 2019のNPSについて、Standard/DatacenterでRADIUSクライアント数（AP台数）に上限がある／ないを断定できる公式情報を見つけにくいのが実情です。過去のWindows Server世代では「Standardは台数制限があり、上位Editionは制限なし」という体験談が語られることがありますが、2019ではEnterprise Editionが存在せず、Standard/Datacenterの二択になります。
そのため、実務としては次のスタンスが安全です。
- Edition差で“登録できない”前提で設計しない（=Datacenter必須と決め打ちしない）
- ただし導入前にラボで検証し、少なくとも想定台数（例：300台）を登録して運用できることを確認する
- 検証では「登録できるか」だけでなく、認証ログ、応答遅延、バックアップ/復旧手順まで一通り見る
もし「台数制限があるのでは？」と疑う状況に直面したら、まずは“上限”を探すより先に、エラーの種類を切り分けるのが近道です。例えば、RADIUSクライアント未登録（送信元IPが一致しない）、共有シークレット不一致、ポリシー条件不一致などは、台数制限と関係なく起きます。
検証のやり方（失敗しにくい手順）
- 検証用のNPSサーバー（できれば本番と同一OS/同一パッチレベル）を用意する
- APを数台だけ登録して疎通を取り、構成の正しさを先に確定させる
- 一括登録で300台相当まで増やし、NPS管理コンソール上で正しく表示されるか確認する
- 実際にAPからの802.1X認証（またはMAC認証）を複数拠点/複数SSIDで試し、ログが想定通り出るか確認する
- バックアップ→復旧（ロールバック）を一度通して、事故時に戻せる状態を作る
現実的な一括登録：NPS構成をXMLでエクスポート→編集→インポート
NPSはGUIでの設定が中心で、数百台のRADIUSクライアントを手作業で追加するのは現実的ではありません。そこで有効なのが、NPS構成をXMLとしてエクスポートし、必要な定義をまとめて追加してからインポートする方法です。
ポイントは、NPSに「大量生成専用の決定打となるCLIが見当たりにくい」一方で、設定の移行・復旧を目的とした“丸ごと”の入出力が用意されている点です。これを一括登録に転用します。
基本コマンド（PowerShell）
まずは現状のNPS構成をファイルに退避します。
Export-NpsConfiguration -Path "NPSConfig.xml"編集後にインポートして反映します。
Import-NpsConfiguration -Path "NPSConfig.xml"重要：インポートは「差分反映」ではなく、構成全体に影響する可能性があります。作業前にバックアップ、検証環境でのリハーサル、そしてロールバック手順（元のXMLを戻す）を必ず用意してください。
おすすめの進め方（“テンプレを作って増やす”）
- NPSにRADIUSクライアントを1件だけ手作業で作成する（例：AP-000のIPと共有シークレット）
- ExportでXMLを出力し、XML内でその1件がどのように表現されているか確認する
- その定義をテンプレートとして複製し、IP・名称・共有シークレット等を差し替えて件数分作る
- Importで反映し、NPSコンソール上で件数・内容が合っているか確認する
XMLの構造は環境や設定内容によって異なるため、以下はあくまでイメージです。
<!-- 例：RADIUSクライアント定義（実際のタグ名は環境で確認） -->
<RadiusClients>
<Client Name="AP-001" Address="10.0.10.11" SharedSecret="********" />
<Client Name="AP-002" Address="10.0.10.12" SharedSecret="********" />
</RadiusClients>CSVを元に“設定をコード化”すると運用が安定する
300台を一度登録して終わりではなく、増設・交換・拠点追加で継続的に更新が発生します。おすすめは、AP一覧をCSVで持ち、そこからXML編集の素材を自動生成する運用です。
| 列名の例 | 内容 | 例 | 備考 |
|---|---|---|---|
| FriendlyName | NPS上の表示名 | TOKYO-03F-MR46-01 | 拠点/階/機種/連番などで命名すると検索が早い |
| IPAddress | APの送信元IP | 10.20.30.41 | NPSは送信元IP一致が重要（NATが入るとズレる） |
| SharedSecret | 共有シークレット | ランダム文字列 | 可能ならAPごとにユニーク、難しければ拠点単位でも可 |
| Vendor | ベンダー種別 | RADIUS Standard | 通常は標準で問題なし |
このCSVを“正”とし、NPSの設定はXMLに反映して管理すると、作業者が変わってもブレにくくなります。XMLはファイルなので、Git等で差分管理しやすいのもメリットです。
「APを300台登録」が本当に必要かを一度だけ見直す
MerakiのようにAPが直接RADIUS要求を送る構成では、NPS側でAP台数分のRADIUSクライアント登録が必要になりがちです。ただし設計次第では、“NPSが見る送信元IP”を集約して登録件数を減らせる場合があります。
- RADIUSプロキシを挟む：拠点内にRADIUSプロキシ（またはコントローラー相当）を置き、NPSから見たクライアントを少数にする
- NAT/中継点で送信元が一本化される：意図せずNATされるケースもあるので、どのIPでNPSに到達しているかを必ず確認する
- 拠点単位でRADIUSサーバーを分ける：大規模環境では拠点ごとにNPSを置き、運用と障害影響を分割する
ここで重要なのは「件数を減らすこと」そのものではなく、運用負荷・セキュリティ・障害影響のバランスです。例えば送信元を集約するとNPS側は楽になりますが、共有シークレットの漏えい時の影響が大きくなることがあります。
共有シークレット設計：ユニークにするか、まとめるか
RADIUSクライアント登録が大量になると、共有シークレットの管理が次のボトルネックになります。セキュリティと運用の落としどころを、最初に決めておくと後で苦労しません。
| 方式 | セキュリティ | 運用負荷 | 向いているケース | 注意点 |
|---|---|---|---|---|
| APごとにユニーク | 高い | 高い | 拠点/台数が多く、漏えいリスクを最小化したい | 一括登録（CSV→XML）がほぼ必須になる |
| 拠点ごとに共通 | 中 | 中 | 拠点ごとに担当が分かれ、保守を簡素にしたい | 拠点内のどれか1台で漏えいすると拠点全体が影響 |
| 全APで共通 | 低い | 低い | 短期で仮設、または検証環境 | 漏えい時の影響が最大。監査でも指摘されやすい |
実務では「APごとユニーク」か「拠点ごと共通」が多い印象です。いずれにしても、共有シークレットは長く・ランダム・使い回さないが基本で、保管はパスワードマネージャー等に寄せるのが安全です。
ネットワークポリシーは“増やさない設計”が基本
「APが300台あるから、ポリシーも300本必要？」と悩む方もいますが、通常はそうなりません。無線802.1XのNPS設計は、むしろポリシーを少数精鋭にして条件で分けるほうが安定します。
- 社員端末（EAP-TLS）とBYOD（PEAP/MS-CHAPv2）で分ける
- 許可/拒否をADグループで分ける（例：WiFi-Allow）
- 時間帯や端末条件（NAP等）で追加制御する
AP単位の例外が必要になった場合も、まずは「SSID」「NAS Identifier」「Called-Station-ID」「拠点の送信元IP帯」など、条件でまとめられないかを検討してから、最小限の追加ポリシーに留めるのがおすすめです。
一括登録を安全にするチェックリスト
XMLでの入出力は強力ですが、誤編集の影響範囲が大きいのがデメリットです。作業を“手順化”して事故を防ぎましょう。
| フェーズ | チェック項目 | 目的 |
|---|---|---|
| 事前 | 現在のNPS構成をExportして別媒体に退避 | いつでも元に戻せるようにする |
| 事前 | 変更対象（AP一覧CSV、IP、共有シークレット）を確定 | 手戻りと漏れを減らす |
| 検証 | ラボでImport→疎通→ログ確認を一通り実施 | 本番での失敗を潰す |
| 本番 | メンテナンス時間を確保し、影響範囲を周知 | ユーザー影響を最小化 |
| 本番 | Import後にNPSログ（成功/失敗）を監視 | “動いているつもり”を防ぐ |
| ロールバック | 元のXMLをImportして復旧できることを確認 | 事故時に復帰できる |
MACアドレスを“登録したい”と言われたときの整理
やり取りの途中で「APの登録」と「MACアドレスの登録」が混ざることがあります。ここも混同しやすいポイントなので、先に整理しておきます。
- AP（RADIUSクライアント）登録：NPSが認証要求を受け付けるための“送信元装置”の登録です。基本は送信元IPアドレスと共有シークレットで管理します。
- クライアント端末のMACアドレス管理：いわゆるMAC認証（MAB）のように、端末のMACで許可/拒否したい場合の話です。これはRADIUSクライアント登録とは別で、ポリシー条件や外部データベースの設計が論点になります。
特に注意したいのは、RADIUSクライアントを「APのMACアドレスで登録する」という発想です。L2（同一セグメント）ならともかく、通常RADIUSはL3を跨いで到達するため、サーバー側が“送信元MAC”を見て判定することはできません。NPSでのクライアント判定は、基本的に送信元IPに依存します。
一方で、RADIUSパケットの属性（例：Called-Station-ID、NAS-Identifier、NAS-IP-Addressなど）には、APやSSID、BSSID（AP側MACに近い情報）が含まれることがあります。「どのAP/SSIDから来た要求かでポリシーを分けたい」場合は、まずNPSのログ（またはRADIUSのパケットキャプチャ）で実際に入ってくる属性を確認し、条件として使える形に落とし込むのが現実的です（ベンダーや設定で形式が変わるため、想像で決め打ちしないのがコツです）。
よくある詰まりポイントと切り分け
「台数制限かも？」と感じたとき、実は設定の不一致が原因というケースが多いです。代表例を押さえておくと、切り分けが早くなります。
RADIUSクライアントが一致していない
- NPSは基本的に送信元IPでRADIUSクライアントを判定します
- AP側のIP（管理IP）と、NPSが受け取る送信元IPが一致しているか確認します
- 途中にNATや中継装置があると、想定と違うIPで到達することがあります
共有シークレット不一致
- AP側設定とNPS側設定のシークレットが一致しているか確認します
- 一括作成時に、CSVの改行や余計なスペースが混ざると失敗します
ポリシー条件の不一致
- 接続要求ポリシー／ネットワークポリシーの順序と条件で拒否されることがあります
- 「認証方法（EAP）」と「ユーザー/コンピューターのグループ」が噛み合っているか確認します
まとめ：Edition差の“噂”より、検証と一括運用の仕組み作りが勝ち筋
Windows Server 2019のNPSで、Standard/Datacenterによる明確な台数制限を断定できない状況では、Datacenterに寄せるよりも、一括登録できる運用を作り、検証で安全を担保するのが最短ルートです。
- 大量のAP登録は、XML Export/Importで“設定を扱える形”にする
- AP一覧をCSVで管理し、変更を再現可能にする（属人化しない）
- 本番反映前に、想定台数・疎通・ログ・復旧までラボで通す
この流れを一度作ってしまえば、300台でも500台でも「増やせるか」ではなく「どう増やすか」に集中できます。NPSは“設定運用”で差が出る製品なので、初回の設計と手順化に時間をかける価値があります。
コメント