- 11 minutes to read
Entitlement management is an identity governance feature that enables organizations to manage identity and access lifecycle at scale, by automating access request workflows, access assignments, reviews, and expiration.
Employees in organizations need access to various groups, applications, and SharePoint Online sites to perform their job. Managing this access is challenging, as requirements change. New applications are added or users need more access rights. This scenario gets more complicated when you collaborate with outside organizations. You may not know who in the other organization needs access to your organization's resources, and they won't know what applications, groups, or sites your organization is using.
Entitlement management can help you more efficiently manage access to groups, applications, and SharePoint Online sites for internal users, and also for users outside your organization who need access to those resources.
Why use entitlement management?
Enterprise organizations often face challenges when managing employee access to resources such as:
- Users may not know what access they should have, and even if they do, they may have difficulty locating the right individuals to approve their access
- Once users find and receive access to a resource, they may hold on to access longer than is required for business purposes
These problems are compounded for users who need access from another organization, such as external users that are from supply chain organizations or other business partners. For example:
- No one person may know all of the specific individuals in other organization's directories to be able to invite them
- Even if they were able to invite these users, no one in that organization may remember to manage all of the users' access consistently
Entitlement management can help address these challenges. To learn more about how customers have been using entitlement management, you can read the Mississippi Division of Medicaid, Storebrand and Avanade case studies. This video provides an overview of entitlement management and its value:
What can I do with entitlement management?
Here are some of capabilities of entitlement management:
- Control who can get access to applications, groups, Teams and SharePoint sites, with multi-stage approval, and ensure users don't retain access indefinitely through time-limited assignments and recurring access reviews.
- Give users access automatically to those resources, based on the user's properties like department or cost center, and remove a user's access when those properties change (preview).
- Delegate to non-administrators the ability to create access packages. These access packages contain resources that users can request, and the delegated access package managers can define policies with rules for which users can request, who must approve their access, and when access expires.
- Select connected organizations whose users can request access. When a user who isn't yet in your directory requests access, and is approved, they're automatically invited into your directory and assigned access. When their access expires, if they have no other access package assignments, their B2B account in your directory can be automatically removed.
If you are ready to try Entitlement management you can get started with our tutorial to create your first access package.
You can also read the common scenarios, or watch videos, including
- How to deploy entitlement management in your organization
- How to monitor and scale your use of entitlement management
- How to delegate in entitlement management
What are access packages and what resources can I manage with them?
Entitlement management introduces the concept of an access package. An access package is a bundle of all the resources with the access a user needs to work on a project or perform their task. Access packages are used to govern access for your internal employees, and also users outside your organization.
Here are the types of resources you can manage user's access to, with entitlement management:
- Membership of Azure AD security groups
- Membership of Microsoft 365 Groups and Teams
- Assignment to Azure AD enterprise applications, including SaaS applications and custom-integrated applications that support federation/single sign-on and/or provisioning
- Membership of SharePoint Online sites
You can also control access to other resources that rely upon Azure AD security groups or Microsoft 365 Groups. For example:
- You can give users licenses for Microsoft 365 by using an Azure AD security group in an access package and configuring group-based licensing for that group.
- You can give users access to manage Azure resources by using an Azure AD security group in an access package and creating an Azure role assignment for that group.
- You can give users access to manage Azure AD roles by using groups assignable to Azure AD roles in an access package and assigning an Azure AD role to that group.
How do I control who gets access?
With an access package, an administrator or delegated access package manager lists the resources (groups, apps, and sites), and the roles the users need for those resources.
Access packages also include one or more policies. A policy defines the rules or guardrails for assignment to access package. Each policy can be used to ensure that only the appropriate users are able to have access assignments, and the access is time-limited and will expire if not renewed.
You can have policies for users to request access. In these kinds of policies, an administrator or access package manager defines
- Either the already-existing users (typically employees or already-invited guests), or the partner organizations of external users that are eligible to request access
- The approval process and the users that can approve or deny access
- The duration of a user's access assignment, once approved, before the assignment expires
You can also have policies for users to be assigned access, either by an administrator or automatically.
The following diagram shows an example of the different elements in entitlement management. It shows one catalog with two example access packages.
- Access package 1 includes a single group as a resource. Access is defined with a policy that enables a set of users in the directory to request access.
- Access package 2 includes a group, an application, and a SharePoint Online site as resources. Access is defined with two different policies. The first policy enables a set of users in the directory to request access. The second policy enables users in an external directory to request access.
When should I use access packages?
Access packages don't replace other mechanisms for access assignment. They're most appropriate in situations such as:
- Migrating access policy definitions from a third party enterprise role management to Azure AD.
- Employees need time-limited access for a particular task. For example, you might use group-based licensing and a dynamic group to ensure all employees have an Exchange Online mailbox, and then use access packages for situations in which employees need more access rights. For example, rights to read departmental resources from another department.
- Access that requires the approval of an employee's manager or other designated individuals.
- Access that should be assigned automatically to people in a particular part of an organization during their time in that job role, but also available for people elsewhere in the organization, or in a business partner organization, to request.
- Departments wish to manage their own access policies for their resources without IT involvement.
- Two or more organizations are collaborating on a project, and as a result, multiple users from one organization will need to be brought in via Azure AD B2B to access another organization's resources.
How do I delegate access?
Access packages are defined in containers called catalogs. You can have a single catalog for all your access packages, or you can designate individuals to create and own their own catalogs. An administrator can add resources to any catalog, but a non-administrator can only add to a catalog the resources that they own. A catalog owner can add other users as catalog co-owners, or as access package managers. These scenarios are described further in the article delegation and roles in entitlement management.
Summary of terminology
To better understand entitlement management and its documentation, you can refer back to the following list of terms.
|access package||A bundle of resources that a team or project needs and is governed with policies. An access package is always contained in a catalog. You would create a new access package for a scenario in which users need to request access.|
|access request||A request to access the resources in an access package. A request typically goes through an approval workflow. If approved, the requesting user receives an access package assignment.|
|assignment||An assignment of an access package to a user ensures the user has all the resource roles of that access package. Access package assignments typically have a time limit before they expire.|
|catalog||A container of related resources and access packages. Catalogs are used for delegation, so that non-administrators can create their own access packages. Catalog owners can add resources they own to a catalog.|
|catalog creator||A collection of users who are authorized to create new catalogs. When a non-administrator user who is authorized to be a catalog creator creates a new catalog, they automatically become the owner of that catalog.|
|connected organization||An external Azure AD directory or domain that you have a relationship with. The users from a connected organization can be specified in a policy as being allowed to request access.|
|policy||A set of rules that defines the access lifecycle, such as how users get access, who can approve, and how long users have access through an assignment. A policy is linked to an access package. For example, an access package could have two policies - one for employees to request access and a second for external users to request access.|
|resource||An asset, such as an Office group, a security group, an application, or a SharePoint Online site, with a role that a user can be granted permissions to.|
|resource directory||A directory that has one or more resources to share.|
|resource role||A collection of permissions associated with and defined by a resource. A group has two roles - member and owner. SharePoint sites typically have three roles but may have other custom roles. Applications can have custom roles.|
Using this feature requires Azure AD Premium P2 licenses. To find the right license for your requirements, see Compare generally available features of Azure AD.
How many licenses must you have?
Ensure that your directory has at least as many Azure AD Premium P2 licenses as you have:
- Member users who can request an access package.
- Member users who request an access package.
- Member users who approve requests for an access package.
- Member users who review assignments for an access package.
- Member users who have a direct assignment or an automatic assignment to an access package.
For guest users, licensing needs will depend on the licensing model you’re using. However, the below guest users’ activities are considered Azure AD Premium P2 usage:
- Guest users who request an access package.
- Guest users who approve requests for an access package.
- Guest users who review assignments for an access package.
- Guest users who have a direct assignment to an access package.
Azure AD Premium P2 licenses are not required for the following tasks:
- No licenses are required for users with the Global Administrator role who set up the initial catalogs, access packages, and policies, and delegate administrative tasks to other users.
- No licenses are required for users who have been delegated administrative tasks, such as catalog creator, catalog owner, and access package manager.
- No licenses are required for guests who have a privilege to request access packages but they do not choose to request them.
For more information about licenses, see Assign or remove licenses using the Azure Active Directory portal.
Example license scenarios
Here are some example license scenarios to help you determine the number of licenses you must have.
|Scenario||Calculation||Number of licenses|
|A Global Administrator at Woodgrove Bank creates initial catalogs and delegates administrative tasks to six other users. One of the policies specifies that All employees (2,000 employees) can request a specific set of access packages. 150 employees request the access packages.||2,000 employees who can request the access packages||2,000|
|A Global Administrator at Woodgrove Bank creates initial catalogs and delegates administrative tasks to six other users. One of the policies specifies that All employees (2,000 employees) can request a specific set of access packages. Another policy specifies that some users from Users from partner Contoso (guests) can request the same access packages subject to approval. Contoso has 30,000 users. 150 employees request the access packages and 10,500 users from Contoso request access.||2,000 employees need licenses, guest users are billed on a monthly active user basis and no additional licenses are required for them. *||2,000|
* Azure AD External Identities (guest user) pricing is based on monthly active users (MAU), which is the count of unique users with authentication activity within a calendar month. This model replaces the 1:5 ratio billing model, which allowed up to five guest users for each Azure AD Premium license in your tenant. When your tenant is linked to a subscription and you use External Identities features to collaborate with guest users, you'll be automatically billed using the MAU-based billing model. For more information, see Billing model for Azure AD External Identities.
- If you're interested in using the Azure portal to manage access to resources, see Tutorial: Manage access to resources - Azure portal.
- if you're interested in using Microsoft Graph to manage access to resources, see Tutorial: manage access to resources - Microsoft Graph
- Common scenarios