リモートワークやBYODの普及により、クラウド環境で管理されるデバイスが急増しています。オンプレミスのネットワークを守るためにはVPNや無線LANの認証でNPS（Network Policy Server）を活用したいものの、「クラウド参加されているデバイスをEAP-TLSなどのデバイス証明書で直接認証できるか？」という疑問を持つ方も多いのではないでしょうか。そこで今回は、NPSとMicrosoft Entra ID（旧Azure AD）にクラウド参加されたデバイスとの連携や認証方式について、具体的な構成や運用上のポイントを含めて詳しく解説します。
NPSとクラウド参加デバイスの課題
NPSはオンプレミス環境でのRADIUSサーバーとして多くの企業で導入されていますが、クラウドサービスとの連携に焦点を当てると、いくつかの検討すべきポイントが浮かび上がります。ここでは、まずNPSとクラウド参加デバイスを取り巻く代表的な課題を整理します。
オンプレミスのActive Directoryへの依存
NPSは通常、オンプレミスのActive Directory Domain Services（AD DS）と連携してユーザーやデバイスを認証します。ユーザー認証の場合はユーザー名とパスワードをActive Directoryに照合しますが、デバイス認証（EAP-TLSによる証明書認証など）の場合は、AD DSのコンピューターオブジェクトや証明書テンプレートと連携するケースが一般的です。一方で、クラウド参加されているデバイスの場合、オンプレミスのドメインに参加していないため、AD DS単独ではデバイスの属性を把握できません。
ハイブリッドAzure AD参加との違い
クラウド参加デバイスと似た言葉に「ハイブリッドAzure AD参加」がありますが、これはオンプレミスのAD DSに参加しつつAzure AD（Microsoft Entra ID）にも登録されている状態を指します。ハイブリッド参加であればオンプレミスAD DSにデバイスオブジェクトが存在するため、NPSは従来の仕組みで認証が可能です。純粋に「クラウド参加（Azure AD Joinのみ）」されているデバイスはオンプレミス側には登録されていないため、NPSがデバイスを認識する仕組みをどう用意するかが課題となります。
証明書認証を行う際の問題点
EAP-TLSなどの証明書ベース認証は、端末に発行されたクライアント証明書を用いて安全に認証を行います。本来は証明書の失効リスト（CRL）やOCSPレスポンスを使って有効性を確認しますが、その証明書自体をどの認証局が発行し、どのデバイスに割り当てられたものなのかを認識できるかが大きなポイントです。オンプレミスの社内CA（Certificate Authority）が発行した証明書ならば、NPSと連携して失効管理やテンプレート管理が容易に行えます。しかしクラウド側で管理されるデバイスに対して、Azure ADが発行するデバイス証明書をNPSで直接検証できる構成は、標準では用意されていません。
デバイス属性との照合方法
クラウド参加デバイスをデバイス証明書で認証する際、証明書に含まれる「Subject」や「Subject Alternative Name（SAN）」フィールドの情報をもとに、NPSが本当に正当なデバイスであると判断できるかを検討しなければなりません。オンプレミスのAD DSに存在しないデバイスであれば、Azure ADに登録されたデバイス情報と照合する必要が出てきます。NPSがAzure AD（Microsoft Entra ID）に問い合わせてデバイスIDを確認する仕組みは、標準機能では存在しません。このため、何らかの追加ツールや中間レイヤーで「Azure ADにデバイスIDを問い合わせ→NPSが照合する」といった流れを作る必要があります。
クラウド参加デバイスへのデバイス認証アプローチ
続いて、実際にNPSでクラウド参加デバイスのデバイス認証を実現するために考えられるアプローチをいくつか紹介します。それぞれメリット・デメリットがあるため、自社の要件や既存インフラに合わせて検討することが重要です。
方法1：ハイブリッドAzure AD参加を活用する
既にオンプレミスのActive Directory環境があり、かつデバイスをドメイン参加できる状況であれば「ハイブリッドAzure AD参加」を積極的に検討するのが最もシンプルな手段です。デバイスがオンプレミスADとAzure AD双方に登録される形となるので、NPSでは従来通りオンプレミスのコンピューターオブジェクトやGPOによる証明書配布が可能になります。
メリット
- 既存のAD DSベースの証明書インフラが使える
- NPSによるデバイス証明書認証を構成しやすい
- AD DS側でデバイスアカウント管理が行える
デメリット
- デバイスをドメイン参加させるため、運用コストが増加する場合がある
- 純粋な「クラウド参加」を望む環境では方針と食い違う可能性がある
方法2：Azure AD発行の証明書をオンプレミスで認識させる
純粋にクラウド参加しているデバイスに対し、Azure ADが発行するデバイス証明書をEAP-TLSで使用する構成を考えた場合、NPSがその証明書を検証できるようにする必要があります。具体的には以下のようなステップが考えられます。
- Azure AD側で発行されるルート証明書（もしくは中間証明書）をオンプレミスのNPSサーバーやクライアント信頼ストアにインポート
- 発行されたデバイス証明書のSANまたはSubjectに格納されたデバイス識別子をNPS側で処理し、正当性を判断する仕組みを構築
- 失効リスト（CRL）やOCSPレスポンスがAzure側で提供される場合、それらを参照できるネットワーク構成とNPS側の設定を用意
ただし、標準のNPS機能だけではクラウドのAzure ADデバイスIDをオンライン照合する方法がなく、実現するには多大なカスタマイズや追加ツールが必要になることが多いです。
具体的な構成例
例えば、以下のような構成を考えてみましょう。
| 構成要素 | 概要 |
|---|---|
| Azure AD（Microsoft Entra ID） | クラウド参加デバイスを登録し、デバイス証明書を発行する。 |
| オンプレミスNPSサーバー | RADIUSサーバーとしてEAP-TLS認証を実施する。ルート証明書を信頼している場合のみ認証を許可するが、証明書内のデバイスIDも検証が必要。 |
| 中間レイヤーツール | 証明書内のデバイスIDとAzure ADのデバイスレコードを照合し、認証可否をNPSに返す機能を持つ。 |
このように追加レイヤーを挟むことで、証明書のSubject Alternative Nameなどに格納されたデバイスIDをAzure ADのデバイスレコードに問い合わせ、適合すれば認証成功とし、そうでなければ失敗とする仕組みが考えられます。理論上は実装可能ですが、管理コストやカスタマイズ工数、サポート面でのリスクが大きくなる点に留意が必要です。
方法3：代替ソリューションの検討
NPSを使わずにAzure AD（Microsoft Entra ID）ネイティブの機能や、他社のクラウド連携に強いRADIUSソリューションを採用することも一案です。たとえば、Microsoft Intune（Endpoint Manager）と統合してデバイスを管理し、クラウドネイティブのアクセス制御を行う構成を構築する企業も増えています。また、サードパーティベンダーが提供するクラウド連携RADIUSサービスを利用し、Azure ADと連携させる形でEAP-TLS認証を行う事例もあります。
メリット
- クラウドネイティブな管理方法を採用することで運用がシンプルになる場合がある
- 追加レイヤーを自前で構築するよりも短期間で導入できるケースが多い
デメリット
- サードパーティ製品のコストがかかる
- 既存のNPS・オンプレミスADと全く別の仕組みとなるため、移行や学習コストが発生
デバイス証明書の作成・配布と検証
クラウド参加デバイスを証明書で認証するには、デバイス証明書の作成・配布と検証プロセスを正しく設計する必要があります。ここでは具体的な流れと、その際に考慮すべきポイントを見ていきましょう。
証明書テンプレートと自動配布
オンプレミスAD DSを利用する場合、グループポリシーによる証明書自動配布が便利です。しかしクラウド参加デバイスにはグループポリシーが適用できないため、Microsoft Intuneなどを介して証明書をデバイスに配布する方式が考えられます。以下は大まかなフローです。
- Microsoft Intune（Endpoint Manager）で証明書プロファイルを作成
- ルート証明書や中間証明書を登録し、対象デバイスに配布
- デバイスがIntuneから証明書を取得し、ローカルストアに格納
- NPS側では同じルート証明書を信頼し、EAP-TLS認証ポリシーを作成
このように、クラウド管理ツールを使ってデバイス証明書を一括配布できれば、デバイス側の構成がラクになります。ただし、証明書に含まれるデバイスIDなどをNPSがどう活用するかは別途検討が必要です。
サンプル設定例（Intune側）
# Intune PowerShell Moduleを使用する例（架空のサンプル）
# 実際のコマンドは異なる場合があります
# ルート証明書のアップロード
Add-IntuneRootCertificate -Name "MyRootCA" -FilePath "C:\certs\myRootCA.cer"
# SCEP証明書プロファイルの設定
New-IntuneScepCertificateProfile -Name "Device EAP-TLS Certificate" `
-SubjectNameFormat "CN={{DeviceName}}" `
-ValidityInMonths 12 `
-KeySize 2048 `
-HashAlgorithm "SHA256" `
-RootCertificateName "MyRootCA"上記はあくまでイメージです。実際にはGUIから設定を行うか、公式ドキュメントを参照しながら構成を進めます。
証明書失効の管理
デバイス証明書が紛失や盗難にあった場合に、速やかに失効手続きを行えることはセキュリティ上非常に重要です。オンプレミスのCAであればAD CSのCRL（Certificate Revocation List）を発行し、NPSがCRLを参照することで失効を検出できます。一方、Azure AD発行の証明書やサードパーティCAの場合は、オンライン証明書ステータスプロトコル（OCSP）やクラウド上のCRLサービスと連携する仕組みを用意する必要があります。ネットワークのファイアウォールポリシーやプロキシ設定で通信がブロックされていないかなど、運用面での配慮が欠かせません。
NPSポリシーの設定とログ管理
実際にNPSでデバイス認証を行う場合、RADIUSクライアントやネットワークポリシーの設定に加えて、トラブルシューティングを行いやすくするためのログ管理が不可欠です。
ネットワークポリシーの設定例
以下はNPSのネットワークポリシーでEAP-TLSを使用する例を示す設定イメージです。
- 「Connection Request Policies」でEAP-TLSを許可するポリシーを作成
- 「Network Policies」で条件を設定（WindowsグループやActive Directory属性など）
- EAP Methodsに「Smart Card or other certificate（EAP-TLS）」を追加し、トラステッドルートCAを選択
[Conditions]
; ユーザーグループ・コンピューターグループなど必要に応じて設定
[Settings]
EAP-TLS:
Allowed = TRUE
RootCA = "MyRootCA"
ValidateServerCertificate = FALSE ; サーバー証明書は別途設定
ValidateClientCertificate = TRUE実際にはGUI操作がメインになりますが、イメージとしてはこのようにルート証明書を信頼し、クライアント証明書によるEAP-TLSを許可するといった方針です。
ログとイベントビューアの活用
認証がうまくいかない場合、NPSサーバーのイベントビューア（Windows Logs → Security）やNPSログ（C:\Windows\System32\LogFiles など）を確認するのが基本です。証明書不備や失効リストの確認ミスなど、問題の原因が詳細ログに書かれていることも多いため、ログの取り扱いルールを整備しておきましょう。
運用上の注意点と今後の展望
クラウド参加デバイスのデバイス認証をNPSで行う場合、技術的には次のような点に留意する必要があります。また、Microsoftのサービスやエコシステムが進化する中で新たな連携機能が登場する可能性もあるため、常に最新情報をチェックすることが大切です。
オンプレミスとクラウドの境界を意識したネットワーク設計
NPSはオンプレミスサーバーで動作しますが、クラウド参加デバイスは社外ネットワークやインターネット経由で接続される可能性が高まります。VPNやWireless APでRADIUSトラフィックを通す際には、ファイアウォール設定やDNS解決、証明書失効リストへのアクセスなどがスムーズに行えるように設計しましょう。
セキュリティアップデートと暗号化方式のモダナイゼーション
EAP-TLS認証を行う場合、TLSバージョンや暗号スイートに注意し、最新のセキュリティ標準を満たすことが求められます。Windows Serverの更新やNPSのアップデートによって、サポートされるプロトコルが変わる場合もあるため、定期的にパッチを適用し、セキュリティアドバイザリを確認する運用が欠かせません。
Microsoft IntuneやAzure ADとの今後の連携機能
Microsoftのサービス群は、クラウドベースのデバイス認証やネットワークアクセス制御をより簡単にする方向へ進化を続けています。たとえば「Microsoft Entra ID + Intune + Conditional Access + VPN Gateway + RADIUS」などの連携シナリオがさらに強化される可能性もあります。将来的にはNPSに代わるよりクラウドネイティブなRADIUSサービスが提供されることも考えられ、運用形態が大きく変わるかもしれません。
まとめ
クラウド参加デバイスをNPSでデバイス認証するには、標準機能だけでは難しい課題があるのが現状です。オンプレミスのAD DSと一体化したハイブリッドAzure AD参加であれば比較的スムーズに対応できるものの、純粋なクラウド参加デバイスの証明書認証をNPSで実現するには追加の仕組みやツールの導入、あるいはクラウドネイティブな認証ソリューションに切り替える検討が必要です。
しかしながら、EAP-TLSによる証明書認証は安全性が高く、企業にとっては魅力的な選択肢でもあります。運用コストやセキュリティリスクを総合的に評価しながら、Azure ADとNPSの連携方法やハイブリッド構成のメリットを最大限に活かしていくことが重要となるでしょう。ネットワークセキュリティの要であるRADIUS認証をどのようにクラウド時代に最適化するか、将来のアップデートや製品動向にも注目しながら最適解を探していくことが求められます。
コメント