Right Rights

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).

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.

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.

Access for External Users

Giving external partners access to applications and systems in the cloud works in a similar way to granting access to your own employees. You simply define an appropriate policy that links to people outside your directory. The resources in the package are the same, only the access assignment and reassignment settings that you define in the package are different. When creating packages, you should only add to internal Access packages resources that are accessible only to internal employees.

External partners and suppliers request access the same ways as internal employees, through the My Access portal or from the direct hyperlink to the package. Partners with whom you already successfully collaborate in the cloud can switch to your company in the My Access portal by selecting Switch organizations at top right, where they will find a list of the available access packages. The URL for the package automatically changes the organization, because the tenant (environment) information for the package is embedded in the URL.

If you want new partners to be able to access resources, you typically need to invite users to access your tenant. During the invitation process, AAD creates external identities to maintain references to invited users for auditing, access control, and group memberships. Azure AD automatically creates these accounts when new external partners follow the hyperlink to the package and request access, and you grant access. In this scenario, all new external partners receive a message with a checkbox that must be confirmed to request access.

To create the account in your tenant, the partner must agree to share their name, email address, and partner organization name with your tenant (Figure 3). Although this procedure might sound redundant, it is set up for your privacy. If the request is accepted, the partner can then be found as an external identity in the directory. The permissions from the access package are then assigned with the newly created external identity account.

Delegating to Departments

ELM in AAD is designed such that the processes of creating and assigning packages and the authorizations lifecycle do not need to be handled by IT. Many of the activities that require approval of access assignments are best handled by the individual departments, because at the end of the day, the staff there are more familiar with the type of resources internal employees require and who needs access to the resources.

Breaking resources down into different packages within a department, such as basic documents, confidential documents, and files containing customer data, is no problem. A Finance catalog defines the different packages as a function of their confidentiality and access requirements; then, you assign policies to the packages and determine dynamically how access and reassignment can occur, strictly on the basis of urgency or confidentiality.

Administrative Authorizations

ELM is also useful for administrative authorizations. You can create your own catalogs with access packages that assign ownership of, rather than membership in, resources such as groups or SharePoint sites.

As an administrator, if you add a SharePoint site or group to a package, you are defining the privileges that members of the resource in question are given. For groups, this can be Member or Owner. For SharePoint, the system also supports ownership for SharePoint sites, to which you can effectively assign administrative authorizations to employees. These authorizations can then also expire automatically after a number of days and need reapproval.

Access Review Automation

The lifecycle of a set of authorizations assigned to a user for an asset is rounded off by reviewing the further need for it and extending access or revoking the set accordingly. Normally, it does not make sense to assign assets without a time limit or a review. All too often, the needs or roles of users in the organization can change without their authorizations being rolled back. In the end, long-term employees accumulate resources and authorizations that they never give back and that no one ever reviews.

This problem becomes more serious in the cloud, where users don't necessarily have to be in the office to access resources and are not seen regularly. Even in collaboration with external partners and suppliers who have been authorized to use data for projects, the project managers and contact persons for the external parties are unlikely to tidy up.

Microsoft has developed access reviews for AAD that close the gap between reauthentication of authorizations and access to resources by enabling resource owners or IT administrators to request confirmation for all users in the scope of campaigns. Campaigns can be run once on demand or at regular intervals (e.g., monthly, quarterly, or annually). When a campaign is launched, affected end users are notified and need to confirm within a specified time that they still require access. Their confirmation – or active rejection – of further access is logged and results in the corresponding change in access.

The access reviews feature has different attestation methods. End users are either asked to take action themselves, or application owners or a group of delegates decide on a list of authorized users. In either case, each individual user must be approved or rejected. For end users for whom no response is available – either because the end user does not respond or the delegate cannot express an opinion – the system can, if so desired, automatically extend access at the end of the campaign, automatically deny access, or take action itself on the basis of login and usage data.

Configuration starts in the Identity Governance section of the AAD Portal below Access reviews | New access review:

• Review name gives you a place to assign a meaningful name: State the resources to be reviewed and the frequency of review in the name – all of which helps with administrative tasks later on.
• Description gives you more space for detailed information related to the application and what happens in the review.
• Start date defines when the campaign starts and reviewers need to be notified.
• Frequency lets you set the frequency of the review; the default setting is One time. If you plan to review the resources in question on a regular basis, this is the drop-down menu to change this value.
• Duration (in days) lets you define how much time you want to give the reviewers to confirm access. To prevent holidays and absences interfering with this process, you will want to allow four weeks before closing the door on people who have not confirmed.
• End indicates the end of the review if you selected a frequency rather than One time.
• Users lets you choose which user base you want to review either by referencing AAD groups or the concrete application assignment.
• Scope defines whether you want to check all access equally, or whether you specifically want to target external collaboration partners.
• Reviewers lets you determine the colleagues who will be able to perform the review: either specific, selected reviewers or the individual end users themselves, who then certify their future need for access (self-attestation).
• Upon completion settings sets how the system acts when individual users fail to respond if you opt for automatic changes. You can deny access, continue allowing access, or enforce system recommendations, which are based on historical usage data: If the user has not recently used the resource, they will be locked out.

Keeping Track

To track where users have permissions, you can choose User assignments reports in the Identity Governance section to run queries. This overview shows authorizations for individual users – the Access reviews function is intended for multiple users.

In the overview, click on the magnifying glass, Select users, and choose the user of interest. The system finds all the resources for which the target user has access, with a breakdown showing the access packages to which the resource belongs and how long access is allowed according to the linked policy (Figure 4).

Conclusions

Even this first version of the Identity Governance package for the Microsoft Cloud shows some useful features. Wherever users mainly access resources from the cloud or when collaboration with partners in the cloud is a priority, Identity Governance is a viable alternative to existing on-premises solutions that need to be made cloud-ready. The self-service functions are tailored to the various resources that can be integrated into AAD. At the moment, Identity Governance cannot yet hold a candle to mature systems, but the question is: Does it have to? In the near future, when many things will exclusively rely on the cloud, a paradigm shift or site-by-site operation could make sense.