Besides internal corporate users, Azure Active Directory (AAD) is increasingly seeing access by suppliers, partners, and external developers. If your own identities and external partners are stored in one directory, collaboration across a diverse range of applications becomes easier but managing the various authorizations more complex. Azure identity governance comes in handy in these cases.

Access management and processes that support the lifecycle are of interest even in companies that aim for little or no collaboration in the cloud. For example, employees often move between departments within a company, collecting different authorizations in the process, such as access to marketing repositories, insights into various training courses, or information on budget planning for previous years. Next, they might switch to a sales role, where they gain insights into customer relations information. Rarely does a clean-up take place after a role change. If the corresponding user account is hijacked by attackers, they can gain access to all of this information, which is fatal in the case of administrative accounts. Here, too, administrators retain extensive permissions after setting up systems across different projects.

Azure AD administrators use Identity Governance to regulate access management for resources in the cloud. This function lets organizations bundle resources, assign them to end users, and check access regularly with automatic mechanisms. In AAD, identity governance is split into two parts: the lifecycle of privileges for administrators (Privileged Identity Management, PIM) and Entitlement Lifecycle Management (ELM) for end users. Premium P2 licenses are required for both functions, but a trial license is all you need to test the functionality.

Access Packages

ELM in AAD currently manages groups (both security and Office 365 groups), applications integrated in AAD (both software as a service (SaaS) and in-house programming), and SharePoint Online sites. ELM bundles privileges in access packages that comprise one or more resources and one or more policies. The packages describe activities that end users need to perform in the scope of their work (e.g., all the privileges a user in marketing needs).

The policies delivered in the package determine the framework conditions under which the packages can be used (i.e., who has these rights and for how long). The system distinguishes between "internal" and "external" users, such as partners and suppliers with whom the company collaborates as Azure AD B2B external identities . Access packages thus bring together resources, roles for users, the users, and general conditions such as duration and the required permission process.

To create an initial package, open the AAD portal and select Azure Active Directory | Identity Governance , then Access packages on the overview page, and New access package in the top menu. In this example, you will be putting together a package for the finance department that provides access to websites and SharePoint and involves memberships in security groups. The package wizard guides you through the basic configuration of the package, including names and descriptions, resources, and then access policies. After you have set the name for the package, go to Resource roles , and select the kind of access you want to grant in the package. The switches for Groups , Applications , and SharePoint sites let you add the corresponding resources (Figure 1).

Figure 1: Entitlement management lets you bundle access packages and assign them to users at a later time.

For this example, you need to select two security groups, two applications, and one SharePoint site. For the respective resources, you have the option to specify the role to be assigned. Users can be assigned to groups as Member or Owner , and the options for SharePoint sites are Member , Owner , and Visitor . Applications in AAD can have very flexible role assignments because AAD supports app roles as a flexible construct during application integration. The roles that are available for the application are presented to you here.

Once you have selected the resources, in the next step you need to create an access policy in which you define the conditions for end-user access (e.g., whether access is self-service or whether an owner group is defined with approval). You can also define how long the authorizations are valid (days) and whether users will be able to extend access by submitting a request. In this example, you should enforce an attestation for internal users every 180 days, and every 90 days for external partners.

Because you can select multiple policies for an access package, you can create a policy that applies For users in your directory (your own users) in the first step and later a second policy For users not in your directory . If you want administrators to define the access rights, select None (administrator direct assignments only) , but in doing so you are disabling the self-service ability of users to authorize themselves.

For access controlled by the administrator, go to the Assignments section of Access packages on the AAD portal (if you are granting this privilege) and authorize the users individually. A path between the extremes would be to enable self-service for legitimate users, which would mean that not all employees of the company would have the right to grab the access package, although there would be a presorted list. This could be a dynamic group in AAD, which – keeping to the example – would comprise employees who have Finance in their Department attribute. The dynamic group bundles all the candidates and assigns this policy as an option.

Catalogs and Delegation

Of course, access packages should not be managed by centralized IT. Delegation of these activities for bundling packages, as well as the approval and rejection processes, can be handled by each department. Packages can therefore be logically grouped into catalogs , to which delegated administrators and approvers can then be assigned. When creating a new access package, the first step would then be to select a catalog in which the package would be published.

Under Azure Active Directory | Identity Governance on the AAD portal, you can see the Catalogs overview in the left sidebar; this is also where you can add new catalogs. If you did not select a catalog when creating the package, the new access package is automatically assigned to the Default catalog. After clicking on it, you will see further selection options in the left-hand menu, and overviews of resources, packages, and delegation options in Roles and administrators .

In the main overview you will find the Edit button, which you can use to make changes to the catalog. It is very important also to specify whether or not the catalog and all its packages should be visible to employees and optionally to external partners (Enabled and Enabled for external users switches). If the switches are set to No , employees will not see the packages.

Assigning Access Policies and User Requests

Authorized employees can independently request access via Access packages by registering for it through a self-service request. If an approval process has been configured, the approver of the access package still needs to sign off on this process. Each access package has a unique URL shown in the My access portal link property, which can be seen in the Overview tab. The My Access portal is the entry point for all access requests and provides an overview of all packages that the company approves. As part of the service, it handles requests for new packages, renewals from the user's perspective, and approvals and rejections by administrators and delegates. Employees can access the My Access portal either by clicking on the direct link to the access package or by using their browser to access the overview of all the packages on the portal. After doing so, they can then request the desired access. The My Access portal is integrated into AAD and uses AAD sign-in.

In the overview of all available Access packages , you will find a list of the packages and menu arrows that point to further information about the resources in the package (Figure 2). Packages that do not need approval can thus be requested directly, as can packages that require approval – although the latter do not immediately take effect. After approval, ELM in AAD adds the user to the respective resources. Employees are added as members for groups and SharePoint sites, and they are assigned to AAD applications for the respective applications. The active access packages can be seen in Access packages in the Active tab, whereas the Expired tab shows packages that have already expired. Users who are designated as owners of a package will find the current requests for their packages below Approvals and can decide whether to allow access.

Figure 2: User Sarah from the Finance team is requesting access. She opens the My Access portal and posts an access request. All assigned access packages are listed on the portal.

The description that you entered for the package during package creation is displayed for end users in the overview when the details are rolled up, and in the fly-in when users click Request access . You can avoid confusion and support requests if the description clearly states what the package gives access to, for whom it is intended, and how long access will be granted or when users will need to be recertified. If you have different approval processes, a note about the duration and requirements of the approval is also useful.