This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 93%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
I am looking to restrict the scope of the Graph API Mail.Send application permission for an app registration.
I'd like to use RBAC for applications instead of application policies, but I am unclear on the note in the documentation for management scopes which says:
While there is a property called Administrative Units, we recommend you use the native Admin Units parameter on a role assignment to avoid creating a scope as an intermediary pointer object.
I would be grateful if someone could explain that to me (e.g., what is a "scope as an intermediary pointer object")?
Thank you!
What they are trying to say is that you should not be creating a new (AU-scoped) management scope for this scenario. Instead, when issuing the New-ManagementRoleAssignment cmdlet, leverage the -RecipientAdministrativeUnitScope parameter, to the same effect.
Hi @Vasil Michev ,
As far as I know, we use one of the following parameters:
My question is that it seems the author is implying that using an Entra ID AU is not preferrable. While I am not debating it, I am intrigued to know why.
Thea author is implying that you should not be creating a new management scope based on AU membership, as you can achieve the same effect by leveraging the -RecipientAdministrativeUnitScope parameter. Both methods can be used for scoping access based on AUs, but in the former you are creating additional overhead.
That makes sense, thank you for your interest in my question.