【備忘】Cloud Identity（Idp）とO365・AzureAD（SP）連携検証③
【備忘】Cloud Identity（Idp）とO365・AzureAD（SP）連携検証②の続きです。今回はプロビジョニングを試します。
(再掲)今回やりたいこと
今回は、最終的にはCloud Identity（Idp）とO365（SP）を連携する検証を個人の勉強として行いたいです。
組織のGCPやAzureADには触れずに設定の検証を行いたいため、自前のGCP・Azureのお勉強環境を利用し、できるところまでやってみます。（そしてお金はかけたくない）
この投稿はその作業履歴・備忘です。
イメージはこちら👇
画像はリファレンスアーキテクチャより一部引用しています。
前回までで、SAML連携を利用したO365利用時のCloudIdentity認証を試しました。今回は「手順 7: 自動プロビジョニングを設定する」が無料お試し枠内でできるかどうか試します。
流れは、以下の通りです。
手順 1: ImmutableID を設定する
手順 2: Google ID プロバイダ（IdP）の情報を入手する
手順 3: Office 365 を SAML 2.0 のサービス プロバイダ（SP）として設定する
手順 4: Google を SAML ID プロバイダ（IdP）として設定する
手順 5: Office 365 アプリケーションを有効にする
手順 6: Google と Office 365 間の SSO の動作を確認する
ーーーー（今回投稿ここから👇）ーーーーーーーーーーーー
手順 7: 自動プロビジョニングを設定する
事前準備
自動プロビジョニングに必要なライセンスの環境を整えます。
こちらのライセンス比較のページを見ると、「Business Starter」で自動プロビジョニングができそうです
こちらの管理コンソールの「お支払い」＞「その他のサービスの使用」から「無料試用を開始」をぽちっと
無料試用版の購入が完了しました。
「サブスクリプション」画面でも、「Google Workspace Business Starter」が表示されています
手順 7: 自動プロビジョニングを設定する
本題の自動プロビジョニング手順に戻ります
アプリ>ウェブアプリとモバイルアプリ>Microsoft Office 365
の画面にもどると、自動プロビジョニングが設定できそうになっています。
[承認] をクリックする前に Office 365 の管理者アカウントでログインしていない場合は、同じタブで Office 365 アプリケーションが開き、ログインを求められます。
SAML連携したO365テナントの管理アカウントでログイン
管理者の同意画面が表示される
次にGoogle側の認証画面に遷移します。一番下の管理権限のユーザーで続行
Microsoft Office 365 のすべての必須属性（* が付いているもの）が Google Cloud Directory の属性にマッピングされていることを確認します。マッピングされていない場合は、下矢印アイコン をクリックして、適切な属性にマッピングします。
とのことなので、値を設定します。
一部選択されていない項目があったため、以下の通り設定して続行します。
グループの指定ができるようなので、グループを作り、同期対象に設定してみます。
プロビジョニング解除の設定。実際の運用となるときちんと設計が必要な箇所になりそうですが、今回は動作検証のためいったんデフォルトで「完了」
「自動プロビジョニング」がオンにできそう
こんな注意喚起文言が・・
オンになりました。
ログを見ると、同期用グループに含まれるユーザーが同期され、含まれないユーザー（前回手動で連携させたユーザー）が停止されていることがわかります。
なるほど。
O365・AzureAD側を見ると設定されたとおりに同期されています。ぱちぱち。
最後に
無料枠内で、CloudIdentity（GWS）→AzureAD（O365）のプロビジョニングが確認できました。
もちろんプロビジョニングされたアカウントでO365にログインできました。
イメージでは理解していたプロビジョニングを実装することで、連携までの流れや実際の挙動を確認でき、理解が深まりました。
多少試行錯誤した箇所がありましたが、本内容が、どなたかのお役に立つと嬉しいです。
この記事が気に入ったらサポートをしてみませんか？