複雑に思えがちなネットワーク認証の世界では、NPS（Network Policy Server）とMicrosoft Entra ID（旧Azure AD）の連携が注目を集めています。クラウドへの移行が進む中、「オンプレミスのADを介さずにRADIUS認証を完結できないか？」と悩まれる方も多いでしょう。本記事では、NPSとEntra IDの直接統合の現状や代替手段、将来の展望について詳しく解説します。
NPSとMicrosoft Entra IDとは
NPS（Network Policy Server）は、Windows Serverに含まれるRADIUSサーバー機能で、VPNやWi-Fiなどのネットワーク認証を一元管理する役割を担います。RADIUSは認証・認可・アカウンティング（AAA）を実現するプロトコルとして広く使われています。
一方、Microsoft Entra ID（旧称：Azure AD）は、Microsoftが提供するクラウドベースのディレクトリおよびID管理プラットフォームです。Office 365やTeamsなどのSaaSアプリケーションはもちろん、あらゆるクラウドリソースへのシングルサインオン（SSO）や多要素認証（MFA）を簡潔に行えることが特徴です。近年はオンプレミスのActive Directoryからの移行先としても注目されており、ハイブリッド構成や完全クラウド運用など、多様な形態に柔軟に対応できます。
NPSとEntra IDを結びつけたい背景
NPSが提供するRADIUS認証は、VPN接続や802.1XなどのWi-Fi環境を安全に運用するために欠かせない仕組みです。従来であれば、オンプレミスに設置したADドメインコントローラーをID情報の一次ソースとして用いつつ、NPSがRADIUSプロトコルを通じてユーザー認証を行うのが一般的な構成でした。しかし、クラウド移行を進める企業が増え、オンプレミスサーバーの撤廃や縮小化を目指す中、「Active Directoryを置かずに、クラウド（Microsoft Entra ID）だけでNPS認証できないか？」という要望が高まっています。
「NPSとEntra IDの直接統合」は可能なのか
結論からいうと、2025年2月現在、オンプレミスのADをまったく用いずにNPSをEntra IDと直接統合する公式の方法は提供されていません。NPS自身はWindows ServerのRADIUSサーバーとして古くから利用されている技術である一方、Entra IDはクラウドベースの最新のIDプラットフォームです。この両者を完全に直結するための仕組みやAPIは、Microsoft公式ドキュメントでは明示的にサポートされていない状況です。
NPS Extension for Microsoft Entra MFAの存在
NPSとAzure AD（Entra ID）を連携させるうえでよく利用されるのが「NPS Extension for Microsoft Entra MFA」（旧称：NPS Extension for Azure MFA）です。これを使うと、NPSを介した認証フローにMFAが導入され、クラウド上の多要素認証機能を利用できます。
しかし、この拡張機能を導入する際、ユーザー情報のドメイン参加チェックやグループ確認などを行うために、オンプレミスADが前提となるケースが少なくありません。拡張機能自体はMFAの問い合わせ先をクラウドに移すものの、ユーザーアカウントの一次ソースとしては依然としてオンプレミスのActive Directoryが必要になることが多いのです。
仕組みの概要
NPS Extension for Microsoft Entra MFAを導入した場合、認証フローは下記のようになります。
- クライアントがVPNやWi-Fiなどのネットワークに接続する際、RADIUSパケットがNPSに送信される。
- NPSはユーザーのドメインアカウントをActive Directoryで検証し、パスワードの正当性を確認。
- 同時に、NPS ExtensionがEntra ID側へMFAの要求を投げ、ユーザーの二要素目（電話、Authenticatorアプリ、メールなど）を確認。
- 二要素認証に成功すれば、NPSは最終的に「Accept」のRADIUSレスポンスを返し、クライアントの接続が許可される。
このように、NPSとクラウドのMFAは連携するものの、ユーザーのアイデンティティソースとしてオンプレミスADを利用する流れは変わりません。
完全なクラウドネイティブ運用が難しい理由
そもそもNPSは、Windows Server上にインストールされるRADIUSサーバー機能として長年進化を重ねてきました。しかし、その歴史的背景から「オンプレミスのActive Directoryでユーザー情報を管理し、NPSでRADIUS認証を実施する」という構成が基本設計となっています。
Microsoft Entra IDをIDソースにしたい場合は、本来ならOAuthやSAMLなどのモダンプロトコルでクラウド上の認証を完結させるのが理想的です。しかし、NPSがRADIUSプロトコルを介したオンプレミス基盤として動作する以上、完全にActive Directoryを排除できる公式ソリューションは現時点で提供されていません。
Microsoftの公式発表の有無
MicrosoftはNPSに関する大規模なリニューアルの発表をしていません。Windows Serverのアップデートで細かな修正やMFAエクステンションのアップデートはあるものの、Active DirectoryレスのNPS運用をサポートする計画は公表されていないのが実情です。
クラウドシフトの潮流から見ると、今後「NPS自体をクラウドネイティブで動かせるようにする」可能性は考えられますが、具体的なロードマップは不透明です。したがって、すぐに完全クラウド対応が実現する見込みは低いと考えておいた方がよいでしょう。
代替策として考えられる方法
現状、「NPSとMicrosoft Entra IDを直接繋げる」ことが難しい以上、代替手段としては以下のような選択肢が検討されます。
1. Azure AD Domain Services（AAD DS）の活用
オンプレミスのドメインコントローラーを廃止したい場合、Azure AD Domain Services（AAD DS）を利用する方法があります。AAD DSでは、クラウド上にドメインコントローラー相当の機能を構築でき、従来のLDAPやKerberos、NTLMといったプロトコルもサポートします。
これにより、オンプレミスの物理サーバーを置かなくとも、クラウド上で「ドメイン参加マシンを管理できる環境」が得られます。NPSをAzure上の仮想マシンに配置し、AAD DSをディレクトリソースとして認証を行うことで、実質的にオンプレミスレスな構成が可能です。
ただし、この構成は「完全にActive Directoryを使わない」というよりも、「Azure上でAD相当の機能を使う」形に近く、ライセンスやコスト面、運用の複雑さを加味する必要があります。
2. ハイブリッド環境の維持
すでにオンプレミスADを運用している場合は、ハイブリッド構成を維持しながらクラウドシフトを進める方法が最も多いです。
- オンプレミスADとAzure ADを同期させる（Azure AD Connectなどを使用）
- NPSはオンプレミスADを参照する
- 追加の多要素認証をクラウド（Entra ID）で実行する
こうした段階的アプローチでクラウド移行を進めることにより、既存のAD連携を活かしつつ、ユーザーのMFA体験をクラウド主体にシフトできます。
3. サードパーティ製ソリューションの導入
NPSにこだわらず、RADIUS認証やVPN接続をクラウドネイティブで行えるサードパーティ製ソリューションに切り替える方法もあります。Zero Trustネットワークを前提とした製品や、クラウドIDプロバイダーへのネイティブ連携を標榜するサービスなどが該当します。
一部ソリューションでは、直接Azure AD（Entra ID）をユーザーストアとして参照し、RADIUSの役割をクラウドサービス側で実行することも可能です。導入コストや運用負荷は発生しますが、将来的にオンプレミスインフラを極小化する狙いがあるのであれば、検討に値します。
NPS運用における具体的な設定例
ここでは、NPS Extension for Microsoft Entra MFAを用いたハイブリッド構成の一例を示します。あくまでサンプル構成としてご参考ください。
# 1. Windows Serverの機能インストール
Install-WindowsFeature NPAS -IncludeManagementTools
# 2. NPS Extensionのインストール
# ダウンロードしたNPS Extension for Azure MFAインストーラーを実行
.\NpsExtnConfigSetup.exe
# 3. Azure ADテナント登録情報の設定
# Azure ADテナントで作成したアプリケーションのClient IDなどを設定
Set-NpsExtensionConfiguration -TenantId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-ClientId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-ClientSecret "クライアントシークレット" `
-UserDiscoveryMethod "UPN"
# 4. NPSポリシーの設定
# RADIUSクライアント（VPN機器やWi-Fiコントローラなど）をNPSに登録
Add-RadiusClient -Name "VPNServer1" -IPAddress "10.0.0.10" -SharedSecret "RADIUS共通秘密"
# 5. Connection Request PolicyおよびNetwork Policyの適切な設定
# - Connection Request PolicyでNPS Extensionを利用するよう指定
# - Network Policyでユーザーやグループのアクセス制御このように、従来のRADIUS認証の設定と同時にNPS Extensionを導入することで、クラウドベースの多要素認証を実装できます。しかし、この方式では依然としてオンプレミスADでのユーザーアカウント管理が前提となる点に注意が必要です。
代替策比較表
以下の表は、NPSとEntra IDを直接統合できない現状を踏まえ、代替策を比較したものです。
| 選択肢 | メリット | デメリット | 主な利用ケース |
|---|---|---|---|
| Azure AD Domain Services | ・クラウド上でADドメインコントローラー相当を利用可能 ・オンプレミスサーバー不要（ただしVMの維持は必要） | ・AD DS相当のコストが発生 ・設定や運用がやや複雑 | ・オンプレミスの縮小や廃止が狙い ・完全クラウド上でADを提供したい場合 |
| ハイブリッド構成 | ・既存のAD環境をそのまま活用 ・段階的なクラウド移行が可能 | ・オンプレミスサーバーを維持する必要 ・ネットワーク構成が複雑化 | ・既存資産を活かしたい ・急激な移行リスクを避けたい場合 |
| サードパーティ製 RADIUS ソリューション | ・クラウドネイティブでのRADIUS認証が可能 ・Entra IDをIDソースとして直接参照できる製品もあり | ・追加コストや学習コスト ・サポート範囲がベンダー依存 | ・今後オンプレミス機能を極力無くしたい ・ゼロトラスト等、新しい認証アーキテクチャを導入したい |
今後の展望と準備
MicrosoftがNPSとEntra IDを直接統合するための機能を提供する可能性は、今後のクラウドシフトの潮流から考えると十分にあり得ます。事実、MFAや条件付きアクセスといったセキュリティ機能は年々強化されており、オンプレミスの役割を縮小する方針を打ち出しています。
しかし、少なくとも本稿執筆時点においては、正式に「NPSがオンプレミスADなしで動作する」ためのロードマップは公開されていません。現実的には「NPS Extension for Microsoft Entra MFA」や「Azure AD Domain Services」、「サードパーティ製ソリューション」のいずれかを駆使して、ニーズに合った構成を選択するのがベストです。
運用者が今すべきこと
- 現在の環境の棚卸し
・オンプレミスADの利用状況、認証対象の規模、ネットワーク構成を改めて可視化する。 - クラウド移行の優先度と段階的な計画立案
・NPSを含む主要サービスをどのタイミングでクラウドに移行するのか、具体的なマイルストーンを設定する。 - サードパーティ製も含めた最新動向の調査
・クラウドネイティブRADIUSやVPN、ゼロトラストソリューションなど、自社の要件に合う代替製品を検討する。 - Microsoftのアップデート情報をチェック
・NPS関連の機能更新やEntra IDの新機能リリースは随時ウォッチ。特にTechCommunityや公式ドキュメント、Igniteなどの発表イベントを追いかける。
まとめ
NPSとMicrosoft Entra IDを直接連携する方法は、現時点で残念ながら公式には提供されていません。クラウドファーストが進む中で「オンプレミスADなしにRADIUS認証を実現したい」というニーズは高まっていますが、NPSは歴史的にWindows Server＋Active Directoryと密接に結びついた存在です。そのため、実際にはハイブリッド構成を維持しつつクラウドMFAを導入するか、Azure AD Domain Servicesやサードパーティ製ソリューションといった代替案を検討するのが現実的なアプローチです。
将来的にMicrosoftがクラウドネイティブなNPSのアーキテクチャを提供する可能性は否定できませんが、具体的なロードマップやリリース計画は公表されていません。したがって、現場で運用に携わる方は今ある選択肢を上手く活用しつつ、アップデート情報をフォローし続けることが重要です。どの方法を選択するにせよ、自社の運用ポリシーやコスト、リスクマネジメントを踏まえた慎重な検討が求められます。
コメント