🔺

AzureADのテナント間同期を設定してみた

2023/02/22に公開

はじめに

前回、下の記事にてAzureADのテナント間同期機能の机上確認をしました。
https://zenn.dev/tomot/articles/fea16622cd972c

今回は改めて、AzureADのテナント間同期を設定して機能確認していきます。

設定手順

参考にしたドキュメントは下記の通りです。後から見返した時のため、こういうリンクを残しておくのも大事ですね。

前提条件の確認

①の手順に記載のある前提条件を確認します。

ソーステナント

Azure AD Premium P1 または P2 ライセンス
テナント間アクセス設定を構成するためのセキュリティ管理者ロール
テナント間同期を構成するためのハイブリッド ID の管理者ロール
構成へのユーザーの割り当てと、構成の削除を行うクラウド アプリケーション管理者またはアプリケーション管理者ロール

ターゲットテナント

Azure AD Premium P1 または P2 ライセンス
テナント間アクセス設定を構成するためのセキュリティ管理者ロール

今回は検証なので両テナントの強権限(グローバル管理者)で進めてしまいます。
ですが、ライセンス周りだけは確認が必要ですね。この「テナント間同期」機能を使う場合、同期対象となるユーザー分、ソース/ターゲットテナントそれぞれでP1/P2ライセンスのどちらかが必要となるようです。

事前設定(ライセンス周り)

ソーステナントでは、必要なユーザー数分のP1ライセンスを持っているものとします。
ターゲットテナント(ゲスト招待する側)では、いくつのP1ライセンスが必要になるのでしょうか?

元々AzureADの世界では、ゲストユーザー分のP1ライセンスはちょっと特殊ルールがあり、通常用のライセンス1に対して5ゲストユーザーまで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