Is it possible to create an app-only credential, which has scoped AdministrativeUnit.ReadWrite.All permissions ?

Question

Is it possible to create an app-only credential, which has scoped AdministrativeUnit.ReadWrite.All permissions ?

Harish Ganesan 0

From what i read around, Administrative units allow us to scope certain directory operations to a certain groups of principals within a tenant. I am working on an application, which handles some directory operations for a particular group of users. For this application, I need to create a least-privilege credential which can invite guest users, add these guest users to a specific AU, delete guest users, create groups inside the same AU, add guest users to the created groups. But as far as I can understand from the various documentation sources, it seems like it is not possible to create an application credential ( non-delegated ) which is scoped to a particular AU. Is my understanding of the issue complete ?

If what I said above is right, then what options do I have with me to perform the task I mentioned above ? If not, what would be the least-privilege permissions that I need to assign to the application SP to acheive the above ?

Thanks.

0 comments

2 answers

Your answer

Answer 1

Vasil Michev 128.7K MVP Volunteer Moderator

There are two ways you can go about granting permissions in Microsoft 365. First one is by granting the corresponding role/scope on the API layer, if your scenario granting AdministrativeUnit.ReadWrite.All app permissions. As you've correctly noted, those are unrestricted, tenant-wide permissions and will not prevent your app from managing other objects.

The other way is by granting an admin role to the corresponding principal, be it user or app. In this scenario, the permissions on the API side are dictated by what the role allows, and as role assignments can indeed be scoped to an AU, the effective permissions are also scoped. And yes, applications/service principals can also gain access in this way.

So for your scenario, identify which Entra/Microsoft 365 admin role is the lowest privileged one, and create an AU-scoped assignment for it, with your app as the target. Do NOT grant AdministrativeUnit.ReadWrite.All permissions on the app directly. If you cannot identify a single admin role that contains all required permissions, you can assign multiple (scoped) ones, or use a combination of admin role and application permissions. But remember, the latter cannot be scoped, so the app will always have access to all corresponding objects.

Harish Ganesan 0 Reputation points

2026-11-12T19:15:39.7633333+00:00

Thanks a lot for the response @Vasil Michev . We identified User Administrator as the least privilege role sufficient to do all the operations we needed the application to do.

But when we tried to assign the role using the az cli, we got a response saying "Applications cannot be assigned admin roles" or something of that sort. Granted that the account we were trying this was a Pay as you go account, so when we tried to do something similar with a user's principal, it said that the operation was only allowed on AAD premium accounts. Does this have any bearing in the first error though ?

Also on a related note, I couldn't find any documentation for this, but when I asked an AI assistant, if granting equivalent admin roles without granting the corresponding API permissions, would allow me to add users to that particular AU, it actually pointed out that the following.

In an app-only flow, Graph first checks the token for an application permission (an roles claim). Without AdministrativeUnit.ReadWrite.All (or an equivalent), the call is rejected with 403 Authorization_RequestDenied. The AU-scoped User Administrator role doesn't substitute for it.

I ofcourse couldn't check this, because I couldn't even assign the admin role to the application credential.

In conclusion, Am i misunderstanding the error saying that I can't assign applications cannot be admins ?

Thanks
Vasil Michev 128.7K Reputation points MVP Volunteer Moderator

2026-11-12T20:51:14.73+00:00

I haven't tested in a PAYG subscription, but assigning roles to service principals works fine in my tenant. Do make sure you are passing the GUID of the service principal object, not the app registration one. You do need P1 or equivalent license for working with AUs though.Speaking of which, adding/removing AU members is only possible via the Privileged Role Administrator or Global Administrator roles. The reason being, AUs are used to delegate permissions, so only highly privileged users can manage them. Plus, said roles cannot be AU scoped. You can still assign them to your app, but they will grant tenant-wide access, which defeats the initial purpose. I suppose I should have though about that in my initial reply, sorry about that.

For the record, if you do assign Privileged Role Admin to the service principal, you can manage AU members without the need for AdministrativeUnit.ReadWrite.All permissions. But due to the nature of said roles, this is not really a solution that will work for you.

Answer 2

A service principal can receive a Microsoft Entra role scoped to an administrative unit, but AdministrativeUnit.ReadWrite.All and the other Microsoft Graph application permissions required by this workflow cannot themselves be restricted to one AU. ^1^

