ルート組織SSOと組織向けの3rd SSOの切り替えの検証

検証１-１  ssotest user04 はCloudgate sso経由でログインできること

操作手順：

①　ルート組織直下にssotest user04が存在することを確認します。

②　ルート組織の下に既存のsoftbank_unitalkサブ組織が存在することを確認します。

③　ssotest-user04のGoogleアカウントにログインします。

④　アカウントに入力すると、CloudGate SSOのログイン画面に飛ばされるので、ssotest-user04と連携しているユーザーID（maz84sso）を代わりに入力します。

⑤　user04のログイン成功を確認できます。

検証１-２  adsso user01 はCloudgate sso経由でログインできること

①　サブ組織softbank_unitalkの下にadsso　user01が存在することを確認します。

②　adsso-user01のGoogleアカウントにログインします。

③　アカウントに入力すると、CloudGate SSOのログイン画面に飛ばされるので、adsso-user01と連携しているユーザーID（maz83sso）を代わりに入力します。

④　 ado user01がログイン成功を確認できます。

検証１-３  グループ配下のアカウントはCloudgate sso経由でログインできること

①　グループsso_group_testの下にuser01とuser02が存在することを確認します。

②　ssotest-user02のGoogleアカウントにログインします。

③　アカウントに入力すると、CloudGate SSOのログイン画面に飛ばされるので、ssotest-user02と連携しているユーザーID（maz82sso）を代わりに入力します。

④　ssotest-user01がログイン成功を確認できます。

  Phase２

検証２-１ルート組織下のuserをReplace domainに移動してAzureADでログインできること

ルート組織「dev.ep-cloud.jp」直下のユーザー（user04）を臨時のサブドメイン「Replace domain」に移動させ、3rd SSOのAzureADをつけた後ログインができます。

①　ルート組織dev.ep-cloud.jpの下にReplace_domainを作成し、ssotest user04が中に存在します。

②　GWSコンソールの「SSOプロファイルの割り当ての管理」の Replace_domainにAzureAD_SSOで紐付けます。

③　アカウントに入力すると、AzureAD SSOのログイン画面に飛ばされるので、ssotest-user04のメールアドレスを入力すると、ログインができます。

④　ssotest-user04が成功にログインすることを確認します。

検証２-２サブ組織配下のuser03をmigrate_ssotestに移動してAzureADでログインできること

サブ組織softbank_unitalk配下のuser03を新しく作成したmigrate_ssotestに移動させ、3rd SSOのAzureADで紐づけます。

① 元々サブ組織softbank_unitalkの下にadsso　user01が存在することを確認します。

② 元々新しく作成したサブ組織migrate_ssotestの下に何のアカウントも存在しないことを確認します。

③ adsso_user01をサブ組織softbank_unitalkからmigrate_ssotestに移動します。

④  migrate_ssotestにssotest user03が存在することを確認します。

サブ組織softbank_unitalk配下のuser03を新しく作成したmigrate_ssotestに移動させ、3rd SSOのAzureADをつけます。

①  GWSコンソールの「ssoプロファイルの割り当ての管理」に3rdのSSOであるAzureADをmigrate_ssotestに紐付けます。

②  AzureADをmigrate_ssotestに紐付けてから、migrate_ssotest配下のaadsso-user01でログインしてみます。

③　アカウントに入力すると、CloudGate SSOではなく、AzureADのログイン画面に飛ばされるので、adsso-user01@dev.ep-cloud.jpでログインします。

④ adsso-user01@dev.ep-cloud.jpがログイン成功を確認できます。

検証２-３　グループssogroup_testに3rd SSOのAzureADをつけてログインできること①

①  グループSSO_group_testを選択します。

②  グループSSO_group_testを「別のSSOプロファイル」である「AzureAD_SSO-SAML」にオーバーライドします。

ssotest-user01がAzureAD SSO経由でログインできることを確認します。

検証２-３　グループssogroup_testに3rd SSOのAzureADをつけてログインできること②

