引き続きInternet Weekのフォローアップです。ようやく残り2回です。
いよいよStep 2の情シスとの連携開始です。
- 第1回：環境の説明、OpenAMの認証を社内ADで行う
- 第2回：OpenAMのデータストアとして社内ADを利用する
- 第3回：OpenAMとG SuiteのID連携を行う
- 第4回：OpenAMでDesktop SSOを設定する
- 第5回（今回）：Azure ADとOpenAMと連携したままのG Suiteを連携する
- 第6回：G SuiteのID連携先をOpenAMからAzure ADへ切り替える
前回まではあくまで利用部門で野良ITとしてG SuiteとOpenAMを構成し、利用者が社内ADのアカウントでシングルサインオン出来るようにしてきました。
今回は情報システム部門が重い腰をようやく上げ、Azure Active Directory（Azure AD）を契約し、これまで利用部門が独自で管理していたG SuiteのID管理やSSOを順番に巻き取っていきます。
では、早速始めていきましょう。
そのためにはAzure AD上のエンタープライズアプリケーションとしてG Suiteを登録する必要があります。
AzureポータルよりActive Directoryを開き、エンタープライズアプリケーションの追加を選択するとギャラリーが開くので、Google Appsを選択して[作成]をクリックします。
ただ、情シスが管轄している他のアプリケーションと同列で管理をしていきたいので、Azure ADでG Suite自体の管理を行うために既存OpenAMと連携する形でシングルサインオン設定を行っておきます。
クリックスタートより[シングルサインオンを構成する]を開きます。
シングルサインオンのモードとして、
がありますので、[リンクされたサインオン]を選択します。
サインオンURLにG SuiteのURLを入れることで既存でG Suiteに設定されているシングルサインオン（OpenAM）をそのまま使い続ける形でAzure ADと連携を行うことが出来ます。
取り敢えずこれでシングルサインオン設定は完了です。
この部分が利用部門の一番の負荷となっていた部分なので、これをやるだけでも相当大きなメリットがあります。
まず、Azure AD上の対象となるユーザに対してG Suiteを割り当てる必要があります。
Azure AD Premiumのライセンスがあるとグループベースでの割り当てが出来るのですが、今回用意したテナントは無償版なので、個別にユーザを割り当てる必要があります。
具体的には[ユーザとグループにシングルサインオンをデプロイする]というよくわからないメニューで割り当てを行います。
対象のユーザを選択します。
次に、G Suiteに対するプロビジョニングを有効にします。
まず、G Suite側でAPI管理を有効にしておきます。この設定を行うことでDirectory APIなどを使ってG Suite上のユーザやグループを外部から操作することが可能になります。
ここまでできたらAzure ADにG Suiteに対するプロビジョニング設定です。
今回行いたいのは、
・プロビジョニングの実行（作成・更新・削除）
・プロビジョニング属性のカスタムマッピング
です。
特に今回はAzure ADのドメイン名とG Suiteのドメイン名が異なっているので、デフォルトのマッピングだとAzure ADのuserPrincipalNameとG SuiteのLoginIDがアンマッチとなり正常にプロビジョニングされません。
そこで、社内のADのmail属性にG Suiteで使うメールアドレスをセットし、その値をAzure AD経由でG SuiteのLoginIDとマッピングすることで連携を行います。
まずは、プロビジョニングの有効化です。
これまたわかりにくいメニュー名[Google Appsでテストユーザを作成する]を開いてプロビジョニングモードを[自動]に設定します。
ここでG Suiteとの連携を行うためにAzure ADに対して管理権限を委譲します。
ここで[承認する]をクリックするとポップアップでG Suiteに対する管理権限の委譲に同意を求められるので、同意します。（G Suiteの管理権限を持つユーザでログインをします）
これで一旦保存をすると属性のマッピングを変更できるようになります。
ユーザの属性マッピングを開き、userPrincipalNameをLoginIDにマッピングしている行を選択して、ソース属性をuserPrincipalNameからmail属性に変更し保存をします。
尚、新ポータルでマッピングを変更しようとするとエラーが起きることがあります。その場合はクラシックポータルを使ってマッピングを変更してください。
これで設定は完了です。
少し時間がかかるので、ゆっくり待ちましょう。
上手くいくとG Suite上にユーザが新規に作成されます。
尚、一度もログインしたことのない新規ユーザは[停止中のユーザ]として作成され、初回ログインを行うとアクティブに変更されます。
これでID管理とシングルサインオンの両方がそろったことになりますので、テストをしてみます。
具体的には利用者からアクセスできるアクセスパネル（https://myapps.microsoft.com）から利用可能なアプリケーションとして参照・アクセスすることが可能になります。
情シスが管理している他のアプリへのシングルサインオンは当然可能です。
同じようにG Suiteへアクセスすると一瞬OpenAMへアクセスしますが、Desktop SSOが有効なのでそのままシングルサインオンされ、シームレスにログインすることが可能です。
もちろんこれまで通り、G Suiteへ直接アクセスした場合はOpenAMでシングルサインオンされますので、利用者から見た使い勝手は全く変化ありませんが、これでID管理の統合、およびほかのアプリケーションとのシングルサインオンなど、少し幅が広がりました。
次回は野良ITだったOpenAMをいよいよ撤廃してAzure ADへ一本化していきますが、利用者がほぼ気が付かない状態で移行していくのが大きなポイントとなります。
＜Step 2＞
◆Azure AD上にG Suiteを登録する
何はともあれ、情報システム部門がG Suiteを巻き取るにはAzure ADを使ってG Suiteを管理する必要があります。そのためにはAzure AD上のエンタープライズアプリケーションとしてG Suiteを登録する必要があります。
AzureポータルよりActive Directoryを開き、エンタープライズアプリケーションの追加を選択するとギャラリーが開くので、Google Appsを選択して[作成]をクリックします。
◆既存OpenAMと連携したシングルサインオン設定を行う
最終的にはAzure ADを使ってシングルサインオンも行うように構成しますが、現在はOpenAMが存在しますので、十分なテストが完了するまでは、引き続きOpenAMを使っておきたいところです。ただ、情シスが管轄している他のアプリケーションと同列で管理をしていきたいので、Azure ADでG Suite自体の管理を行うために既存OpenAMと連携する形でシングルサインオン設定を行っておきます。
クリックスタートより[シングルサインオンを構成する]を開きます。
シングルサインオンのモードとして、
- Azure ADシングルサインオンが無効
- SAMLベースのサインオン
- パスワードベースのサインオン
- リンクされたサインオン
がありますので、[リンクされたサインオン]を選択します。
サインオンURLにG SuiteのURLを入れることで既存でG Suiteに設定されているシングルサインオン（OpenAM）をそのまま使い続ける形でAzure ADと連携を行うことが出来ます。
取り敢えずこれでシングルサインオン設定は完了です。
◆ID管理（プロビジョニング）をAzure ADから行うように設定する
次はプロビジョニングです。これまで利用部門が手動でG Suite上のIDの作成、削除をしてきましたが、この部分をAzure ADから自動的に行います。（もちろんAzure ADは社内のADとAzure AD Connectを経由して同期されているので、社内ADのIDの作成・更新・削除がそのままAzure ADを経由してG Suiteまで反映されるようになります）この部分が利用部門の一番の負荷となっていた部分なので、これをやるだけでも相当大きなメリットがあります。
まず、Azure AD上の対象となるユーザに対してG Suiteを割り当てる必要があります。
Azure AD Premiumのライセンスがあるとグループベースでの割り当てが出来るのですが、今回用意したテナントは無償版なので、個別にユーザを割り当てる必要があります。
具体的には[ユーザとグループにシングルサインオンをデプロイする]というよくわからないメニューで割り当てを行います。
対象のユーザを選択します。
次に、G Suiteに対するプロビジョニングを有効にします。
まず、G Suite側でAPI管理を有効にしておきます。この設定を行うことでDirectory APIなどを使ってG Suite上のユーザやグループを外部から操作することが可能になります。
ここまでできたらAzure ADにG Suiteに対するプロビジョニング設定です。
今回行いたいのは、
・プロビジョニングの実行（作成・更新・削除）
・プロビジョニング属性のカスタムマッピング
です。
特に今回はAzure ADのドメイン名とG Suiteのドメイン名が異なっているので、デフォルトのマッピングだとAzure ADのuserPrincipalNameとG SuiteのLoginIDがアンマッチとなり正常にプロビジョニングされません。
そこで、社内のADのmail属性にG Suiteで使うメールアドレスをセットし、その値をAzure AD経由でG SuiteのLoginIDとマッピングすることで連携を行います。
まずは、プロビジョニングの有効化です。
これまたわかりにくいメニュー名[Google Appsでテストユーザを作成する]を開いてプロビジョニングモードを[自動]に設定します。
ここでG Suiteとの連携を行うためにAzure ADに対して管理権限を委譲します。
ここで[承認する]をクリックするとポップアップでG Suiteに対する管理権限の委譲に同意を求められるので、同意します。（G Suiteの管理権限を持つユーザでログインをします）
これで一旦保存をすると属性のマッピングを変更できるようになります。
ユーザの属性マッピングを開き、userPrincipalNameをLoginIDにマッピングしている行を選択して、ソース属性をuserPrincipalNameからmail属性に変更し保存をします。
尚、新ポータルでマッピングを変更しようとするとエラーが起きることがあります。その場合はクラシックポータルを使ってマッピングを変更してください。
これで設定は完了です。
◆プロビジョニングを実行する
プロビジョニングを[オン]にしてG Suiteへプロビジョニングを実行します。少し時間がかかるので、ゆっくり待ちましょう。
上手くいくとG Suite上にユーザが新規に作成されます。
尚、一度もログインしたことのない新規ユーザは[停止中のユーザ]として作成され、初回ログインを行うとアクティブに変更されます。
これでID管理とシングルサインオンの両方がそろったことになりますので、テストをしてみます。
◆Azure ADを経由してアクセスしてみる
Azure ADにG Suiteを登録したとはいえ、実際にシングルサインオンを行うのはOpenAMです。しかし、Azure ADに登録したことにより、Azure ADに登録された他のアプリケーションと同列でアプリケーションへのアクセスを管理することが可能になります。具体的には利用者からアクセスできるアクセスパネル（https://myapps.microsoft.com）から利用可能なアプリケーションとして参照・アクセスすることが可能になります。
情シスが管理している他のアプリへのシングルサインオンは当然可能です。
同じようにG Suiteへアクセスすると一瞬OpenAMへアクセスしますが、Desktop SSOが有効なのでそのままシングルサインオンされ、シームレスにログインすることが可能です。
もちろんこれまで通り、G Suiteへ直接アクセスした場合はOpenAMでシングルサインオンされますので、利用者から見た使い勝手は全く変化ありませんが、これでID管理の統合、およびほかのアプリケーションとのシングルサインオンなど、少し幅が広がりました。
次回は野良ITだったOpenAMをいよいよ撤廃してAzure ADへ一本化していきますが、利用者がほぼ気が付かない状態で移行していくのが大きなポイントとなります。
投稿