Consequently, a fully unattended app can perform the workflow, but Microsoft Entra cannot enforce the target AU as the authorization boundary for every operation. The application must enforce that boundary itself.

Recommended app-only configuration

Grant only the application permissions required by the operations you implement:

Operation	Least-privileged application permission	AU-scoped?
Invite a guest	`User.Invite.All`	No. Invitation creates the guest in the tenant; it does not place the guest in an AU. B2B invitations must also be enabled. ^2^
Add an existing guest to the AU	`AdministrativeUnit.ReadWrite.All`	No. This application permission can modify AU membership tenant-wide. ^3^
Create a group directly in the AU	`Group.Create` + `AdministrativeUnit.Read.All`	Requires either Groups Administrator or User Administrator assigned to the service principal at that AU, plus directory-read access. ^3^
Add the guest to the group	`GroupMember.ReadWrite.All`	No; the application permission can modify eligible groups throughout the tenant. ^4^
Delete the guest account	`User.ReadWrite.All`	No; it can delete nonprivileged users outside the AU as well. Extra role privilege is required for users holding privileged administrative roles. ^5^

For direct group creation under the AU endpoint, choose Groups Administrator unless the app also needs AU-scoped user-administration capabilities. Do not add User Administrator merely for group creation, because either role satisfies that API’s role requirement.

The service principal also needs directory-read access. Microsoft documents that service principals do not receive directory-read permissions by default and that these read permissions cannot currently be scoped to an AU. Assign tenant-scoped Directory Readers, or grant an appropriate Graph read application permission such as Directory.Read.All. ^6^

Assign the AU-scoped role

Prerequisites:

Microsoft Entra PowerShell installed.
A Privileged Role Administrator executing the assignment.
Microsoft Entra ID P1 or P2 for the administrative-unit administrator assignment; AU members require Microsoft Entra ID Free. ^7^

Connect-Entra -Scopes 'Application.Read.All',
    'AdministrativeUnit.Read.All',
    'RoleManagement.ReadWrite.Directory'

$sp = Get-EntraServicePrincipal -Filter "DisplayName eq 'My Application'"
$au = Get-EntraAdministrativeUnit -Filter "DisplayName eq 'My Admin Unit'"
$role = Get-EntraDirectoryRoleDefinition `
    -Filter "DisplayName eq 'Groups Administrator'"

New-EntraDirectoryRoleAssignment `
    -PrincipalId $sp.Id `
    -RoleDefinitionId $role.Id `
    -DirectoryScopeId "/administrativeUnits/$($au.Id)"

Microsoft Entra supports assigning AU-scoped roles to service principals. ^1^

This script assigns the Entra role only. It does not add Microsoft Graph application permissions or grant admin consent; configure those separately on Entra ID → App registrations → your app → API permissions.

End-to-end API sequence

POST /invitations using User.Invite.All; retain the returned guest user ID.
POST /directory/administrativeUnits/{au-id}/members/$ref to add that guest ID to the AU.
POST /directory/administrativeUnits/{au-id}/members to create the group directly within the AU.
POST /groups/{group-id}/members/$ref to add the guest to the group.
When offboarding, remove group/AU memberships as needed, then optionally call DELETE /users/{guest-id}.

Adding a group to an AU scopes management of the group object, not the users in that group. Users must be added directly to the AU when their user objects need AU-scoped administration. ^7^

Deletion warning: DELETE /users/{guest-id} is destructive and can affect access, ownership, licenses, and downstream resources. Before automation, verify the tenant and immutable guest object ID, check ownership/dependencies, log the operation, and preferably require approval.

Security boundary

The app should maintain an allowlist containing the permitted AU ID and group IDs, reject arbitrary object IDs, and verify AU membership before updates or deletion. However, these checks are defense in depth—not a Microsoft Entra authorization boundary. A compromised credential carrying AdministrativeUnit.ReadWrite.All, GroupMember.ReadWrite.All, or User.ReadWrite.All remains technically capable of operations elsewhere in the tenant.

A delegated design can enforce AU-scoped Entra roles for operations that honor those roles, but it does not make guest invitation AU-scoped and does not automatically constrain operations independently authorized by tenant-wide Graph permissions.

References