Delegation and roles in entitlement management
In Azure AD, you can use role models to manage access at scale through identity governance.
- You can use access packages to represent organizational roles in your organization, such as "sales representative". An access package representing that organizational role would include all the access rights that a sales representative might typically need, across multiple resources.
- Applications can define their own roles. For example, if you had a sales application, and that application included the app role "salesperson", you could then include that role in an access package.
- You can use roles for delegating administrative access. If you have a catalog for all the access packages needed by sales, you could assign someone to be responsible for that catalog, by assigning them a catalog-specific role.
This article discusses how to use roles to manage aspects within Microsoft Entra entitlement management, for controlling access to the entitlement management resources.
By default, Global administrators and Identity governance administrators can create and manage all aspects of entitlement management. However, the users in these roles may not know all the situations where access packages are required. Typically it's users within the respective departments, teams, or projects who know who they're collaborating with, using what resources, and for how long. Instead of granting unrestricted permissions to non-administrators, you can grant users the least permissions they need to do their job and avoid creating conflicting or inappropriate access rights.
This video provides an overview of how to delegate access governance from IT administrator to users who aren't administrators.
To understand how you might delegate access governance in entitlement management, it helps to consider an example. Suppose your organization has the following administrator and managers.
As the IT administrator, Hana has contacts in each department-- Mamta in Marketing, Mark in Finance, and Joe in Legal who are responsible for their department's resources and business critical content.
With entitlement management, you can delegate access governance to these non-administrators because they're the ones who know which users need access, for how long, and to which resources. Delegating to non-administrators ensures the right people are managing access for their departments.
Here is one way that Hana could delegate access governance to the marketing, finance, and legal departments.
Hana creates a new Azure AD security group, and adds Mamta, Mark, and Joe as members of the group.
Hana adds that group to the catalog creators role.
Mamta, Mark, and Joe can now create catalogs for their departments, add resources that their departments need, and do further delegation within the catalog. They can't see each other's catalogs.
Mamta creates a Marketing catalog, which is a container of resources.
Mamta adds the resources that the marketing department owns to this catalog.
Mamta can add other people from that department as catalog owners for this catalog, which helps share the catalog management responsibilities.
Mamta can further delegate the creation and management of access packages in the Marketing catalog to project managers in the Marketing department. She can do this by assigning them to the access package manager role. An access package manager can create and manage access packages.
The following diagram shows catalogs with resources for the marketing, finance, and legal departments. Using these catalogs, project managers can create access packages for their teams or projects.
After delegation, the marketing department might have roles similar to the following table.
|User||Organizational role||Azure AD role||Entitlement management role|
|Hana||IT administrator||Global administrator or Identity Governance administrator|
|Mamta||Marketing manager||User||Catalog creator and Catalog owner|
|Bob||Marketing lead||User||Catalog owner|
|Jessica||Marketing project manager||User||Access package manager|
Entitlement management roles
Entitlement management has the following roles, with permissions for administering entitlement management itself, that apply across all catalogs.
|Entitlement management role||Role definition ID||Description|
||Create and manage catalogs. Typically an IT administrator who isn't a Global administrator, or a resource owner for a collection of resources. The person that creates a catalog automatically becomes the catalog's first catalog owner, and can add more catalog owners. A catalog creator can’t manage or see catalogs that they don’t own and can’t add resources they don’t own to a catalog. If the catalog creator needs to manage another catalog or add resources they don’t own, they can request to be a co-owner of that catalog or resource.|
Entitlement management has the following roles that are defined for each particular catalog, for administering access packages and other configuration within a catalog. An administrator or a catalog owner can add users, groups of users, or service principals to these roles.
|Entitlement management role||Role definition ID||Description|
||Edit and manage access packages and other resources in a catalog. Typically an IT administrator or resource owners, or a user who the catalog owner has chosen.|
||View existing access packages within a catalog.|
|Access package manager||
||Edit and manage all existing access packages within a catalog.|
|Access package assignment manager||
||Edit and manage all existing access packages' assignments.|
Also, the chosen approver and a requestor of an access package have rights, although they're not roles.
|Approver||Authorized by a policy to approve or deny requests to access packages, though they can't change the access package definitions.|
|Requestor||Authorized by a policy of an access package to request that access package.|
The following table lists the tasks that the entitlement management roles can do within entitlement management.
|Task||Admin||Catalog creator||Catalog owner||Access package manager||Access package assignment manager|
|Delegate to a catalog creator||✔️|
|Add a connected organization||✔️|
|Create a new catalog||✔️||✔️|
|Add a resource to a catalog||✔️||✔️|
|Add a catalog owner||✔️||✔️|
|Edit a catalog||✔️||✔️|
|Delete a catalog||✔️||✔️|
|Delegate to an access package manager||✔️||✔️|
|Remove an access package manager||✔️||✔️|
|Create a new access package in a catalog||✔️||✔️||✔️|
|Change resource roles in an access package||✔️||✔️||✔️|
|Create and edit policies||✔️||✔️||✔️|
|Directly assign a user to an access package||✔️||✔️||✔️||✔️|
|Directly remove a user from an access package||✔️||✔️||✔️||✔️|
|View who has an assignment to an access package||✔️||✔️||✔️||✔️|
|View an access package's requests||✔️||✔️||✔️||✔️|
|View a request's delivery errors||✔️||✔️||✔️||✔️|
|Reprocess a request||✔️||✔️||✔️||✔️|
|Cancel a pending request||✔️||✔️||✔️||✔️|
|Hide an access package||✔️||✔️||✔️|
|Delete an access package||✔️||✔️||✔️|
Required roles to add resources to a catalog
A Global administrator can add or remove any group (cloud-created security groups or cloud-created Microsoft 365 Groups), application, or SharePoint Online site in a catalog. A User administrator can add or remove any group or application in a catalog, except for a group configured as assignable to a directory role. For more information on role-assignable groups, reference Create a role-assignable group in Azure Active Directory.
Users that have been assigned the User administrator role will no longer be able to create catalogs or manage access packages in a catalog they do not own. If users in your organization have been assigned the User administrator role to configure catalogs, access packages, or policies in entitlement management, you should instead assign these users the Identity Governance administrator role.
For a user who isn't a global administrator, to add groups, applications, or SharePoint Online sites to a catalog, that user must have both an Azure AD directory role or ownership of the resource, and a catalog owner entitlement management role for the catalog. The following table lists the role combinations that are required to add resources to a catalog. To remove resources from a catalog, you must have the same roles.
|Azure AD directory role||Entitlement management role||Can add security group||Can add Microsoft 365 Group||Can add app||Can add SharePoint Online site|
|Intune administrator||Catalog owner||✔️||✔️|
|Exchange administrator||Catalog owner||✔️|
|Teams service administrator||Catalog owner||✔️|
|SharePoint administrator||Catalog owner||✔️||✔️|
|Application administrator||Catalog owner||✔️|
|Cloud application administrator||Catalog owner||✔️|
|User||Catalog owner||Only if group owner||Only if group owner||Only if app owner|
To determine the least privileged role for a task, you can also reference Administrator roles by admin task in Azure Active Directory.
Manage role assignments to entitlement management roles programmatically (preview)
You can also view and update catalog creators and entitlement management catalog-specific role assignments using Microsoft Graph. A user in an appropriate role with an application that has the delegated
EntitlementManagement.ReadWrite.All permission can call the Graph API to list the role definitions of entitlement management, and list role assignments to those role definitions.
For example, to view the entitlement management-specific roles that a particular user or group has been assigned, use the Graph query to list role assignments, and provide the user or group's ID as the value of the
principalId query filter, as in
GET https://graph.microsoft.com/beta/roleManagement/entitlementManagement/roleAssignments?$filter=principalId eq '10850a21-5283-41a6-9df3-3d90051dd111'&$expand=roleDefinition&$select=id,appScopeId,roleDefinition
For a role that is specific to a catalog, the
appScopeId in the response indicates the catalog in which the user is assigned a role. Note that this response only retrieves explicit assignments of that principal to role in entitlement management, it does not return results for a user who has access rights via a directory role, or through membership in a group assigned to a role.