Microsoft 365のワークショップでお客様の会社に伺い、Microsoft Entra IDの利用状況などを伺うとActive Directoryと並行して運用していますって方はまだまだ多いです。
ただ、一方でActive Directoryを辞めたいという話を随分と聞くようにもなりました。
そんな最中にActive DirectoryからMicrosoft Entra IDに(ユーザーやグループなどの)オブジェクトの同期を行うMicrosoft Entra Connectでオブジェクト単位で同期設定を切り離し、オブジェクトのマスターをActive DirectoryからMicrosoft Entra IDに切り替えるという方法が提供されるようになりました (ちなみにオブジェクトのマスターのことをSource of Authority = SOAと呼ぶそうです)。
ちなみに同期そのものを辞める設定はこちら
これを利用することで、今まではActive Directoryからユーザーのパスワードを変更したり、属性情報を設定変更したりしていましたが、これからは同期したユーザーでもMicrosoft Entra ID側のユーザーをマスターにできるので、Microsoft Entra IDから属性変更などができるようになります。
設定してみる
2026年1月現在、オブジェクト単位でのマスター切替はGraph API経由で操作する必要があります。そこでGraph Explorerを使って設定します。
Graph Explorerにアクセスしたら画面右上のサインインボタンからサインインし、さらにConsent to Permissionsをクリックして、アクセス許可割り当てをします。使用するアクセス許可は User-OnPremisesSyncBehavior.ReadWrite.All になります。
アクセス許可割り当てができたら、URI (URLっぽい文字列のこと) 欄から
https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior?$select=isCloudManaged
と書いてRun queryを実行します。
※{ID}部分にはユーザーのIDを書きます (詳細は後述)
すると isCloudManaged = false となっていることから、このユーザーはまだActive Directoryから同期されているユーザーなんだなってことがわかります。
ちなみに{ID}部分に入れるユーザーのIDはMicrosoft Entra管理センターからユーザーのプロパティを開くと表示されるオブジェクトIDがそれにあたります。
ではいよいよマスターをActive DirectoryからMicrosoft Entra IDに切り替えましょう。
メソッドをPATCHに設定変更し、URIは
https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior
と書き、Request Body欄には
{
“isCloudManaged”: true
}
と書いてRun queryを実行します。
見た目の変化はないように見えますが、もう一度
https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior?$select=isCloudManaged
を実行すると今度は isCloudManaged = true となっていることがわかります。これによりこのユーザーはMicrosoft Entra IDがマスターとなり、Microsoft Entra IDから属性変更等ができるようになります。
同期はどのように変化したのか？
ここからはマニアックに見ていきます！
この設定により isCloudManaged = true となったユーザーは同期の対象から外れます。その様子をMicrosoft Entra ConnectのツールであるSynchronization Service Managerから見てみましょう。
★その前にちょっとだけおさらい★
Microsoft Entra Connectはご覧のようにActive DirectoryとMicrosoft Entra IDの間を直接同期するのではなく、コネクタスペースとメタバースを経由して行う仕組みでしたよね
Synchronization Service Managerに戻りましょう。
設定変更後の初回同期をログで見ると、Microsoft Entra ID側からMicrosoft Entra Connectのコネクタスペースへ1オブジェクトだけUpdateが同期されていることがわかります。この情報をダブルクリックして参照すると、、
ご覧のようにyamadaユーザーは blockOnPremisesSync = True となっており、同期対象ではないことを示す属性値が設定されたことがわかります。
さらにコネクタスペースからメタバースへ同期が行われ、YamadaユーザーのマスターはMicrosoft Entra IDだよって情報はメタバースにまで格納されることになりました。
ここでちょっと変わったことをしてみましょう。
Yamadaユーザーは同期対象ではなくなりましたが、ユーザー自体はまだActive Directoryにいます。そこで、新しいユーザーとグループを作成し、そのメンバーに新しいユーザーとYamadaユーザーのふたりを追加してみましょう。
同期を実行するとActive Directoryに作成したユーザーとグループはコネクタスペースを経由してメタバースへ情報が同期されたことがわかります(Projections ＝ 2となっている)。
メタバースへ格納されたActive Directoryユーザーとグループの情報はさらにMicrosoft Entra IDへエクスポート処理を行い、最終的にMicrosoft Entra IDへの同期処理を完了させます。
このとき、メタバースにはActive Directory側からは新しいユーザーとグループ、Microsoft Entra ID側からはYamadaユーザーのマスターは変わったよって情報がそれぞれ同期されてきて、両者が合体しています。
この時点で、Active Directoryから同期されたグループのメンバーに入っているYamadaユーザーとMicrosoft Entra IDのYamadaユーザーは同一ユーザーと認識します。
この状態でMicrosoft Entra IDへグループの情報を同期(エクスポート)するため、Microsoft Entra IDに同期されて作られたグループにはYamadaユーザーがちゃんと入っていることになります。
ちなみにエクスポート処理をログで見るとAdds = 2, Updates = 1 と表示されます。
Addsは新規作成したユーザーとグループ、UpdatesはYamadaユーザーをグループに追加した事象をそれぞれ表しています。
オブジェクトのマスターをActive DirectoryからMicrosoft Entra IDに切り替える設定方法とその同期処理の一部始終を見てみました。仕組みも含めて理解し、トラブルにも対応できるようになりましょう！
