Microsoft
Microsoftskwan Nice work, Stuart and team! I've started to look at this and it is certainly an "interesting" feature, even though a GA won't have a problem to either remove a user from a restricted AU, change them, and then move them back ... but - of course - not without leaving traces in the audit-log. So certainly worthwhile to hinder GAs from performing any unintentional change on objects in a restricted AU!
Nonetheless, my testing also showed that there are circumstances when using restricted AUs, where it's even more challenging to predict which objects can be edited by whom - i.e. what the resultant set of permissions an operator has on an object. E.g. when one of the objects in the restricted AU is themselves assigned to an AAD/EID role, the "restricted AU" admin (i.e. the "Executive admin" in the sample above) who may be assigned the User Admin role, won't be able to edit this object as it's "protected" by being a member of a (privileged) role [MikeCrowley - this object-protection by membership of a role is what I'd compare to AD's AdminSDholder/SDPROP process]. However, the GA can no longer edit that account either, unless also assigned to manage the objects in the restricted AU ... which obviously defeats the purpose.
So, good care must be taken when planning the use of the restricted AU feature - but in general, I very much welcome it!
