NPSからの安全なクラウド移行を実現する | SecureW2による段階的移行のすすめ【前編】

これまでNPS(Network Policy Server)やAD CS(Active Directory Certificate Services)といったオンプレミスのWindows Serverの機能は、企業ネットワークにおけるRADIUS認証やPKI運用の要として活用されてきました。近年ではMicrosoft Entra IDやIntuneの進化により、PKIサービスのクラウド移行が進みつつありますが、Microsoft Entra IDではRADIUS連携にNPS拡張機能を用いる構成が提供されていますが、現時点ではMicrosoft Entra ID単体で完結するクラウドRADIUSサービスは提供されておらず、オンプレミスNPSの運用が残るケースがあります。

そこで本ソリューションではNPSをSecureW2 Cloud RADIUSに、AD CSをSecureW2 Cloud PKIへ移行する方法を紹介します。

当社が提供するSecureW2は、PKI管理からRADIUS認証までをクラウドで一元化できるプラットフォームです。クラウド上のRADIUS、証明書によるデバイス認証、外部IdP連携によるアクセス制御を通じて、より堅牢なネットワークセキュリティを実現します。既存のNPS/AD CSを利用しているが、運用負荷や可用性に課題を感じているシステム管理者にとって、SecureW2は「どの部分をクラウドに任せ、どの部分を自社で管理すべきか」を考える一つの選択肢となります。

本ソリューションは以下の2部構成の記事として解説します。
Part1(本記事):NPSをSecureW2 Cloud RADIUS に移行する
Part2:AD CSをSecureW2 Cloud PKIに移行する
本記事では、AD CSの秘密鍵や証明書発行機能をSecureW2へ移行するのではなく、AD CSのCA証明書をSecureW2側の信頼アンカーとして登録し、既存クライアント証明書をSecureW2のRADIUSサーバーで認証できる状態にします。

なぜNPSからSecureW2 Cloud RADIUSへの移行が勧められるのか

ここでは、NPSの運用を継続する際の課題と、SecureW2 Cloud RADIUSで解決できることについてご説明します。

NPSの運用を継続する際の課題

  • 冗長化によるサーバー管理の手間が増える、障害対応が属人的で復旧や原因調査に時間がかかる。
  • RADIUS基盤が社内ネットワークに依存するため、拠点の増加やネットワーク構成の変更に柔軟に対応しにくい。
  • IdP連携や端末状態を考慮したアクセス制御など、より高度な認証ポリシーを実装することが難しい。

SecureW2 Cloud RADIUSで解決できること

  • クラウドサービスとして提供されるため、オンプレミス環境でRADIUSサーバーの冗長構成を設計する必要がない。フェイルオーバーや監視もサービス側で管理される。
  • クラウド環境で複数地域に展開されたRADIUSサーバーを利用できるため、拠点拡大やネットワーク構成の変更にも柔軟に対応できる。
  • IdPやEDRと連携することで、ユーザー属性や端末状態を反映した柔軟で安全なアクセス制御を実現できる。

どのように移行していくのか

移行前のNPS/AD CSの運用イメージ図を示します。

NPS/AD CSからSecureW2へ移行する際に重要なのは、既存環境を止めずに“段階的に切り替えていく”設計を取ることです。RADIUS認証と証明書配布の仕組みを一度に置き換える必要はなく、まずは認証基盤(RADIUS)、次に証明書基盤(PKI)という順番で進めることで、影響範囲を最小限に抑えながら移行できます。

本記事で提案する移行アプローチは以下になります。

RADIUSのクラウド化から始める

現在NPSが担っているRADIUS処理をSecureW2 Cloud RADIUSへ段階的に切り替えます。この段階では、既存のAD CSで発行済みの証明書をそのまま使用できるため、証明書の再発行や端末再構成は不要です。移行時は、SecureW2のRADIUSサーバー情報を設定した新規SSIDを追加し、必要なルート証明書や無線プロファイルをグループポリシー経由で各端末へ配布することで並行稼働が可能になり、切り替えの影響を最小限に抑えられます。

