特定のサーバー上でActive Directoryを用いた認証と、別サーバー上のユーザーをリモートRADIUSサーバーへ転送して認証する環境を同時に実現したい場面では、Windows ServerのNPS（Network Policy Server）を活用する構成が有効です。NPSはRADIUSサーバーとして機能するだけでなく、RADIUSプロキシとして外部RADIUSサーバーへ認証要求を転送する仕組みを備えており、これを正しく設定することで、ローカル（Active Directory）ユーザーとリモート（他サーバー）のユーザーが同一の無線LAN環境に接続できるようになります。本記事では、NPSを利用したリモートRADIUSプロキシ設定の手順や考慮点を、具体的な構成例やトラブルシューティングを交えつつ詳しく解説します。
NPSの役割とRADIUSプロキシ構成の基本
NPS（Network Policy Server）は、Windows Serverに標準で搭載されているRADIUSサーバー兼ポリシーサーバーです。ローカルのActive Directoryドメインユーザーに対する認証や、ネットワーク接続のポリシー適用が可能です。さらに、RADIUSプロキシとして動作させることで、受信した認証要求を別のRADIUSサーバーに転送できます。
このRADIUSプロキシ構成を利用すれば、一部のユーザーはローカルのActive Directoryで認証し、別のドメインや別サーバー上のユーザーは外部RADIUSサーバーに転送して認証するといった柔軟な仕組みを実現できます。
NPSが担う主な機能
NPSには大きく分けて、以下のような機能があります。
- RADIUSサーバー機能: 受信したRADIUSリクエストを自サーバーで認証し、ポリシーを適用する機能。
- RADIUSプロキシ機能: 受信したRADIUSリクエストを、別のRADIUSサーバー（リモートRADIUSサーバー）へ転送する機能。
- ポリシー管理機能: 「接続要求ポリシー（Connection Request Policy）」や「ネットワークポリシー（Network Policy）」を用いて、どのようにリクエストを処理するかを定義する。
ローカル認証とリモート認証を両立させるポイント
- 接続要求ポリシーの振り分け条件: どのようなユーザーやクライアントからの要求をローカル認証に回し、どのような要求をリモートRADIUSサーバーへ転送するかを細かく設定する必要があります。
- ネットワークポリシーの適切な構成: 接続要求ポリシーによって転送されなかったリクエストは、ローカルのネットワークポリシーで処理します。ここで承認/拒否の条件や認証方式を設定し、必要に応じてユーザーグループを指定します。
接続要求ポリシーとネットワークポリシーの関係
NPSの設定において要となるのが「接続要求ポリシー（Connection Request Policy）」と「ネットワークポリシー（Network Policy）」の使い分けです。認証の振り分けは多くの場合、接続要求ポリシーで実行され、実際の承認/拒否はネットワークポリシーで行われます。
以下はNPSがRADIUSリクエストを処理する流れの概要です。
- RADIUSリクエスト受信
ユーザーからの接続要求が、まずNPSに届きます。 - 接続要求ポリシーのマッチング
NPSは設定されている接続要求ポリシーを上から順番に評価し、条件に合致したポリシーを適用します。
- ポリシー内で「ローカルのNPSで処理する」または「リモートRADIUSサーバーへ転送する」などの動作を指定。
- ネットワークポリシーの評価
接続要求ポリシーで「ローカルのNPSで処理する」と判断された要求は、ネットワークポリシーへ進みます。ここで認証方式、許可するセキュリティグループ、NASポートの種類など、多様な条件を設定して承認・拒否を判断します。 - リモートRADIUSサーバーでの処理
接続要求ポリシーで「リモートRADIUSサーバーに転送する」と判断された要求は、あらかじめ設定したリモートRADIUSサーバーグループに送信されます。送信先のサーバー側でユーザー情報を照合し、認証が行われます。
ポリシー設計の注意点
- 複数ポリシーの順序: 接続要求ポリシーは上から評価されるので、複数のポリシーを使い分ける場合は優先度を慎重に設定します。
- ドメイン名やUPNを活用した分岐: 例えば、ユーザーが「user1@localdomain」と「user2@remotedomain」のように異なるドメイン名で認証を行うケースでは、UPNに含まれるドメイン名で条件を分けるのが一案です。
- クライアントのNAS属性で分岐: 同じSSIDを使っていても、NASポートタイプやCalling Station IDなどが異なる場合に応じて判別することも可能です。
リモートRADIUSサーバーへの転送設定
ローカルNPSがRADIUSプロキシとして機能する場合、「リモートRADIUSサーバーグループ」を作成しておき、それを接続要求ポリシーで呼び出す形をとります。
リモートRADIUSサーバーグループの作成
- NPS管理コンソールを起動
「サーバーマネージャー」から「ツール」→「ネットワーク ポリシー サーバー」を選択し、NPSコンソールを開きます。 - リモートRADIUSサーバーグループの追加
左ペインの「ポリシー」下にある「リモート RADIUS サーバー グループ」を右クリック→「新しいリモートRADIUSサーバーグループ」を選択。 - グループ名とサーバー情報の入力
作成するグループ名（例：「RemoteGroup1」など）を指定し、「追加」ボタンでリモート側のRADIUSサーバーのIPアドレスまたはFQDN、シークレットキー、ポート番号（通常1812/1813）を設定します。
接続要求ポリシーでの設定例
接続要求ポリシーで「リモートRADIUSサーバーに転送する」ように指示する場合、以下のような手順をとります。
- 新規接続要求ポリシーの作成
左ペインの「接続要求ポリシー」を右クリック→「新しいポリシー」を選択。 - 条件の設定
- 例えば、「User Name」に対して「@remotedomain」が含まれている場合にマッチするように条件を設定する。
- または「NAS Port Type = Wireless – IEEE 802.11」を条件に入れつつ、NAS IDで区別するなど、環境に応じて調整。
- 転送先の設定
「ネットワーク ポリシーおよびアクセス サービスの条件と設定」画面で「このNPSサーバーでの処理」か「リモートRADIUSサーバーグループへ転送」かを選択できます。リモートRADIUSサーバーグループを選択し、先ほど作成したグループ名を指定します。
サンプル接続要求ポリシー
以下のように、UPNのドメイン名で条件を分けて転送する例を示します。
ポリシー名: RemoteDomainForward
条件: ユーザー名 (User Name) - “@remotedomain” を含む
ネットワークへのアクセス許可: Grant Access
処理の場所: リモートRADIUSサーバーグループ (RemoteGroup1)このようなポリシーを作成しておくと、ユーザー名に「@remotedomain」が含まれる場合、NPSは即座に認証要求をリモートサーバーへ転送します。一方、条件に合致しないユーザー、つまりローカルADのドメイン名を使うユーザーは、このポリシーにはマッチせず、次の接続要求ポリシーが評価されます。
ローカル認証用ポリシーの設定
ローカルのActive Directoryで認証させるユーザーについては、別の接続要求ポリシーを設定するか、あるいはデフォルトで存在するポリシーを編集して利用します。
ここでは、新規に「LocalAuthPolicy」としてポリシーを作成する手順を例示します。
- 新規接続要求ポリシーを作成
「接続要求ポリシー」を右クリック→「新しいポリシー」。 - 条件の設定
- 「User Name」にローカルドメイン名（例：@localdomain）を含む
- あるいは特定のグループ（例：Domain Users）に属するユーザーなど
- 処理方法
- 「このNPSサーバーでの処理」を選択
こうすることで、@localdomainを含むUPNのユーザー名が来た場合は、ローカルのNPSで認証処理が走り、Active Directoryに対して資格情報を問い合わせます。
ネットワークポリシーの最適化
接続要求ポリシーによってローカル処理が決定されたリクエストは、続いてネットワークポリシーによって最終的なアクセス可否が判断されます。
- PEAPやEAP-TLSなどの認証方式: Wi-Fi認証にはPEAPやEAP-TLSなどが利用されることが多いため、ネットワークポリシーで「許可するEAPの種類」を設定します。
- グループ条件: ドメインのセキュリティグループを利用し、「Domain Users」「特定部署用グループ」などを許可・拒否に振り分ける場合は、ネットワークポリシーの条件に組み込みます。
サンプルネットワークポリシー
ポリシー名: LocalAD-WiFi-Policy
条件:
- Windows Groups: "DOMAIN\\Domain Users"
- NAS Port Type: "Wireless - IEEE 802.11"
- Authentication Type: EAP
ネットワークへのアクセス許可: Grant Access
EAPの種類: PEAP (EAP-MSCHAP v2)このように設定すると、無線LAN経由の接続要求でドメインユーザーがPEAPを利用する場合に、アクセスが許可されるという仕組みになります。
トラブルシューティングとログの活用
NPSの構成はポリシーの優先順位や条件設定の誤りで、認証要求が意図しないポリシーにマッチすることがあります。問題が発生した際には、以下のポイントをチェックしましょう。
イベントビューアーでのログ確認
- イベントビューアー → カスタムビュー → サーバーの役割 → Network Policy and Access Services
ここにNPSでの認証結果やエラーメッセージが表示されます。どのポリシーにマッチし、何が原因で失敗したかを把握できます。
NPSログファイルの解析
- 既定設定では、
%SystemRoot%\System32\LogFiles配下にNPSログが生成されます。 - ログにはクライアントのCalling-Station-ID（MACアドレスなど）や認証結果、マッチしたポリシーIDが記録されるため、詳細なトラブルシュートに役立ちます。
リモートRADIUSサーバー側の状況
- リモート先のRADIUSサーバーでも、同様にログを確認し問題なく要求を受け取って認証しているかをチェックします。
- シークレットキーの不一致やネットワーク経路（ファイアウォールやルーティング設定）の不備があると、NPSからのリクエストを受け取れない可能性があります。
設定のポイントと注意事項
複雑なポリシーを組む場合や環境が拡張される場合は、次の点に特に留意してください。
ドメイン構成とUPNの扱い
- Active Directoryを複数構成している場合、UPNサフィックスを統一するか、ユーザーがどのUPNを使うのか明確にする必要があります。
- リモートRADIUSサーバー側が別のドメインコントローラーと連携している場合、ユーザー名の書式を正しくしておかないと認証に失敗します。
シークレットキーとポート番号
- RADIUS通信にはシークレットキーが必須です。NPSとリモートRADIUSサーバー間で同じキーを設定し忘れると、認証要求が通りません。
- 既定では1812（認証）/1813（アカウンティング）や、古い互換設定では1645/1646を使用します。ファイアウォールなどでブロックされていないか確認しましょう。
優先順位の管理
- 接続要求ポリシーは複数作成すると混乱しやすいため、わかりやすい名前や正しい順序を設定します。
- 条件に合致しない要求が発生する場合、思わぬポリシーがマッチしないかログを細かく確認しましょう。
具体的な構成例: ローカルAD + リモート認証
ここでは、具体的な例として、ローカルドメインを「LOCALDOMAIN.LOCAL」、リモート側のドメインを「REMOTEDOMAIN.LOCAL」と仮定します。Windows Server 2016上のNPSで、以下のようなポリシーを設定します。
リモートRADIUSサーバーグループ設定
| 項目 | 設定例 |
|---|---|
| グループ名 | RemoteGroup_RemoteDomain |
| サーバー アドレス | 192.168.100.10 (remotenps.remotedomain.local) |
| シークレット | 同一の強固な文字列を設定 |
| 認証ポート | 1812 |
| アカウンティングポート | 1813 |
接続要求ポリシー1: RemoteDomain_Forward
- 条件: ユーザー名に「@remotedomain.local」が含まれる
- 処理方法: リモートRADIUSサーバーグループ「RemoteGroup_RemoteDomain」に転送
- アクセス許可: 承認（Grant Access）
接続要求ポリシー2: LocalDomain_Auth
- 条件: ユーザー名に「@localdomain.local」が含まれる、または条件を絞らない（デフォルトポリシー化）
- 処理方法: このNPSサーバーで処理
- アクセス許可: 承認（Grant Access）
ネットワークポリシー: LocalDomain_WiFi
- 条件: Windows Groups = 「LOCALDOMAIN\Domain Users」
- NASポートの種類: Wireless – IEEE 802.11
- 認証方式: PEAP（EAP-MSCHAP v2）
- アクセス許可: 承認
このような構成にすると、@remotedomain.localユーザーはリモートNPSへ転送され、@localdomain.localユーザーはローカルのNPSとActive Directoryで認証されます。
コード例: netshコマンドによる設定確認
GUIで設定するだけでなく、netsh npsコマンドを使用してNPS構成を確認・エクスポートすることも可能です。
以下に、NPSの現在の構成をエクスポートする例を示します。
netsh nps export filename="C:\npsconfig.xml" exportPSK=YESこれにより、接続要求ポリシー、ネットワークポリシー、リモートRADIUSサーバーグループなどを含むNPSの全設定がXMLファイルとして出力されます。バックアップや構成レビューの際に役立ちます。
運用時のベストプラクティス
最後に、運用上のベストプラクティスと注意点をまとめます。
段階的な導入テスト
- まずはシンプルなポリシー構成で、ローカルユーザーのWi-Fi認証のみが機能することを確認します。
- 次にリモートRADIUSサーバーへの転送ポリシーを追加し、リモートユーザーのみをテストする段階を設けます。
- 問題なく両方機能するのを確認したら、本番稼働へと進めると、トラブルを最小限に抑えられます。
ドキュメント化とポリシー管理
- ポリシーの数が増えると混乱しやすくなるため、設定内容や接続要求ポリシーの優先順位、転送先RADIUSサーバー情報をきちんとドキュメント化しておきましょう。
- シークレットキーの更新時期や手順も含め、定期的にチェックし、セキュリティを保つことが重要です。
冗長化構成
- 大規模環境や重要なインフラの場合、NPSサーバーとリモートRADIUSサーバーを冗長化することで、障害時でも認証サービスを止めないようにします。
- ロードバランサーやDNSラウンドロビンを活用し、複数のNPSサーバーを運用するケースもあります。
まとめ
Windows ServerのNPSをRADIUSプロキシとして活用すると、ローカルのActive Directoryユーザーと、リモートの別ドメインや別サーバーのユーザーを同時に運用する柔軟なWi-Fi環境が構築できます。接続要求ポリシーとネットワークポリシーを正しく設計し、どのユーザーがどこで認証されるかを明確にしたうえで、ログやイベントビューアーを活用したトラブルシュートを行うことが成功の鍵です。さらに、ポリシーの優先順位や詳細条件を整理し、運用ドキュメントを整えることで、将来的な拡張や変更にも対応しやすくなるでしょう。ぜひ本記事で紹介した手順とポイントを参考に、スムーズなNPS運用を実現してください。
コメント