Aruba Central の CloudAuth SSID で、Microsoft Entra ID（旧 Azure AD）を使った SAML ベースの Wi-Fi ユーザー認証を行い、さらに Microsoft Graph API でユーザー/グループ情報を参照してポリシー分岐までやりたい――このとき「Entra ID Free だけで完結するのか」「P1/P2 が必要になる条件はどこか」「Graph の呼び出しに課金があるのか」を、運用パターン別に整理します。
今回の“Free だけで完結できるか”が難しい理由
Aruba Central × Entra ID 連携では、同じ「アプリ」という言葉でも、Entra 側に大きく 2 つの面があります。
- App registrations（アプリ登録）：アプリ（クライアント）の定義。クライアント ID、シークレット/証明書、Graph の API 権限などを管理します。
- Enterprise applications（エンタープライズ アプリ）：テナント内に作られるサービス プリンシパル。SSO 設定、ユーザー/グループの割り当て、可視性（My Apps への表示）などを管理します。
Wi‑Fi 認証そのものは SAML で完結しているように見えても、「どのユーザーに使わせるか（割り当て）」を Enterprise applications 側でグループ運用したいと、ここで P1/P2 が登場します。
まず押さえる：SAML 用と Graph 用は“同じアプリである必要はない”
Aruba Central 連携では、設定手順の説明が資料ごとに違い、「SAML の設定」と「Graph を呼ぶ設定」が一つに見えて混乱しがちです。実務では次のように役割を分けて考えると整理しやすくなります。
| 用途 | Entra 側で触る場所 | 主な設定 | ライセンス論点 |
|---|---|---|---|
| SAML ベースの Wi-Fi 認証（CloudAuth SSID） | Enterprise applications（エンタープライズ アプリ） | SAML SSO、クレーム/属性、（必要なら）ユーザー/グループ割り当て | グループ割り当てを使うなら P1/P2 |
| ユーザー/グループ参照（Microsoft Graph） | App registrations（アプリ登録） | API permissions、クライアント資格情報（シークレット/証明書）、Admin consent | 基本は Free で進むことが多い（ただし権限と同意は管理者が必要） |
つまり、“Graph を呼ぶためのアプリ登録”は Free の範囲で作れても、“SAML 用のエンタープライズ アプリでグループ割り当て運用したい”と、そこで P1/P2 が必要になる、という切り分けです。
結論：Entra ID Free でできること / P1・P2 が必要になるところ
| やりたいこと | Free で可否 | 補足（P1/P2 が必要になる条件） |
|---|---|---|
| ユーザーを作成（例：3 名） | 可能 | 基本機能。テスト用ユーザー作成は Free で十分です。 |
| グループを作成し、ユーザーを所属させる（静的グループ） | 可能 | 動的グループ（ルールで自動加入）を使う場合は P1 が必要で、さらに「動的グループのメンバー各ユーザー」単位で要件が発生します。 |
| App registrations でアプリ作成 | 可能 | アプリ登録自体は一般的に Free で実施可能です（権限は管理ロールに依存）。 |
| クライアント シークレット作成 | 可能 | シークレットは最長 24 か月まで、推奨は 12 か月未満です。 |
| Microsoft Graph API 権限を追加（例：Directory.Read.All / Group.Read.All / User.Read.All 等） | 可能 | ただしアプリ権限（Application permissions）や高権限の委任権限は、管理者同意が必要です。 |
| Admin consent（管理者の同意）を付与 | 可能 | 同意を行える管理ロールが必要です。 |
| Enterprise applications 側で「ユーザーを割り当てる」 | 可能 | 個別ユーザー割り当ては可能。少人数ならこれで Free に寄せられます。 |
| Enterprise applications 側で「グループをアプリに割り当てる」 | 不可 | グループ割り当ては P1 または P2 が必要です（ネスト グループも非対応）。 |
“P1/P2 が必要かどうか”は、どの運用でアクセス制御するかで決まる
パターンA：PoC/検証で、3ユーザーだけ通ればよい（Free で完結しやすい）
最短で「Free に寄せる」なら、Enterprise applications の割り当てはユーザー個別にします。グループを割り当てない（割り当てを使わない/ユーザーのみ割り当てる）なら、P1/P2 を踏まずに検証が進められます。
- メリット：追加ライセンスの検討が後回しにできる
- デメリット：ユーザーが増えたときに割り当て管理がつらい（スケールしない）
パターンB：本番でも少人数で固定、管理は手作業で許容（Free 継続が現実的）
店舗/小規模拠点で「スタッフ数名だけ」といったケースは、個別ユーザー割り当てでも運用が回ることがあります。SSO の世界では地味ですが、“人が増えない前提”なら Free で長期運用も可能です。
パターンC：部署やロールで Wi-Fi ポリシーを分けたい（グループ運用）
ここで多くの組織がハマるのが、次の要件です。
- 「A というグループだけ SSID へ接続できる」
- 「B グループはゲスト VLAN、C グループは社内 VLAN」
- 「異動/入退社はグループの出入りだけで追従させたい」
このように Enterprise applications 側でグループ割り当てを使ってアクセス制御したい場合、Microsoft Learn 上も「グループ割り当ては P1/P2 が必要」と明記されています。
「P1 は管理者だけで足りる？」の整理（機能の解放 と ライセンス準拠）
現場で混乱しやすいのが、次の 2 つが混ざることです。
| 観点 | 意味 | 実務でのポイント |
|---|---|---|
| 機能の解放（UI/設定ができるか） | 管理画面で “グループを割り当てる” 操作ができるか | Q&A などでは「機能を解放するだけなら 1 ライセンスでいける」系の回答も見かけます。 |
| ライセンス準拠（契約上の必要数） | その機能の恩恵を受けるユーザーに適切なライセンスが割り当たっているか | Microsoft の一般的な考え方は「機能を利用（恩恵を受ける）するユーザー単位でライセンスが必要」です。 |
たとえば Microsoft Learn の別機能（グループベースのライセンス割り当て）では、“恩恵を受けるユーザーごとに必要”が明確に書かれています。グループ割り当て機能も同じ発想で見ておくと、監査/コンプライアンス面で安全です。
一方で、コミュニティや Q&A では「グループ割り当て機能を“解放”する目的なら、P1 を 1 つ購入して管理者に割り当てる」という趣旨の回答があるのも事実です。
このギャップをどう扱うかは組織のリスク許容度次第ですが、本番運用で“グループ割り当てをアクセス制御として使う”なら、割り当て対象のユーザーも P1 相当（P1 を含む SKU）を想定するほうが無難です。特に監査がある組織では、「1 ライセンスで機能だけ使う」運用は説明が難しくなります。
Microsoft Graph API 呼び出しは課金される？（結論：通常は追加費用なし、ただし例外あり）
Graph API はすべてが従量課金というわけではありません。Microsoft は Graph を大きく次の考え方で説明しています。
- 多くの API は 標準（Standard）で、定められた使用量（しきい値）内なら ユーザー サブスクリプションに含まれ、追加費用なし
- 大量データのエクスポートなどは 高容量（High-capacity）、付加価値系は 高度（Advanced）として メーター課金（Metered）になる場合がある
- メーター課金の API を使う場合は、アプリに Azure サブスクリプション紐づけが必要
今回想定の権限（Directory.Read.All / Group.Read.All / User.Read.All など）での“課金”の考え方
Wi‑Fi 認証連携でよく使うのは、ユーザー情報やグループ情報の参照（GET）です。これらは通常、メーター課金の対象として挙がりにくい領域です。安心材料として、Microsoft が公開している「メーター課金対象 API の一覧」を見ても、現時点（ページ更新日 2025-08-27）では Teams の一部や SharePoint/OneDrive の特定 API などに限られており、ユーザー/グループ読み取りがここに含まれていないことが確認できます。
ただし将来の仕様変更で対象が増減する可能性はあるため、運用前に次を押さえておくのが安全です。
| 確認ポイント | 見るべきもの | 理由 |
|---|---|---|
| 使う予定の API がメーター課金対象か | Metered APIs の一覧 | “知らない間に従量課金”を避けるため |
| メーター課金対象なら Azure サブスクリプションの紐づけが必要か | Metered API の概要・設定手順 | 紐づけがないと API が失敗する/課金の可視化ができないため |
| 課金ではなく “スロットリング” による失敗に備える | Graph の使用量しきい値/制限 | 追加費用はなくても、呼び出し過多で 429 になることがあるため |
設定の実務フロー（Entra 側だけ抜粋）
Aruba Central 側の画面は環境差が出るため、ここでは Entra 側で詰まりやすいポイントに絞って手順を整理します。
ユーザーとグループを用意する
- テスト用にユーザー 3 名を作成（例：wifi-user01〜03）
- グループを 3 つ作成（例：Wi-Fi-Staff / Wi-Fi-Partner / Wi-Fi-Guest）
- 各ユーザーをそれぞれのグループへ所属
グループで自動加入（動的グループ）にしたくなる場面もありますが、動的グループは P1 前提になりやすいので、まずは静的グループで要件を固めるのが早道です。
App registrations でアプリを登録する
- Entra 管理センターで App registrations に移動し、新規登録
- アプリ名は運用で識別しやすいものに（例：ArubaCentral-CloudAuth）
- 作成後、Application (client) ID と Directory (tenant) ID を控える
アプリ登録後の画面から API 権限の追加や管理者同意へ進みます。
クライアント シークレット（または証明書）を作成する
Aruba Central から Graph を呼ぶ場合、多くは “バックエンド同士” の認証になるため、証明書またはシークレットが必要です。実運用では証明書のほうが安全ですが、まずは検証としてシークレットでも進められます。
- シークレットの有効期限は最長 24 か月で、推奨は 12 か月未満
- 値は作成直後にしか表示されないため、安全な保管が必須
Microsoft Graph の API 権限を付与し、管理者同意する
権限は「最小権限」が基本です。とはいえ Aruba Central の要件次第で必要権限が変わるため、まずは Aruba 側ドキュメントの要件に合わせます。
| 目的 | 代表的な Graph 権限（例） | 注意 |
|---|---|---|
| ユーザー情報の参照 | User.Read.All | 委任/アプリ権限のどちらか要件に合わせる |
| グループ参照・メンバー参照 | Group.Read.All / GroupMember.Read.All | “Directory.Read.All より狭い権限”で済むか検討する |
| ディレクトリ全体の参照 | Directory.Read.All | 権限が強いので本当に必要か確認する |
権限追加後は Grant admin consent を実行します。アプリ権限（Application permissions）や高権限の委任権限は管理者同意が必要です。
Graph の疎通確認（クライアント資格情報フロー）
Aruba Central 側の設定に入る前に、Entra 側で「このアプリが Graph を読める」ことを手元で確認しておくと切り分けが速くなります。以下は代表的な確認例です（値は自環境のものに置き換えてください）。
1) トークン取得
POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
client_id={client-id}
&client_secret={client-secret}
&grant_type=client_credentials
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default2) ユーザー一覧の取得（例）
GET https://graph.microsoft.com/v1.0/users?$select=id,displayName,userPrincipalName3) 特定ユーザーの所属グループ取得（例）
GET https://graph.microsoft.com/v1.0/users/{user-id}/memberOf?$select=id,displayNameここで 401/403 になる場合は、ほぼ「シークレットの誤り・期限切れ」か「権限不足/管理者同意不足」のどちらかです。先に Graph 側で成功パターンを作っておくと、Aruba Central 側の設定に入った後も迷いにくくなります。
（必要なら）Enterprise applications 側で割り当てを設計する
ここが “Free で完結できるか” の分岐点です。
- ユーザー個別割り当て：少人数なら Free で運用可能
- グループ割り当て：P1/P2 が必要。ネスト グループも非対応。セキュリティ グループのみ対応。
運用設計としては、次の優先順位が無難です。
- 検証はまずユーザー個別割り当てで通す（無料で進める）
- 本番で人数/異動があるなら、グループ割り当て＋（必要数の）P1 を検討する
- 将来、MFA や条件付きアクセス（Conditional Access）を SSID 連携にも効かせたいなら、P1 を前提に設計し直す
Graph API を使うなら知っておきたい運用・セキュリティの勘所
最小権限に寄せる（Directory.Read.All を“最初から”入れない）
Directory.Read.All は強力で、アプリが読める範囲が広くなります。要件が「ユーザー検索」「グループ所属確認」程度なら、より狭い権限で代替できないか（例：GroupMember.Read.All など）を最初に検討すると、後からの見直しコストが減ります。
シークレット運用は “漏洩前提” で設計する
- 保管場所：パスワード管理ツール、Azure Key Vault 等の利用を検討
- 期限：短め（12 か月未満）＋計画的なローテーション
- 棚卸し：使っていないシークレットは削除
Admin consent は「最終確認ポイント」
管理者同意は強い権限を一気に付与できるため、実務では “最後に実施” が基本です。誰が同意できるのか（どの管理ロールが必要か）も事前に整理しておくと、手戻りを防げます。
トラブルシューティング（詰まりやすいポイント）
| 症状 | 原因の候補 | 対処 |
|---|---|---|
| Enterprise applications の Users and groups で、グループが選べない | プランが Free のまま（グループ割り当ては P1/P2 が必要） | ユーザー個別割り当てで回避するか、P1/P2（試用含む）を準備する |
| Graph 呼び出しが 403 になる | 必要権限が不足 / admin consent 未実施 | API permissions と Grant admin consent の状態を確認 |
| Graph 呼び出しが 401（invalid_client） | シークレット期限切れ / 値の取り違え | シークレットを再発行し、保管・更新手順を整備 |
| ネストしたグループで期待通りに割り当てが効かない | ネスト グループ非対応 | フラットなセキュリティ グループで設計する |
| 「Graph 課金が怖い」 | メーター課金対象 API を誤って使う懸念 | Metered APIs の一覧を確認。対象 API を使わないなら追加費用は基本発生しない |
まとめ：Free で始め、必要になったら P1 を“どこで使うか”で増やす
Aruba Central × Microsoft Entra ID（SAML + Microsoft Graph）連携は、アプリ登録・Graph 権限・管理者同意・ユーザー/グループ作成までは Free でも進められます。分岐点は Enterprise applications 側でグループ割り当てを使うかです。少人数 PoC は Free で走らせ、グループ運用（アクセス制御の自動化）が必要になったタイミングで P1 を検討すると、コストと運用負荷のバランスが取りやすくなります。
コメント