🔺

Azure ADのテナント間同期の使い道

2023/02/10に公開

Azure

Azure AD

aad

tech

はじめに

2023年1月末に、「Cross-tenant synchronization」という機能がpreview公開されました。

「AzureADテナント間（Cross-tenant）でユーザーを同期する機能」ということで、全員にこの機能が刺さるわけではないと思いますが、個人的には嬉しい機能だったので調べてみました。
※今回は机上調査まで。

機能の紹介

それでは機能を見ていきます。
テナント間同期とは？というそのものずばりなドキュメントがあります。

機能概要

『同期元のAzure AD（ホームテナント）のユーザーを、同期先AzureAD（ターゲットテナント）の外部ユーザー（≒ゲストユーザー）として、自動的に招待・承認する機能』です。
同期※というとコピーをイメージし、「同期元AADユーザー」と同じ名前で「同期先AADユーザー」を作成するような機能を想像してしまいますが、あくまで外部ユーザーとしての招待になります。

いわゆるAzure AD B2Bのゲストユーザー招待の操作が自動化されるイメージですね。

※昔々、オンプレミスのActive Direcotryで「FIMやMIMを使ってADドメイン間のユーザー同期」なんていう運用をしていたのを思い出しました。

上記ドキュメントから引用した図で説明すると、Fabrikam MexicoやFablicam USが同期元AAD（ホームテナント）で、Contosoが同期先AAD（ターゲットテナント）となります。

同期対象は「特定の条件に従ったユーザー」に絞れるようです。（User2は同期されていない）

嬉しいこと

ドキュメントにもメリットが3点記載されています。

自動的な同期の構成作業が簡単に
元々、このような同期構成を組もうと思ったら、scriptを自作して定期実行するなど、作りこみが必要でした。マネージドなサービス設定だけで実現できるようになると、script開発～日々の運用が不要になり、嬉しい場面は多いはずです。
ゲストユーザー作成時のUXが向上
ゲストユーザーを招待するときは、
　管理者：ゲスト招待するAAD側（ターゲットテナント）で、ユーザーのメールアドレスを指定して、招待
　ユーザー：連携されたリンクにアクセスし、ホームテナントの認証情報でサインインして、招待の承認
といった手続きが必要で、AADテナントが増えれば増えるほど、対象ユーザーが増えれば増えるほど面倒なものでした。
今回の「Cross-tenant synchronization」では、この招待・承認操作を自動化させることができるようです。
移行元組織のユーザー変更が、自動的に同期
従来のゲストユーザー招待だと、ホームテナントのAAD上でユーザーが退職や異動により削除されたとしても、ターゲットテナント側からは自動的には削除されません。
また、ホームテナント側でユーザーの属性（表示名や、メールアドレスなど）が更新されても、ターゲットテナント側には反映されず、別途修正を行う必要があります。
「Cross-tenant synchronization」では、これも自動的に同期※してくれるようです。

※ドキュメントによると、「約40分ごとに実行」なのでリアルタイムではない。

同期のトポロジ

トポロジを紹介しているドキュメントがありました。この機能に期待している人が、何を知りたいかよくわかっていらっしゃる！

ソースとターゲットが①１：１、②１：多、③多：１、および④メッシュ構成となる場合のいずれも可能とのことです。

ただし双方向の同期を構成できるわけではなく、あくまで片方向の同期を両側で実行するようです。

ユースケースを考えてみる

公式ドキュメントやセミナーなどでの説明を聞くと、これまでMicrosoftの基本的な考え方は「1組織（会社）＝1AAD」でした。
しかしそうではないユースケースが増えて来たのか、最近はマルチAADを前提とした構成も描かれるようになってきているように思います。

ドキュメント上、想定されている構成

マルチAADのユースケースとして、下記のようなものが想定されています。

コングロマリット: 独立経営の複数の子会社または事業単位を含む組織。
合併と買収: 企業を合併または買収する組織。
売却活動: 売却では、ある組織がその事業の一部を分離して新しい組織を立ち上げるか、既存の組織に売却します。
複数のクラウド: コンプライアンスまたは規制上の必要性から複数のクラウド環境に展開する組織。
複数の地理的境界: 所在地に関するさまざま規制のために、複数の地理的な場所で事業を展開する組織。
テストテナントまたはステージングテナント: プライマリテナントへのより広範なデプロイに先んじて、テストまたはステージングの目的で複数のテナントを必要とする組織。
部門または従業員が作成したテナント: 開発、テスト、または独立した統制のために部門または従業員がテナントを作成した組織。

※以下のドキュメントより引用

中でも、よく見る構成について深堀してみます。

テストテナントまたはステージングテナント

SIer所属のエンジニアとして色々なお客様の環境を見ていますが、「本番とは別のAAD・サブスクリプションを用意する」というAzureの使い方をよく見ますし、私自身も推奨することが多いです。
AADレイヤの設定変更など、本番環境での一発変更になってしまうとリスクが大きいので、まず検証したいですし、検証のために設定を緩めたり絞ったりすることがよくあります。

このような時、
・「テスト用テナントに作成したユーザー」を「本番用テナントに招待」して、参照権限だけ付けておくと、開発やテストが捗る
・「本番用テナントに従業員のユーザーが存在し」「一部の部門、役割のユーザーを開発テナントに招待して作業できるようにしておく」
といった形でよく使われています。

とはいえ、この場合は多くても本番AADプラス1～2AADといったところなので、労力もたかが知れているかもしれません。

部門または従業員が作成したテナント

SIer所属のエンジニアとしては（2回目）、お客様毎に統制レベルが違えば設定に跳ねてくるところもあるので、検証用の環境はお客様毎、プロジェクト毎に作るのが普通の感覚です。また、自主事業でも同様で、システム単位で環境が分かれていることがよくあります。
その結果、見える範囲でも数えきれないAADが存在してしまいます。それぞれにユーザーを作成するとパスワードやMFAツールの管理やライセンス（P1,P2など）だけでも大変になってしまうので、ゲストユーザーで賄えるところはゲストユーザーにするのですが、それでもいちいち招待したり、削除したりとすると大変なことになってきます。

以上から、今回の「Cross-tenant synchronization」はとても待ち望んでいた機能でした。一度設定すれば、ホームテナントでSSOを実現したといっても過言ではないですよね。

おわりに

Azure ADのテナント間同期の概要を見てきました。自分にとってとても刺さる機能であることが確認できたので、次回は実際に検証用環境に設定して具体的な動作を確かめたいと思います。

＜参考・補足＞