Entra IDとクラウドRADIUSで無線LAN認証を実現する
〜ユーザーステータス・属性に応じたネットワークアクセスの動的制御をクラウドで完結〜

今回はSecureW2が提供するDynamic RADIUSを利用し、Microsoft Entra ID(以降、Entra ID)のユーザー・グループ情報に基いてネットワークポリシーを動的に制御する検証を行いました。本記事ではSecureW2のDynamic RADIUSについての詳細や、Entra IDとの具体的な連携設定について解説しております。Entra IDをソースとしたクラウドベースのRADIUS認証にご関心のある方はぜひ最後までご覧ください。

Dynamic RADIUSとは

Dynamic RADIUSは、外部のIdP(IDaaS)のユーザー属性(ステータスやグループなど)に基づいた動的なネットワークアクセス制御をリアルタイムに実現します。 Dynamic RADIUSはSecureW2のAccount Lookup機能によって提供され、RADIUSクライアントからSecureW2に対してRADIUS認証要求があった時、その都度証明書内に含まれるユーザー情報に基づいて外部のIdP(IDaaS)のグループやユーザー属性の情報を参照します。

Dynamic Radiusとは

Dynamic RADIUSを利用することで実現できることは、例えば以下です。

  • Entra IDのユーザーステータスが有効か無効かを判別し、認証を許可・拒否する
  • Entra IDのユーザー・グループごとにネットワークポリシーを分岐する
Dynamic RADIUSを利用することで実現できること

作業概要

最終的な構成

本記事では最終的に以下のような構成を想定し、③~⑥に必要な設定を解説していきます。今回は⑥でRADIUSクライアントに応答するメッセージにVLAN-IDを付与することで、ユーザーが所属するネットワークを動的に制御します。(Dynamic VLAN)

構成図

想定シナリオ

本記事では理解を円滑にするために、以下の想定シナリオを想定します。最終的な構成でも示している通り、ユーザーの登録やグループの割り当ては事前に済ませているものとします。

Entra ID上のグループ名 所属しているユーザー
営業部 Alice(alice.demouser@oneloginjp.onmicrosoft.com)
情報システム部 Bob(bob.demouser@oneloginjp.onmicrosoft.com)
Entra ID設定画面Entra ID設定画面

動作確認

以上を踏まえて、想定される動作を検証するために以下の項目を検証します。

  • Entra ID上の異なるグループに所属するユーザーが、SecureW2内でそれぞれ異なるRoleとPolicyが割り振られていることをSecureW2のRADIUSログから確認する
  • Policyの分岐によって、ユーザーごとに異なるVLAN-IDが割り当てられていること(Dynamic VLAN)を確認する
  • Entra ID上でユーザーを無効にして再度認証を行った時、リアルタイムでアクセスがブロックされることを確認する

前提条件

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

  • Entra IDのグローバル管理者であること
  • Entra ID上にユーザー / セキュリティグループが事前に作成されており、それぞれのグループに1人以上のユーザーが所属していること
  • SecureW2の管理者であること
  • SecureW2から上記のユーザーに対してそれぞれクライアント証明書が配布されていること
  • アクセスポイントのSSIDの設定やRADIUSサーバーの設定が完了していること

具体的な設定手順

Entra IDの設定

  1. Entra IDの管理画面にアクセスし、アプリケーション > アプリの登録をクリックします。画面が遷移したら、左上の 新規登録 をクリックします。
    Entra ID設定画面
  2. 以下の画像を参考にアプリケーションを登録します。リダイレクトURIではWebを選択し、SecureW2の組織固有のURLを作成して設定します。以下に例示するURLのMyOrganization部分をSecureW2のGeneral > Organizationから確認できるOrganization Identifierに変更します。
    例:https://{MyOrganization}-auth.securew2.com/auth/oauth/code
    Entra ID設定画面SecureW2設定画面
  3. 作成されたアプリケーションのアプリケーションID(クライアントID) テナントIDの値をメモします。後ほどSecureW2の設定で使用します。
    Entra ID設定画面
  4. 続いてシークレットを作成します。アプリケーションの画面から証明書とシークレット > 新しいクライアントシークレットをクリックします。
    Entra ID設定画面
  5. 説明有効期限を設定し、 「追加」 をクリックします。
    Entra ID設定画面
  6. クライアントシークレットの値をメモします。後ほどSecureW2の設定で使用します。
    Entra ID設定画面
  7. 最後にAPIのアクセス権限の設定を行います。APIのアクセス許可 > アクセス許可の追加をクリックし、続けてMicrosoft Graphを選択します。
    Entra ID設定画面
  8. 委任されたアクセス許可を選択し、次のステップの画像で表示されている5つのアクセス許可を追加します。
    Entra ID設定画面
  9. 5つのアクセス許可が追加されたことを確認したら、グローバル管理者のアカウントで管理者の同意を与えますをクリックしてアクセス許可の設定を承認します。このとき、権限の種類が全て委任済みであることを確認します。
    Entra ID設定画面
  10. 以下の画像のように、全てのAPIへアクセス許可が与えられたことを確認します。
    Entra ID設定画面

