引き続きInternet Weekのフォローアップです。いよいよ最終回です。
利用部門で勝手に構築したOpenAMを完全に撤廃して、情シス管理のAzure Active Directory(Azure AD)にすべてをゆだねます。
- 第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へ切り替える
すでに前回、G SuiteへのID管理(プロビジョニング)はAzure ADで実施する様に構成し、シングルサインオンについても経過期間ということでOpenAMと連携する様に設定を行いました。
今回はG SuiteとOpenAMの連携を解除し、Azure ADと直接連携することでOpenAMを使わないようにします。
では、早速初めて行きます。
<Step 3>
◆G SuiteとAzure ADのシングルサインオン設定をSAMLベースへ変更する
前回は、既存のOpenAMを活用するためにAzure AD上に登録したG Suiteのシングルサインオン設定に「リンクされたサインオン」を選択しましたが、今回からはG SuiteとAzure ADを直接連携させるため、ここの設定を「SAMLベースのサインオン」へ変更します。SAMLを使って連携する属性を編集します。
今回、メールアドレス属性にGoogleで使うログインIDが入っていますので、ユーザ識別子として「user.mail」を指定します。
また、デフォルトでgivenNameやsurNameなどがAttributeStatementに含まれるように構成されますが、日本語の値が入っているとGoogle側でエラーになるので、不要な属性は削除しておきます。
この辺りは以前紹介した注意事項を参照してください。
次にSAMLアサーションに署名するための証明書を作成します。
注意)ここで証明書をダウンロードしてG Suiteへアップロードするのですが、現在新ポータルでダウンロードした証明書をアップロードするとG Suiteがエラーを出しますので、ここだけクラシックポータルへアクセスして証明書をダウンロードしてください。
G Suiteの出すエラー
クラシックポータルでの証明書ダウンロード
後は、G Suiteへ設定するAzure AD側のエンドポイント情報を確認します。
Google Appsの構成メニューを選択すると右側に設定すべきエンドポイントの情報が出てきますので、これをコピーしておきます。
◆G Suite側の設定を更新する
ここまでくればあとは、G Suite側へ設定を入れるだけです。先ほどメモしたログインページのURL、ログアウトページのURL、パスワード変更URLを入力し、証明書をアップロードします。
尚、この設定を行っている間(Azure ADで設定変更~保存、G Suite側の保存)はシングルサインオン設定がAzure ADとG Suite側でズレているので利用者へ影響が出ますので、事前にアナウンスをしてから実施する様にしましょう。
◆動作確認を行う
これで、設定は完了です。後は動作確認をしてみます。
ドメイン参加したPCでアクセスパネル(https://myapps.microsoft.com)へアクセスします。
Azure ADと連携されたドメインに参加しているので、Desktop SSOが有効なのでAzure ADのログイン画面が表示されることなくパネルへアクセスできます。
ここでGoogle Appsをクリックし開くとシングルサインオンされます。この際、前回までの構成だと一旦OpenAMへアクセスしていましたが、今回からは直接Azure ADと連携しているのでOpenAMを経由することなくG Suiteへアクセスしていることがわかります。
※もちろん、アクセスパネルを経由せずに直接G SuiteへアクセスしてもDesktop SSOが実行されるので、ユーザは何も意識することはありません。
後は、OpenAMを停止するだけです。
ようやく利用部門が抱えていた認証基盤およびアプリケーションの管理がすべて情報システム部門へ移管されました。
めでたし、めでたし。
◆最後に
今回、Internet Week向けのデモということであまり情シス目線だけに閉じたものはやめておこうというコンセプトで今回のコンテンツを作成しました。また、オーディエンスが技術者の方が中心ということもあり、家に帰ってすぐに試せるもの、というのも大きなテーマでしたので、あえてOpenAMを引っ張り出してきました。
なかなか実世界では考えにくいシナリオだったかもしれませんが、技術要素としてのSAMLやKerberosを使ったDesktop SSOなどは覚えておいても損はありませんので、少しでもエッセンスが伝われば幸いです。
0 件のコメント:
コメントを投稿