※ssogroup_testというグループ内で2つの検証ユーザーがあるため、検証2-3 は２人目のユーザーがAzureADをつけてログインできるかを確認します。

上記の操作手順によって、Phase２は完了となります。

  Phase３

検証３-１　Replace domainにあるユーザーはAzureADでログインできること

Replace_domainに対し、SSOプロファイルの割り当ての管理にて、事前に作成したAzure_SSO_SAMLで紐つけます。

Replace_domainにssotest user04が存在することを確認しました。

上記の操作を行うことで【検証3-1】ログインが成功しました。

検証３-２　Migrate_ssotestにあるユーザーが3rd SSOのAzureADでログインできること

migrate_ssotestにssotest_user03が存在することを確認しました。

ssotest user03がAzureADSSO経由でログインするプロセスをこちらをご確認ください。

検証３-３　ssogroup_testにあるユーザーがAzureADでログインできること

①  グループSSO_group_testを選択します。

②  グループSSO_group_testを「別のSSOプロファイル」である「AzureAD_SSO-SAML」にオーバーライドします。

ssogroup_testの２つのアカウントがAzureADSSO経由でログインするプロセスをこちらをご確認ください。

  Phase４

検証４-１　dev.ep-cloud.jpにあるユーザーがAzureADでログインできること

①　組織向けの３rdのSSOプロファイル（CloudGate）をオフにした後、AzureAD SSOへ変更しました。

②　ssotest user04をサブ組織Replace_domianからdev.ep-cloud.jpへと移動しました。

上記の操作を行うことで【検証4-1】ログインが成功しました。

検証４-２　Migrate_ssotest配下のユーザーが組織向けの3rdのSSOでログインできること

①　migrate_ssotestを「組織向けの3rdのSSOプロファイル」で紐付けます。

②　migrate_ssotestにssotest user03が存在することを確認します。

上記の操作を行うことで【検証4-2】ログインが成功しました。

検証４-３　ssogroup_test配下のユーザーが組織向けの3rdのSSOでログインできること

グループSSO_group_testを「組織向けの3rdのSSOプロファイル」で紐付けます。

上記の操作を行うことで【検証4-3】ログインが成功しました。

まとめ

・検証の際に、AzureADもCloudgateも事前にGWSと連携するアカウントを作成し、Google Workspaceのサービスを有効にする必要があります。ただし、実際の大人数の移行の場合に、オンプレやクラウド上のアカウントをAzureADやCloudgateに一括追加、或いは同期することができます。

・サブ組織に割り当てられた3rd SSOプロファイルを変更すると、そのサブ組織下のユーザーが直ちに（1minをかけず）指定の3rd SSOでのログインに切り替えたことを確認しました。ただし、実際移行の際に組織下の人数が多くなると、反映時間がもっとかかるかどうかについて更に検証する必要があります。

・Phase3まで実施すると、全組織のユーザーのログインが無事にCloudgateからAzureADに移行できます。ただし、それは各サブOUを AzureAD SSOに直接割り当てた安全的な移行結果です。

・もしPhase4を実施すると、直接ルート組織にAzureAD SSOで割り当てると、理論上で組織全体のSSOログインは移行できるはずですが、組織全体一時的にログインできなくなるリスクが存在するため、Phase3までの操作を勧め、良いタイミングにまたPhase4の実施を検討してもよいと考えます。

・検証後の所感として、各サブ組織のSSO移行完了後、またルート組織のSSOプロファイルをAzureADに変更し、サブ組織に割り当てられたAzureAD SSOプロファイルを１個ずつオフにし、ルート組織のSSOプロファイルはうまく機能すると考えます。或いは、組織向けのSSOをやめて、サブ組織にAzureAD SSOプロファイルを直接的に割り当てたほうが楽かもしれません。

本記事の検証内容をご覧頂くことによって、SSO利用或は変更を検討されているお客様にお役に立つことができれば光栄です。