SecureW2の設定

- Identity Lookup Providerの設定

Identity Lookup Providerに先ほど作成したアプリケーションの情報を設定することで、APIを介してEntra ID上のユーザー情報やグループ情報を取得できるようになります。

  1. SecureW2画面から Identity Management > Identity Providers をクリックし、Add Identity Providerから新しいIdPを作成します。
    SecureW2の設定画面
  2. 以下のように設定し、Saveをクリックします。
    SecureW2の設定画面
  3. Configurationタブに移動し、以下の表のようにEntra IDで取得した値をそれぞれ設定してください。設定が完了したらUpdateをクリックします。
    項目
    Provider URL ・https://login.microsoftonline.com/{Directory (tenant) ID}
    {Directory (tenant) ID} にディレクトリ(テナントID)を挿入します。
    例:https://login.microsoftonline.com/cc2ac844-4eb3-4daa-49d5-da9ad7b0796c
    Client Id アプリケーションID(クライアントID)を入力
    Client Secret クライアントシークレットの値を入力
    SecureW2の設定画面
  4. Identity Providerの一覧で先ほど作成したIdPをAuthorizeし、このIdentity Providerが正しく動作しているかをチェックします。Entra IDの認証画面が表示されたら、Entra IDのグローバル管理者のアカウントで認証してください。これによってSecureW2からEntra IDの情報を参照できているかを確認します。
    SecureW2の設定画面

    ※成功すると以下のようなメッセージが表示されるページにリダイレクトします。

    SecureW2の設定画面
  5. Groupタブから Add をクリックします。こちらはEntra ID上のセキュリティグループごとにRoleを分岐したい場合に設定します。
    SecureW2の設定画面
  6. 以下の表を参考に値を設定したら Create をクリックします。
    項目名 設定値
    Local Group 営業部(任意の名前)
    Remote Group 営業部(Entra ID上のグループ名)
    SecureW2の設定画面
    項目名 設定値
    Local Group 情シス部(任意の名前)
    Remote Group 情報システム部(Entra ID上のグループ名)
    SecureW2の設定画面
  7. 同じようにEntra IDのグループをマッピングし、登録が完了したら Update をクリックします。
    SecureW2の設定画面

- Account Lookup Policyの作成

Account Lookup PolicyはAccount Lookupをトリガーする条件を設定します。今回はSAN-UPNに含まれるメールアドレスが条件として設定した正規表現に適合した場合に、先ほど作成したIdentity Lookup Providerを使用してEntra IDにAccount Lookupを行うように設定します。

  1. SecureW2の管理ポータルから Policy Management > Account Lookup Policies をクリックし、Add Account Lookup Policy をクリックします。
    SecureW2の設定画面
  2. ポリシーの名前を設定したら Save をクリックします。
    SecureW2の設定画面
  3. Conditionsタブに移動し、以下のように設定したら Update をクリックします。
    SecureW2の設定画面

    ※この設定では、SecureW2に登録されているいずれかのIdPで認証を行った時、認証に使われた証明書のSAN-UPNの値が「.*@oneloginjp.onmicrosoft.com$」と合致した場合にこのポリシーが適用されます。 今回のシナリオでは証明書のupnにEntra ID上のユーザープリンシパル名が含まれています。

  4. Settingsタブをクリックし、以下のように設定したら Update をクリックします。
    SecureW2の設定画面

    ※Settingsタブでは、このポリシーが適用された場合にどのIdentity Lookup Providerに対して、証明書のどの値を使ってAccount Lookupを行うか を設定します。今回はポリシーの適用条件としても使用したSAN-UPNの値を用いてEntra IDのユーザープリンシパルネームと照合します。

  5. 設定が完了したら、今一度Settingsタブに戻ってValidiate Configurationをクリックします。
    SecureW2の設定画面
  6. クリックすると以下のような画面が表示されます。入力欄にAccount Lookupの対象としたいユーザーの情報を入力してValidateをクリックすると、Account Lookupが成功するかのテストを行うことができます。
    SecureW2の設定画面
  7. 以下の画像のようにLookupに成功したら設定は完了です。
    SecureW2の設定画面

