pnp
New command: `m365 entra roleassignment add`
Usage
m365 entra roleassignment add [options]
Description
Assign a Entra ID role to a user and specify the scope for which the user has been granted access
Options
| ption | Description |
|---|---|
--roleDefinitionId [roleDefinitionId] |
Id of a role to be assigned. Specify either roleDefinitionId or roleDefinitionName, but not both. |
--roleDefinitionName [roleDefinitionName] |
Name of a role to be assigned. Specify either roleDefinitionId or roleDefinitionName, but not both. |
--principalId <principalId> |
Id of a user, a group or a service principal to which the assignment is granted. |
--administrativeUnitId [administrativeUnitId] |
Id of an administrative unit to which the assignment is scoped. Specify either administrativeUnitId or administrativeUnitName. |
--administrativeUnitName [administrativeUnitName] |
Name of an administrative unit to which the assignment is scoped. Specify either administrativeUnitId or administrativeUnitName. |
--applicationId [applicationId] |
Id of an application to which the assignment is scoped. Specify either applicationId or applicationName. |
--applicationName [applicationName] |
Name of an application to which the assignment is scoped. Specify either applicationId or applicationName. |
--servicePrincipalId [servicePrincipalId] |
Id of an application to which the assignment is scoped. Specify either servicePrincipalId or servicePrincipalName. |
--servicePrincipalName [servicePrincipalName] |
Name of an application to which the assignment is scoped. Specify either servicePrincipalId or servicePrincipalName. |
--groupId [groupId] |
Id of a group to which the assignment is scoped. Specify either groupId or groupName . |
--groupName [groupName ] |
Name of a group to which the assignment is scoped. Specify either groupId or groupName. |
Examples
Assign a role specified by name to a user specified by id and scope the assignment to the whole tenant
m365 entra roleassignment add --roleDefinitionName 'SharePoint Administrator' --principalId 7a2ca997-9461-402e-9882-58088a370889
Assign a role specified by id to a role-assignable group specified by id and scope the assignment to a service principal specified by id
m365 entra roleassignment add --roleDefinitionId 777b752-f9b7-4205-a2b1-5db0d6a0ccfc --principalId 6b1db886-9461-402e-9882-58088a370889 --servicePrincipal a4738dd8-fc0f-4646-87fb-47539f5c651b
Assign a role specified by name to a user specified by id and scope the assignment to an administrative unit specified by name
m365 entra roleassignment add --roleDefinitionName 'User Administrator' --principalId 7a2ca997-9461-402e-9882-58088a370889 --administrativeUnitName 'Marketing'
Assign a role specified by name to a user specified by id and scope the assignment to an application specified by id
m365 entra roleassignment add --roleDefinitionName 'Application Administrator' --principalId 7a2ca997-9461-402e-9882-58088a370889 --applicationId 47539fd8-fc0f-4646-87fb-a4738d5c651b
Default properties
No response
Additional Info
https://learn.microsoft.com/en-us/graph/api/rbacapplication-post-roleassignments?view=graph-rest-1.0&tabs=http
All roles support the tenant wide scope, but some roles can have assignment scoped to the administrative unit, application, service principal or group.
I will work on it
Hi @MartinM85 sorry for the late reply.
A few questions from my side:
- Looking at the docs, we cannot only assign roles to users but also role-assignable groups, and service principals.
- I would drop the
scopeparameter as this adds an extra option that doesn't add that much value for the user. This means that all options become one big option set.
@milanholemans Do you want the command to allow users to assign roles also to role-assignable groups and service principals as well?
Then we should somehow distinguish whether the principalId and principalName refer to users, role-assignable groups or service principals.
When I read the description of principalId etc, it looks like people can only specify users, while they should also be able to specify groups etc. But the command should work just fine if we enter a groupId instead of a userId, right?
@milanholemans That's right. The principalId can be either user id, group id, or service principal id.
Does it make sense to have the principalName? Because we don't know if it's a username, a group name or a service principal name.
Usually we prompt the user to choose one option from one type (like users), but not from three types (users, groups, service principals).
You are right. Maybe we should drop the principalName so we don't have to add a bunch of extra options and make the command more complex.
When calling the graph, it would be fine to use the UPN or group emailaddress as well I believe, right @MartinM85?
It's not super nice to incorporate that in principalId, but still, as it is possible, should we add that as an example and open up the possibility when validating for a guid or upn?
It would seem too bad if we missed that possibility just because the command name doesn't match the allowed value...
Or maybe we should rename it to principal
I don't have a clear opinion on this. I would prefer the solution that is most user-friendly.
If it accepts UPN and group email as well, I would opt for principal indeed.