1. 前回までのおさらい
皆様こんにちは！ストレージ担当の島田です。
中編では、Microsoft Entra ID 側の準備に加えて、PowerStore 側でも SSO 連携に必要な土台づくりまでを進めました。
※本記事は後編です。前編、中編が未読の方は以下のリンクから是非！
前編
後編では、その続きとして PowerStore 側の設定を完了させ、実際の SSO ログイン確認と、検証を通じて見えてきたポイントを整理していきます。
2. アジェンダ
後編では、PowerStore 側の設定を完了させ、実際に SSO ログインできるところまで確認していきます。
そのうえで、検証を通じて見えてきたハマりどころや、MFA を実運用で考える際のポイントも整理します
3. PowerStore 側の設定（後半）
前回は、PowerStore の IdP CA 証明書チェーンの取り込みまでを行いました。後編では、その続きとして OIDC 接続情報の入力から進め、PowerStore 側の設定を完了させていきます。
実施したこと
- OIDC 接続情報の入力
- Claim Mapping の設定
- Role Mapping の設定
- Test Configuration の実行
- 問題なければ SSO の有効化
※本記事の手順は検証環境で確認した内容です。実環境へ適用する際は、要件や運用方針に応じて十分に検討したうえで実施してください。
3-1. OIDC 接続情報の入力
次に、Entra 側で取得しておいた OIDC 接続情報を PowerStore に入力しました。今回使用した主な値は以下です。
- Client ID
- Client Secret
- Metadata URL
これにより、PowerStore は Entra ID を OIDC の IdP として利用できるようになります。
3-2. Claim Mapping/Role Mapping の設定
OIDC 接続情報の入力後、PowerStore 側で claim の対応付けを設定しました。
- IdP Claim Name:
upn - PowerStore Label:
User_Name
この設定により、Entra 側の ID トークンに含まれる upn を、PowerStore 側では User_Name として扱えるようになります。
さらに、その User_Name に対して Role Mapping を設定することで、PowerStore 上の権限を決定します。
Claim Mapping の次に、PowerStore 側で Role Mapping を設定しました。
User_Name = psadmin01@powerstorelab.onmicrosoft.comRole = Administrator(管理者)
つまり、PowerStore は User_Name に入ってきた値を見て、そのユーザーにどの権限を与えるかを判断します。今回は検証用ユーザーを Administrator として扱う設定にしました。
3-3. Test Configuration の実行
設定完了後は、すぐに有効化せず、まず Test Configuration を実行しました。ここで確認したことは以下です。
- Entra のログイン画面へ正しくリダイレクトされるか
- Entra 側の認証が通るか
- PowerStore が
upnを受け取れているか - Role Mapping により Administrator ロールが付与されるか
最終的に、以下の状態まで確認できました。
- IdP Claim Name:
upn - Storage System Claim Name:
User_Name - Claim Value:
psadmin01@powerstorelab.onmicrosoft.com - Role(s) On Storage System:
Administrator
ここまで通ったことで、PowerStore 側の SSO 設定と権限付与の流れが正しく成立していることを確認できました。
3-4. 問題なければ SSO を有効化
Test Configuration が成功した後、PowerStore 側で SSO を有効化しました。
この手順では、いきなり本番有効化するのではなく、
- 設定作成
- テスト実行
- 問題がなければ有効化
という順番で進めました。今回のような認証系の設定では、この順番のほうが安全です。
3-5.実際に試してみる
Test Configuration の成功後、実際に PowerStore のログイン画面から SSO ログインを試しました。
ブラウザは Microsoft Entra ID のサインイン画面へリダイレクトされ、認証後に PowerStore Manager へ戻ります。今回の検証では、Entra ID 側の認証だけでなく、PowerStore 側で Role Mapping により Administrator 権限が付与され、管理画面へログインできることまで確認できました。
これにより、SSO、claim の受け渡し、Role Mapping、権限付与までの一連の流れが成立していることを確認できました。
3-6.ユーザーを増やしたい場合
ユーザーを増やしたい場合は、Entra 側でユーザーを追加し、PowerStore 側でそのユーザーに対応する Role Mapping を追加します。
SSO 設定自体を作り直す必要はなく、既存の連携を使ったまま、User_Name に対して必要なユーザーとロールを追加していく形です。認証を Entra ID 側で一元化しつつ、PowerStore 側では権限管理に集中できるのがこの構成の利点です。
PowerStore 側設定の要点
今回の PowerStore 側設定で重要だったのは、次の三点です。
- Entra 側との OIDC 信頼関係を正しく作ること
upnをUser_Nameに正しくマッピングすることUser_Nameに対する Role Mapping を正しく設定すること
特に、SSO が通ること と PowerStore 上で権限が付くこと は別の話です。今回の検証では、Entra 側で認証されたユーザー情報を PowerStore が受け取り、それをもとに Role Mapping で Administrator を付与するところまで確認できました。
4. 実際にハマったポイント
今回の検証では、SSO 自体の成立よりも、その後の権限付与や信頼関係の整理において見えてくる論点が多くありました。
4-1. 認証と権限付与は別だった
Entra ID で認証が成功しても、それだけで PowerStore にログインできるわけではありませんでした。PowerStore 側では、受け取った claim をもとに Role Mapping で権限を付与して初めてログインが成立します。
4-2. PowerStore 側では信頼関係の設定も必要だった
Entra 側でアプリ登録をして値を用意するだけでは足りず、PowerStore 側では CA 証明書チェーンの取り込みや metadata / OCSP / CRL への到達性も必要でした。
5. MFA 検証で見えたこと
今回の検証で分かったのは、SSO の成立と MFA の適用は分けて考える必要がある、ということです。
今回の検証では Security Defaults を起点に確認しましたが、実運用を考えると、PowerStore 用アプリに対してどのように MFA を当てるかまで設計が必要になります。
その観点では、PowerStore 用アプリに対して MFA を明示的に制御したい場合、Conditional Access も今後の検討対象になります。
6. まとめ
今回の検証を通じて、PowerStore は Microsoft Entra ID と連携し、ストレージ管理の認証を既存の認証基盤に統合できることを確認できました。単に SSO でログインできるだけでなく、claim と Role Mapping を使って PowerStore 側の権限まで制御できる点は、管理認証の強化という観点でも有効です。
ストレージ管理は、サーバーやクラウドと比べると認証強化の議論が後回しになりがちですが、実際には非常に強い権限を扱う重要な管理ポイントです。その意味で、PowerStore が既存の認証基盤と連携し、管理認証の統合や強化に対応できることは、大きな価値だと感じました。
今後、ストレージ管理のセキュリティ強化や、管理アカウント運用の見直しを検討する場面では、PowerStore と Microsoft Entra ID の連携は十分に現実的な選択肢になるはずです。
最後まで、読んでいただきありがとうございました！
Networld Techのブログ一覧はこちら！
https://www.networld.co.jp/product/dell_technologies/tech-blog