こちらはRADIUS移行後の構成イメージです。

前提条件

今回の検証では、以下の項目を前提条件としています。

  • AD CSが発行するクライアント証明書に設定されたCRL配布ポイント(http または https)が、SecureW2などの外部ネットワークからアクセス可能な状態であること
  • AD CSの役割を持ったWindows Serverの管理者権限を持っていること
  • SecureW2の管理者アカウントを持っていること
  • 無線APでEAP-TLS認証の設定が完了していること
    • 今回の検証ではCisco Merakiを使用していますが、EAP-TLSに対応している無線APであれば、他製品でも再現可能です
CRL配布ポイントは外部から到達可能である必要があります

CRL配布ポイント(Certificate Revocation List Distribution Point)とは、証明書が失効したかどうかを確認するためのリスト(CRL:証明書失効リスト)を公開している場所のことです。
SecureW2 Cloud RADIUSは証明書の失効確認時にCRLへアクセスするため、CRL配布ポイントは外部から到達可能である必要があります。

本検証で使用した構成

今回の検証で使用した端末やサービス情報を以下の表に示します。

本記事の手順は検証環境での構成例です。本番環境へ適用する場合は、既存SSID・証明書配布状況・CRL到達性・無線AP側のRADIUS設定・ネットワーク経路を確認したうえで、段階的に切り替えてください。

役割

製品名
(メーカー)

機能

バージョン

AD DS
AD CS
NPS

Microsoft Windows Server 2022 (64-bit)
(Microsoft)

ユーザー管理
証明書発行
認証・認可

21H2

認証局
RADIUSサーバー

SecureW2 JoinNow
(SecureW2)

証明書発行
認証・認可

7.8.0.GA1

RADIUS Client

MR33-HW
(Cisco Meraki)

無線AP

MR30.6

802.1X Supplicant

ThinkPad E15
(Lenovo)

クライアントPC

Windows 11 23H2

RADIUSのクラウド移行

弊社で行った移行手順をダイジェストでお伝えします。

AD CSのCA証明書をSecureW2にインポート

SecureW2のクラウドRADIUSにAD CSのルートCAが認識されるように、SecureW2にAD CSのルートCA証明書をインポートします。今回はルートCAのみとなっておりますが、中間CA証明書もダウンロード可能となっているので、2層PKIを行っている方でも安心して移行を行っていただけます

  1. ルート認証局を作成したWindowsサーバーでブラウザを開き、 http://127.0.0.1/certsrv を検索したら、ADのユーザー名でログインし、CA証明書のインストールを行います。
  2. ダウンロードしたファイルを確認後、Google Driveなどを使って、SecureW2を操作する端末に転送してください。
  3. SecureW2にログインし、PKI > Certificate Authoritiesから[Import Certificate Authority]をクリックします。
  4. 以下のように設定し、[import]をクリックします。Certificateには「CA証明書のダウンロード:手順3」で転送したcerファイルをアップロードしてください。

以上でCA証明書のインポートは完了です。

Windowsサーバーのグループポリシー設定

SecureW2のクラウドRADIUSを用いた無線認証を行うには、ネットワーク構成プロファイルでSSIDがDigiCert Global Root G3を信頼するよう設定し、クライアント端末に対してもDigiCert Global Root G3を信頼されたルート証明機関として配布する必要があります。今回はクライアント証明書を自動配布するグループポリシーと同じ場所に設定を行います。

  1. グループポリシーの管理を起動、グループポリシーの編集からコンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定 > 公開キーのポリシー > 信頼されたルート証明機関に、DigiCert Global Root G3をインポートします。
  2. ワイヤレスネットワーク(IEEE 802.11)ポリシー > 「ネットワークポリシー名(例:Pentio_Network)」を選択します。
  3. 追加 > インフラストラクチャをクリックして、プロファイル名とSSID名を設定後、「このネットワークが接続範囲内に入ると自動的に接続する」にチェックを入れてください。操作の完了後セキュリティタブをクリックします。
  4. 認証方法と認証モードを設定したらプロパティをクリックし、サーバーのドメインを入力、信頼されたルート証明機関としてDigiCert Global Root G3を選択後OKをクリックします
  5. プロファイルが追加されていることを確認し、適用をクリック後OKをクリックしてください。