- Policy Engine Workflowsの作成

Entra ID上のグループ / ユーザーごとに、SecureW2のローカルのロールを作成して割り当てる必要があります。

  1. Policy Management > Policy Engine Workflowsから、Add Policy Engine Workflow をクリックします。
    SecureW2の設定画面
  2. 今回はEntra ID上の「営業部」グループに所属しているか「情報システム部」グループに所属しているかによってSecureW2のRoleを分けるため、それぞれに対応する「営業部 Role」と「情報システム部 Role」を作成します。
    SecureW2の設定画面SecureW2の設定画面
  3. Conditionsタブをクリックし、Identity Providerから 先ほど作成したIdentity Lookup Provider を選択します。次に、GroupsでEntra ID上からマッピングしてきたグループをそれぞれ選択して Update をクリックします。
    SecureW2の設定画面SecureW2の設定画面
  4. 適宜、作成したRoleの優先順位をあげます。
    SecureW2の設定画面

    ※SecureW2はRoleの割り当てに優先順位があります。Account Lookupを利用する場合、Account Lookup Policyが適用されるが割り当てられるRoleが存在しない場合はデフォルトで用意されている「DEFAULT FALLBACK ROLE POLICY」というRoleが割り当てられるため、作成したRoleはそれより上の優先順位に設定します。

- Network Policyの作成

作成したRoleごとにNetwork Policyを作成します。

  1. Policy Management > Network Policiesから、Add Network Policy をクリックします。
    SecureW2の設定画面
  2. 今回はRoleに対応してNetwork Policyを分岐するため、営業部 Network Policyと情報システム部 Network Policyをそれぞれ作成します。
    SecureW2の設定画面SecureW2の設定画面
  3. Conditionsタブをクリックし、Add rule をクリックします。
    SecureW2の設定画面
  4. 表示されるRulesの一覧から Identity を選択し、Role にチェックを入れます。正常に適用されると上部に「'Role' selected」と表示されるので、確認したら Save をクリックします。
    SecureW2の設定画面
  5. 営業部 Network Policyは営業部 Role(Entra ID上の「営業部」グループ)が割り当てられたユーザーに適用させたいので、Roleで 営業部 Roleを選択します。選択したら Update をクリックします。情報システム部も同様に設定してください。
    SecureW2の設定画面SecureW2の設定画面
  6. Settingsタブに移動し、Add Attributeをクリックします。この画面で使用するRADIUS属性の設定を行います。
    SecureW2の設定画面
  7. DictionaryのプルダウンからRadius:IETFを選択します。今回のシナリオではDynamic VLANの利用を想定しているため、以下の表を参考にそれぞれ設定を行います。
    Radius:IETFの属性(Attribute:) 値(Value:) 説明
    Tunnel-Type 13 VLAN(固定値)
    Tunnel-Medium-Type 6 IEEE-802(固定値)
    Tunnel-Private-Group-ID 任意のVLAN-ID(1-4094) 認証対象のユーザーや機器が認証をパスした後に所属させるVLAN-ID
    今回のシナリオでは "Alice"=100, "Bob"=200 を設定します。
    SecureW2の設定画面SecureW2の設定画面SecureW2の設定画面SecureW2の設定画面
  8. ユーザーごとにそれぞれ画像のように設定できたら、Updateをクリックします。
    SecureW2の設定画面SecureW2の設定画面
  9. 適宜、作成したNetwork Policyの優先順位をあげてください。
    SecureW2の設定画面

    ※Policy Engine Workflowsと同様、Network Policyにも優先順位が存在します。RADIUS認証を行なったユーザーの証明書の内容やSecureW2のRoleなどの条件に基づいて上から判定を行います。

動作確認

最初に挙げた以下三つの検証項目について動作確認を行います。

  1. Entra ID上の異なるグループに所属するユーザーが、SecureW2内でそれぞれ異なるロールとポリシーが割り振られていることをSecureW2のRADIUSログから確認する
  2. Policyの分岐によって、ユーザーごとに異なるVLAN-IDが割り当てられ、異なるネットワークに所属していること(Dynamic VLAN)を確認する
  3. Entra ID上でユーザーを無効にして再度認証を行った時、リアルタイムでアクセスがブロックされることを確認する

(1&2)ロール・ポリシーの分岐とDynamic VLANの確認

