テナント間移行時のドメインの考慮（AADCの場合）

以前に下記のブログを書きましたが、AADCの場合にどういう制約があるのかという質問を社内から複数もらいましたので記載をします。

ドメインの移行について

ドメインの移行について

前回の記事の復習

Microsoft 365においてドメインは大きく２つあります。

　１）「xxx.onmicrosoft.com」といった初期ドメイン
　２）「xxx.comやxxx.co.jp」といった独自ドメイン

１つ目は「移行しようがない」ということはほとんどの方は理解しているかと思いますが、このドメインのままで利用しているオブジェクト（グループやシステム系のアカウントに多い）がある場合は注意が必要となります。※配布リスト／メールが有効なセキュリティグループとかに利用していると社外にも影響する可能性あります

２つ目は後から登録したドメインなので簡単に移行ができると思っている方が多いので一番GAPがある部分となります。

一般論として移行プロジェクトの前提は移行元と移行先で環境を整えてデータの移行をするというプロセスですすみます。具体的には移行元でも「XXX.com」を登録して、移行先でも「XXX.com」を登録してデータ移行をした後にMＸレコードだけを切り替えて移行完了とするというのが理想の形なのですが、Microsoft 365では移行元と移行先で同じドメインを登録することができません。

AADCがある環境の違い

データの移行方法は前回書いた通りですので割愛して、本番の切り替え時の方法を記載してきます。

ゴールは「①移行元からドメインを削除」して「②移行先にドメインを登録」して「③移行先の既存オブジェクトを登録したドメインに変更する」ことです。

①と③の方法をどのようにするのかという点でAADCの場合には選択肢が増えます。

AADCはADの情報をAADに同期するシステムです。仕様としては「上書き」であり、ADが正であるという前提で作られています。※書き戻し機能もありますが機能の本質としての記載ですのでご容赦ください

ADで作っていてAADに同期しているオブジェクトに関しては、AD側で変更して同期をするという方法がとれることがAADだけのパターンとの違いとなります。

実際のシチュエーション

このシチュエーションによって推奨される方法が変わります。
※わかりやすくサードパーティ製品とかの観点は除外しています。逆にいうと実際はサードパーティが入ってくるからもっとややこしいです。

例①：移行元はすべてA社で運用をしていた。今後はA社のADを利用をして、それ以外はＺ社のものを利用する
→いわゆる一般的なパターンとなる。

例②：移行元はすべてA社で運用をしていた。今後はA社のADとAADCを使用して、それ以外はZ社のものを利用する。
→1 つの Azure AD テナントに接続する複数の Azure AD Connect 同期サーバーはサポートされていないためこのシナリオはZ社がAADCを使っていない場合となるので稀な状況となる。

サポートしているトポロジーについて：https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/connect/plan-connect-topologies

例③：移行元はすべてA社で運用をしていた。今後はすべてZ社のものを利用する。
→ADを共有のものを使うように変更するというパターンでクライアントのドメイン変更とかユーザーインパクトが大きいため、体制によってはクライアント重視でうわのそらになって後で大変になるパターン（苦笑）

特殊例（いろいろなケースがあるのでちゃんと整理しようという意味で記載）

例：移行元はすべてA社で運用をしていた。ADを変更してユーザーを作りなおしてデータを移行したい。
→グループ全体としてADが複数のフォレストとなっており用途別に利用している。会社のポジションが変わったがゆえに別のADで作りなおして今後も同じテナントで使い続けたい（厳密にいうとテナント内移行なのでスロットリングがより厳しくなったりするので難易度があがる）

パッと思いつくだけでも上記のようなペルソナが存在するので、これから書くことはすべてに当てはまるものではなく一般的なものです。１＋１＝２みたいな簡単なものではないので事実や要望を元にどうやって組み合わせるのかであり、その種として記載しているだけですので考え方を理解した上で実際の対応はご検討ください。

移行元からドメインを削除

ドメインを消すという作業はドメインの追加の画面で「削除」をクリックするだけなので簡単です。しかし、削除を「成功」するためには実は条件があり、この部分が大きく影響を及ぼします。

条件は「ドメインを使っているすべてのオブジェクトのドメインを変更すること」です。

AADだけで運用している場合はAADで全部変更をするしかありません。AADCを利用している場合はオブジェクトがどこで作られているかを考えて対応方法を検討する必要が出てきます。

例えばユーザーや配布リストといった主要なオブジェクトはすべてADで作っている場合は、このようなオブジェクトはAD側で一括でスクリプトでドメインを変更して、AADCを同期してAADにあるオブジェクトのドメインを変更するといったことが考えられます。
この場合においてはMicrosoft 365 グループなどAAD側でしか作れないオブジェクトはAAD側で変更するといったことになるので、ADとAADの両方を対応するといった対応になります。

ここで「もっと楽できないか？」とか考えると考慮ポイントが増えます。
※メリット／デメリットがある部分なので状況によると思ってます。AD担当とAAD担当が別の場合などはリスクの観点からさくっと決まったりします。ADの運用の一部停止なども必要となりますが、ここら辺の考え方によっても選択肢が変わると思います。

①「すべてAADで作業する」
②「AADのものはAADで作業。AD同期しているものはADで作業」

その他で注意すべき点としてはAADCの下記の仕様があります。

非アクティブ化が完了するには 72 時間かかる場合があります。時間は、クラウドサービスサブスクリプションアカウント内のオブジェクトの数によって異なります。
https://learn.microsoft.com/ja-jp/troubleshoot/azure/active-directory/cannot-manage-objects

内容としてはADとAADの同期を完全停止するには72時間かかる場合があるというものなのですが、MXレコードがExOに直接向いている場合に72時間もメールがNDR返る状況にあるというのは現実的に許容されにくいと思います。

記載にあるとおりでオブジェクト数によって変わるために、数百人や数千人の場合にこの時間はここまではかかりませんので必要に応じてテストするなりでスケジュールを組む必要が出てきます。
(sSSOなど影響するのでテストもしにくい環境のケースもありますのでリスクの取り方次第で本番のスケジュールを検討することになると思います）

移行先の既存オブジェクトを登録したドメインに変更

通常のAAD単体で行っている場合はMicrosoft 365でドメインを一括変更する対応となるので少量ならGUIでしょうし、ある程度の量となるとPowerShellなどで対応するかと思います。

AADC環境の場合は今後ADを使って運用をしたいということですので、既存のAADオブジェクト（移行のために作ってある「.onmicrosoft.com」とADをマッチングさせて、ADで管理できるようにする必要があります。

マッチングにはハードマッチとソフトマッチがあるのですがマッチングの順番としては下記のようになります。

ソースアンカー (ImmutableID) の値が同じオブジェクトがあるか -> ハードマッチproxyAddresses/mail の値が同じオブジェクトがあるか -> SMTP ソフトマッチ
UPN の値が同じオブジェクトがあるか -> UPN ソフトマッチ
https://jpazureid.github.io/blog/azure-active-directory-connect/aboutSoftMatching/

一般的なシナリオの場合は２つ目の「proxyAddresses」を使ったソフトマッチで既存のオブジェクトとマッチングさせることになるかと思いますが、通常はADで事前に設定しておいて、AADCの同期だけですぐにマッチングできるようにするなどの対応をするかと思います。（緊急時の対応なども考慮するとすごい手間です）