以上の設定により、SSIDがDigiCert Global Root G3を信頼するとともに、クライアント端末にも同ルート証明書を信頼された証明機関として配布できるようになりました。また、SecureW2のRADIUSを用いたSSID接続に必要なネットワークプロファイルも、端末に配布可能な状態となりました。

SecureW2のネットワークポリシー設定

SecureW2のRADIUSサーバーが、AD CSのCAから発行されたクライアント証明書によるEAP-TLS認証を許可するようネットワークポリシーの設定を行います。

  1. Policy Management > Network Policyに移動したら[Add Network Policy]をクリックし、適切な名前(例:Pentio_Network)をつけて、[Save]をクリックします。
  2. ConditionタブでIssuerをインポートしたルート認証局に設定し、[Update]をクリックします。2層PKI環境では中間認証局を選択できます。AD CSの中間CA証明書をインポートしていれば、無線認証時にNetwork Policyが正しく動作します。

以上で、SecureW2の設定は完了です。これでSecureW2のクラウドRADIUSでの無線認証にAD CS発行のクライアント証明書を利用できるようになりました。

SSIDの設定

新たにSSIDを作成し、SecureW2のクラウドRADIUSサーバー情報を登録します。今回はCisco Merakiのアクセスポイントを使用しました。

  1. Meraki管理ダッシュボードにアクセスし、新たにSSIDを設定します。新規SSIDのアクセス制御管理画面でRADIUSサーバ設定から[サーバ追加]を2回クリックし、サーバを2つ追加します。
  2. SecureW2のRADIUSサーバーのIPアドレス、認証ポート、シークレットを入力して[保存]をクリックします。ここで入力したIPアドレスと認証ポート番号は例示用のものであり、IPアドレスはSecureW2のクラウドRADIUSサーバー固有のものが存在し、認証ポート番号はお客様ごとに異なります。

以上でSSID接続時にAPがSecureW2のRADIUSサーバーに認証要求を送信することが可能になります。

RADIUS移行後の動作確認

実際にクライアント端末を用いて、SecureW2 Cloud RADIUSでの無線認証にAD CS発行のクライアント証明書を使用するデモ動画を撮影しました。
動画内ではSSID:Pentio_NPS(NPSでのEAP-TLS認証)からPentio_Network(SecureW2 Cloud RADIUSでのEAP-TLS認証)に切り替わる挙動が確認できます。

PKIのクラウド移行

最後のステップでは、証明書ライフサイクルの自動化に向けてPKIの移行を行います。現在制作中です。記事の公開をお待ちください。

おわりに

NPSとAD CSを組み合わせた認証環境は、これまで多くの企業ネットワークにおける無線認証基盤として利用されてきました。しかし、クラウドサービスの普及や端末環境の多様化に伴い、オンプレミス中心の設計では運用負荷や拡張性の面で課題が見え始めています。

本記事では、既存のAD CS証明書をそのまま利用して、RADIUS認証基盤をSecureW2 Cloud RADIUSへ移行する方法を紹介しました。CA証明書をSecureW2に登録することで、既存証明書を再配布することなく、NPSからクラウドRADIUSへ認証経路を移行できる点が大きな特徴です。

このように、まずRADIUSサーバーをクラウド化することで、既存環境への影響を最小限に抑えながら認証基盤のクラウド移行を進めることができます。

次の記事では、AD CSのPKI基盤をSecureW2 Cloud PKIへ移行し、証明書発行や管理をクラウド化する方法を解説します。証明書の自動配布やIdP連携などを含めた、より柔軟で拡張性の高い認証基盤の構築について紹介していきます。

引き続き、「SecureW2による段階的移行」の後編もぜひご覧ください。以上で、「NPSからの安全なクラウド移行を実現する | SecureW2による段階的移行のすすめ【前編】」を終わります。

目次