まずは上記項目の1と2について検証を行います。以下の動画をご覧ください。

  1. それぞれのユーザー証明書を用いて無線認証を行います。
    動作確認動作確認
  2. 認証に成功し、無線LANに接続できました。
    動作確認
  3. まずはVLAN-IDが正しく付与され、DHCPで指定した範囲内のIPからアドレスが払い出されているかを確認します。
    今回の例では、VLAN-IDが100の際にDHCPサーバーから192.168.100.2/24 - 192.168.100.254/24の範囲で、200の場合は192.168.200.2/24 - 192.168.200.254/24でIPアドレスを割り振る設定にしているため、設定した範囲のIPアドレスが正しく割り振られていることが確認できます。
    動作確認動作確認
  4. 次にWiresharkでRADIUS認証フローのAccess-Acceptメッセージの中身を確認します。
    営業部に所属する"Alice"にはVLAN=100を、情報システム部に所属する"Bob"にはVLAN=200を付与していることがわかります。
    動作確認動作確認
  5. 最後にSecureW2のRADIUSログを確認します。SSID「Pentio_test」に対するEntra ID上の異なるグループに所属する2ユーザーからの認証要求に、それぞれ適切にロールとポリシーを割り当てていることがわかります。また、応答したVLAN-IDも確認できました。
    動作確認

(3)無効なユーザーの証明書で認証を行う

次に上記項目の3について検証を行います。以下の動画をご覧ください。

  1. Entra ID上で有効なユーザー"Alice"を無効化します。
    動作確認
  2. ネットワークに再度認証を行うために、SSIDを一度オフにし、再度オンにします。
    動作確認
  3. 再度認証が行われましたが、認証が通らずネットワークから遮断されました。パケットキャプチャからも"Access-Reject"メッセージを受け取っていることが確認できます。
    動作確認
  4. SecureW2のRADIUSログからは「ユーザーが無効化されているため認証に失敗した」という旨のメッセージを確認できました。
    動作確認
  5. この時証明書自体は失効していないため、再度Entra ID上からユーザーを有効化することで正常に認証を行うことができるようになります。
    動作確認

おわりに

今回はEntra IDのユーザーがSecureW2のクラウドRADIUSを利用して無線認証を行う際に、SecureW2のDynamic RADIUSを利用して、Entra IDのユーザー・グループ情報に基づいたネットワークポリシーの動的制御ができるかを検証しました。Entra IDと連携を行うことで、以下のようなメリットが生まれます。

  • Entra IDの状態に応じたアクセスコントロール
    RADIUS認証のIDソースとしてEntra IDを利用することで、IDaaSによる統合された認証・認可をネットワークアクセス制御にも提供します。
  • リアルタイムなポリシー制御
    Account LookupはSecureW2へRADIUS認証要求が届くたび、Entra IDにユーザー情報を問い合わせます。ユーザーの所属グループに変化があった場合でも、最新の変更を反映した認証結果を応答します。
  • Entra IDイベントをトリガーにしたクライアント証明書の失効
    SecureW2 Event Hooksをご利用いただくことで、Entra IDユーザーに対する特定のイベント(ユーザーの無効化 / 削除)をトリガーとしたクライアント証明書の即時失効が可能です。

SecureW2は物理アプライアンスの設置が一切不要なクラウド型RADIUSで、国内外問わず世界中のどこからでも社内の認証基盤としてRADIUSエンドポイントを提供します。例えば日本の本社所属の社員が海外の支社に出張した際にも、本社のポリシーを利用して支社側のアクセスポイントにアクセスすることができます。

また、アクセスポイントとしてCisco Meraki / HPE Aruba / Ubiquiti UniFiをご利用されているお客様は、SecureW2の拡張機能である Real-Time Intelligence もご利用いただけます。Real-Time Intelligenceをご利用いただくことで、本来ネットワークへの再接続など再認証がトリガーされるまで遮断されなかったデバイスのネットワーク接続を、証明書の失効と同時にリアルタイムに遮断することができるようになります。Event Hooks機能と併用することで、IDaaS上のユーザーが無効になった際に即時に証明書失効とネットワーク遮断を行う構成が実現できます。

SecureW2とEntra IDを併せて導入することで、社員の入退社や異動に伴う工数の削減など管理者の負担軽減だけでなく、リアルタイムなポリシー適用や証明書の即時失効など、IDaaSを中心としたネットワーク運用を可能にします。SecureW2とEntra IDの導入を検討してみてはいかがでしょうか。以上で「Entra IDのユーザー情報に基づいた動的なネットワークアクセス制御を実現する」検証レポートを終わります。

*本サイトに掲載されている製品またはサービスなどの名称及びロゴは、各社の商標または登録商標です。

問い合わせはこちら

ペンティオでは、SecureW2の無料トライアルを承っております。社内環境をヒヤリングさせていただいた後にトライアル環境を準備いたします。

※トライアル環境のご手配には数日お時間をいただきます