AzureADのテナント間同期を設定してみた
はじめに
前回、下の記事にてAzureADのテナント間同期機能の机上確認をしました。
今回は改めて、AzureADのテナント間同期を設定して機能確認していきます。
設定手順
参考にしたドキュメントは下記の通りです。後から見返した時のため、こういうリンクを残しておくのも大事ですね。
-
②ターゲットテナント上でのライセンス設定手順
https://learn.microsoft.com/ja-jp/azure/active-directory/external-identities/external-identities-pricing
前提条件の確認
①の手順に記載のある前提条件を確認します。
ソーステナント
Azure AD Premium P1 または P2 ライセンス
テナント間アクセス設定を構成するためのセキュリティ管理者ロール
テナント間同期を構成するためのハイブリッド ID の管理者ロール
構成へのユーザーの割り当てと、構成の削除を行うクラウド アプリケーション管理者またはアプリケーション管理者ロール
ターゲットテナント
Azure AD Premium P1 または P2 ライセンス
テナント間アクセス設定を構成するためのセキュリティ管理者ロール
今回は検証なので両テナントの強権限（グローバル管理者）で進めてしまいます。
ですが、ライセンス周りだけは確認が必要ですね。この「テナント間同期」機能を使う場合、同期対象となるユーザー分、ソース/ターゲットテナントそれぞれでP1/P2ライセンスのどちらかが必要となるようです。
事前設定（ライセンス周り）
ソーステナントでは、必要なユーザー数分のP1ライセンスを持っているものとします。
ターゲットテナント（ゲスト招待する側）では、いくつのP1ライセンスが必要になるのでしょうか？
元々AzureADの世界では、ゲストユーザー分のP1ライセンスはちょっと特殊ルールがあり、通常用のライセンス１に対して５ゲストユーザーまでOKというルールになっていました。
ですが、最近（？）では【1 か月間に認証アクティビティを行った一意のユーザーの数である、月間アクティブ ユーザー数 (MAU) に基づいた】課金モデルというものが出てきています。
（②のドキュメントより引用）
また、50000 MAUまでは無料とのこと。AzureAD B2Bのゲストユーザーの使い方かつ、テナント間同期を使うパターン（同じ組織内だけどAzureADが別れている場合に使うことを強く推奨）だと、実質無償化では？？50000人以上のアクティブユーザーが居る組織って、なかなか無いですからね。
B2Cのパターンだと、50000ユーザーを超えるのはざらにあるとは思いますが…
そこで、この②に従ってターゲットテナント側でライセンスに関する設定を行います。
Microsoftではライセンスが紳士協定になっていることが多く、「今のこの状態で違反してないだろうか…」とガクガクブルブルするものですが（言い過ぎ）、今回のこの設定はシンプルで分かりやすいですね。違反になることなく、ちゃんと請求してくれるというのもだいぶありがたいです。
設定作業
「AzureAD＞External Identities＞リンクされたサブスクリプション」よりリンク状態を確認します
今の時点では、状態：リンクされていませんになっています。
「サブスクリプションへのリンク」を設定します。
対象となるサブスクリプションとリソースグループを設定します。
「リソースグループ」を指定する理由はドキュメントには記載されておらず…。
おそらく、課金の対象として識別するためのと思われます。
ちなみに、「Microsoft.AzureActiveDirecotry」のリソースプロバイダが登録されてないとエラーになります。（なりました。）
新サービスを使いだすときに、自動的にリソースプロバイダが有効化される場合もありますが、この「リンクされたサブスクリプション」の設定では手動で有効化する必要がありました。（2022/2現在）
無事設定できると、「お使いのテナントのサブスクリプション」一覧のステータスが更新されます
設定
それでは、メインの「テナント間同期」の設定作業を行います。
冒頭に記載した手順①に従って進めます。
手順 1:プロビジョニングのデプロイを計画する
制約や全体構成を検討します。特別難しいことは無いので、ドキュメントを読んでみましょう。
ターゲットテナント
手順 2: ターゲット テナントでユーザーの同期を有効にする
まず、「AzureAD＞External Identities＞テナント間アクセス設定」にて、「組織の追加」を行います。
ソースとなるテナントのドメイン名を入力し、正しい名前が表示されたことを確認して「追加」します。
続けて、追加された組織の「受信アクセス」欄の「規定値から継承」というリンクをクリックし、
テナント間同期を「受ける」ことを有効にします
手順 3: ターゲット テナントで招待を自動的に引き換える
「信頼の設定」タブにて、2か所のチェックを有効化します。
-
AzureADテナントからの多要素認証を信頼する
1点目は、「ソーステナント側でMFA認証を受けたユーザーが、ターゲットテナントにディレクトリを切り替えたときに再度MFAを求められないようにする」設定です。 -
他のテナントのユーザーが、自分のテナント内の…表示しないようにする
2点目は、ゲストユーザーの初回ログイン時に、「いいよね？」という同意プロンプトが表示されないようにするオプションです。
「同じ組織内で使っている」ことを前提とした「テナント間同期」により同期されてゲストユーザーを作成しますので、有効で問題ないと考えられます。
どちらも必須の設定ではありませんが、設定する便利です…という機能です。
ソーステナント
手順 4: ソース テナントで招待を自動的に引き換える
ソーステナント側でも、手順2および手順3の2点目と同じ設定を行います。
一か所だけ、「受信アクセス」ではなく「送信アクセス」側から設定するところに注意します。
手順 5: ソース テナントで構成を作成する
Azure Active Directory ＞ テナント間同期 (プレビュー)を選択し、
メニューの「構成」＞ 「新しい構成」と進めます。
適当な名前を入れて作成すると、
構成名が保存されます。（この時点では中身は空っぽです。）
この設定、同期先となるターゲットテナント毎に作成することになるので、Fromテナント、Toテナントが識別できる名前を付けるのが良いでしょう。
手順 6: ターゲット テナントへの接続をテストする
手順5で追加された「構成」をクリックし「Get Started（作業の開始）」ボタンを押下します。
続けて表示される「プロビジョニング」画面で、画面の通りに設定します。
なおこの時、ターゲットテナントの「テナントID」が必要にあります。ドメイン名では設定できないことに注意です。
エラーなく保存出来たら、一度「プロビジョニング」画面を閉じます。
手順 7: プロビジョニングの対象となるユーザーを定義する
プロビジョニング＞設定画面にて、スコープを設定します。設定値は2択です。
- すべてのユーザーとグループを同期する
- 割り当てられたユーザーとグループのみを同期する
前者にするとテナント内の全ユーザ、後者にすると次の手順で設定するユーザーのみになります。まず検証の段階では、後者にして絞って試すのが良いと思います。（画面上は「すべて」にしてあります）
絞る場合は、続けて「ユーザーとグループ」メニューを開き、「ユーザーまたはグループの追加」ボタンを押下します。
初期のテストの際や、特定グループだけ同期したい…という要件があるときは設定を行います。
例えば、「IT部門のユーザーグループのみ、開発用のAADテナントに同期させたい…」みたいなシーンがあるのではないでしょうか。
手順 8: (省略可能) スコープ フィルターを使用してプロビジョニングのスコープ内のユーザーを定義する
プロビジョニング＞マッピングセクションにて、同期元となるソースオブジェクトをフィルタすることができます。
「特定の部署所属」など、AADユーザーの属性を元にフィルターすることが出来ます。
手順 9: 属性マッピングを確認する
さらにマッピングの設定にて、各属性を同期の対象とするかどうか、設定値が無かった場合にどうするか（規定値を決めるかどうか）など詳細を設定できます。
ドキュメントで紹介されているのは「userType」属性です。既定では「Member」という値が設定されますが、今回「Guest」に置き換えてみました。
詳細は割愛しますので、ドキュメント②やその先の参考リンクをご参照ください。
手順 10: 追加のプロビジョニング設定を指定する
同期ジョブがエラーになった際などの、通知先メールアドレスや、誤削除防止のための設定を追加します。（実は手順7の画面にて設定済です。）
手順 11: オンデマンドのプロビジョニングをテストする
構成内で「Provision on demand（要求時にプロビジョニング）」メニューを選び、特定のユーザーを指定して同期を試すことができます。
無事同期できている場合、下記のようなログで全て「Success」となりました。
手順 12: プロビジョニング ジョブを開始する
最後に、同期ジョブを開始します。40分に一度、繰り返し同期が行われますので、一度有効化すれば後は放っておくだけです。
構成メニューの「概要」ページにて、「プロビジョニングの開始」ボタンを押下します。
手順 13: プロビジョニングを監視する
無事にプロビジョニングが進むと、「現在のサイクルの状態」表示や、同期されたユーザー数がカウントされます。
「プロビジョニングログの表示」を押下すると、詳細な（ユーザー毎の）同期の要否判断や成否などが表示されますので、トラブルシュートの際などは必要に応じて参照します。
以上で設定は終了です。長く感じますが、慣れれば簡単で、設定内容自体はシンプルだと思います。
動作確認
いくつか「こうなったときに同期はどうなるの？」を確認しました。
ホームテナントでユーザー追加した場合
ターゲットスコープに含まれるように、ユーザーを追加します。
何も追加操作を行わなくても、次のサイクルで自然と同期され、ターゲットテナントのゲストユーザーとして作成されます。
ターゲットテナント側でゲストユーザーを削除した場合
放っておいても、ゲストユーザーの再作成は行われません。
どうやら、「ソーステナント側で前回同期時との差分をチェックして、差分が無ければ同期を行わない」という挙動のようです。
プロビジョニングログ上も、特に何も表示されませんので、同期すら行われない模様です。
さらに、ホームテナントでユーザー属性を弄った場合
「ソーステナント側で差分を検知」できる状態にしてあげることで、次のサイクルで再同期され・・・るのですが、同期には失敗しました。
どうやら「Update」として認識しているので、ゲストユーザーが削除されてしまっている場合はCreateにならずUpdateに失敗する…という挙動のようでした。
この場合の復活方法は追って検証してみたいとおもいます。
おわりに
以上のように、AzureADのテナント間同期機能を検証しました。ドキュメント通り設定でき、動作しますので、特に困ることは無さそうでした。
ただ、同期後のユーザーを「特定のグループに入れる」といったことはできないようで、「ソーステナントにユーザーを作ったら、それだけでターゲットテナント側の権限設定まですべて完了！」という世界観には一歩届いていません。
「同期されたら自動的にAzureに対して権限設定されて、もうそのまま使えるようにしたいのよ！」に対するアンサーは、おそらく「動的グループ」です。
次回、同期されてきたユーザーを自動的に特定グループに所属させる×特定グループにあらかじめ権限設定をしておくことで、SSOのような世界観を実現する…ということを検証したいと思います。
Discussion