SaaS その他

グループの管理権限（SOA）をクラウドに移すとどうなる？ネストやGovernance、切り戻しの挙動を検証！

ごきげんよう、IDチームのわかなです！

前回は、Microsoft Entra IDの注目機能である、同期ユーザーとグループの管理権限をクラウド側に移譲する「SOA（Source of Authority）」の基本と、PowerShellを使った切り替え方法について解説しました。

今回はその続編として、実際に運用時に気になる挙動を、検証してみました！

isCloudManaged を false に戻すとどうなるのか？

何らかの理由で、一度クラウド管理（isCloudManaged = true）にしたグループを、再びオンプレAD管理（false）に戻したい場合があるかもしれません。その時の挙動を確認しました。

結論：AD側の同期が走ったタイミングで、AD管理に戻ります。

具体的には以下のようになります。

属性の上書き
- 次回のディレクトリ同期が実行されたタイミングで、AD側の値でEntra ID側の属性が上書きされます。
管理権限がADに戻る
- 同期が実行された後、Entra ID上のプロパティ編集画面は再びグレーアウトし、クラウド側での直接編集ができなくなります。
ADへの書き戻しは原則なし
- Group Writebackなどを構成していない限り、Entra ID管理期間中にクラウド側で変更したメンバーや属性情報は、AD側には反映されません。

false に戻すとADがマスタの世界に逆戻りするため、クラウド側で行った変更は同期のタイミングで消えてしまう点に注意が必要です。

AD側でグループがネスト（入れ子）構造になっている場合、親グループのSOAを切り替えると、子グループも自動的にメンバーシップに追加されたり、クラウド管理になるのでしょうか？

結論：SOA設定（管理権限）はカスケードしません。ただし、ネスト関係（メンバーシップ）は維持されます。

SOAの設定（isCloudManaged）は、指定したグループオブジェクト単体にのみ適用されます。

例えば、真ん中の「Group2」だけをクラウド管理に切り替えた場合、Entra ID上では以下のように見えます。

このように、明示的に指定したグループだけが切り替わります。もし、ネスト構造を維持したまま全体をクラウド管理へ移行したい場合は、階層の一番下（メンバーとなっているグループ）から順にSOAを切り替えていく運用設計がおすすめです。

なお、管理権限がバラバラになっても、親子関係（メンバーシップ）はそのまま維持されます。以下のように、親グループ（AD管理）の中に、クラウド管理になった子グループ（Group2）がメンバーとして正しく残っていることが確認できました。

これまで、オンプレAD同期グループは、Entra ID Governance機能（アクセスレビューやライフサイクルワークフロー）において課題がありました。

ADマスターのグループをアクセスパッケージに割り当てたり、アクセスレビュー対象にしても、AD同期が走るとメンバーが元通りに復活してしまうため、実質的に制御不能でした。
そもそも、Entra ID Governanceのカタログにリソースを追加しようとしても、「ディレクトリ同期オブジェクトは許可されていません」と表示され、選択すらできませんでした。