Best practices to simplify governing employee access across your applications, groups and teams

In the modern workforce, the emergence of hybrid cloud deployments and collaborative applications make it easy for employees to share information, data, and files with other internal as well as external users, helping them collaborate easily with vendors, business partners, contractors and customers. Managing all the access across different resources – Office groups, Teams, SharePoint sites, as well as your own applications and SaaS applications – is challenging. As requirements change with new applications being added, or users needing additional access rights, IT staff may not know who should have access or to which applications. To succeed at scale, an identity governance process must enable all users’ access to be able to change with their needs, without burdening IT staff to be involved in each access request.

 

Azure AD entitlement management, a feature of Azure AD identity governance, helps organizations manage their access lifecycle at scale by automating request workflows, assignments, reviews, and expiration. You can empower users to request access to the resources they need. These requests and the resulting access can be approved and regularly reviewed by people across the organization who know whether someone should still have access

 

Here are some common questions we’ve received from customers about how to manage employee access.

 

Question 1. In the past we’ve configured that our AD- and ADFS-connected applications were open to everyone in the directory to access, as we only had employees and vendors in our AD.  Now that we’ve moved these applications to Azure AD, we want to lock down access to those apps and move to app assignments so that users don’t inadvertently have access.  What are the best ways to manage application assignments to make sure users don’t have access they don’t need?

 

Azure Active Directory (Azure AD) supports multiple approaches for access management for your own applications, including SaaS apps, cloud-based federation-based apps and on-premises AD-connected applications via the Azure AD app proxy, enabling organizations to easily achieve the right balance of access policies ranging including automatic, attribute-based assignment, as well as delegated assignment.

 

As described in the article managing access to apps, traditionally access management starts with either individual assignment, one for each user, or group-based assignment. Group–based assignment works well if you have an existing security group that you could re-use. However, keeping the membership consistent could be challenging if you have multiple applications. Suppose a user named Alice, and others in the same department as her, need access today to two apps. If there’s a group that has Alice and the other users as members, you could assign that group to those two apps. However, if Alice no longer needs one of the apps, that would require restructuring the groups to avoid audit findings of users having excessive access, and could lead to a proliferation of groups, potentially as many as there are apps. 

 

Another way to manage access to applications is for the users to receive entitlement management assignments for an access package that includes those applications and have those assignments set to expire or be regularly reviewed.  Through Azure AD entitlement management in the Azure portal, an administrator or a resource owner can create an access package with one or more applications. A user can request access to that access package through the myaccess.microsoft.com UI, or an access package catalog owner can assign access to users in the Azure portal. You can also have users request or create assignments programmatically, through Microsoft Graph, as shown in the tutorial for how to create an access package using Microsoft Graph APIs. When a user is approved for access to the access package, they are assigned to the application.

 

You can ensure that users do not have access indefinitely by configuring automatic access reviews as part of the policy. You could have different policies for different collections of users so that their review schedule is based on the likelihood of the user no longer needing access or the risk of inadvertent continued access.  Each policy in an access package can have a different access review frequency for reoccurrence or different reviewers.

 

The “Create policy” screen in the Azure portal for an Azure AD access package, showing the lifecycle tab in which quarterly reviewing access reviews are required.

 

For example, you could have one policy that gives users in the IT department a shorter maximum duration of access as they’re performing administrative tasks and another policy from users in other departments.

 

Question 2.  What about giving users access to Office 365 and other Microsoft applications?  Not everyone in the directory has a license, and we don’t have relevant data in our HR system to be able to create a dynamic group of just those people who need a license.

 

For applications in Office 365 or other paid suites, users can be granted access through license assignment either directly to their user account or through a group using the group-based license assignment. 

 

Combining group-based licensing and entitlement management for users to request an access package that results in license assignments simplifies giving users licenses they need.

First, in the Azure portal, create an Azure AD security group, and configure that group to give license assignments.

 

Then, create an access package containing membership in that group as a resource. If you select  to have the requestor’s manager as approver in the policy, then each requestor’s manager can decide if the requesting user has a need for the license for these applications.

 

The “New access package” screen in the Azure portal, for a policy configuring manager as approver.

 

Once a user requests and is approved, they’re automatically added to the security group, and Group-based license assignment gives them a license.

 

In access packages which give licenses, you may wish to configure a long duration prior to access package expiration or a “Never” setting with access reviews to avoid a user inadvertently losing their access package assignment and their use of Office while on vacation or on leave.

 

Question 3.  As we roll out Office groups and Microsoft Teams in our organizations, employees may inadvertently try to join public teams that sound relevant but aren’t the appropriate team for them. How can we cut down on unnecessary work for teams owners to approve requests and maintain their memberships?

 

An organization can publish a curated collection of teams that they want to make available for users to join by creating access packages for each one (they can include multiple teams in a single access package as well). They can then configure the requestor’s manager as needed for approval, approval by a departmental list of approvers, or both.  Once approved, the user is then added to the Office group and team, and can collaborate.

 

For example, if it wasn’t known in advance everyone who might need to be a member of a team, such as for a marketing launch, the marketing department could create the team as private. Next, the team owners could manually add or share a code with those individuals who are known and likely to need to be part of that team. 

 

To bring in the rest of the necessary members from other departments who aren’t known but avoid users being added who do not have a business requirement, they could create an access package for that team.

 

The “New access package” screen in the Azure portal.

 

If there are additional resources, such as a SharePoint Online site or applications, those could be added to the access package as well.

 

The policies for the access package could scope to only allowing certain users to request access, and could also require approval by both the requestor’s manager, and by the members of a departmental group. 

 

The “New access package” screen in the Azure portal, creating a policy for all member users to be able to request.

 

The first stage would specify the manager as approver. You can also configure a fallback approver for requestors who don’t have a manager.

 

The “New access package” screen in the Azure portal, setting the first approver stage in a multi-stage approval workflow.

 

And the second stage could have a different approver, such as members of a group. 

 

The assignments created through that access package could also be set to expire automatically on a predefined date, to avoid users remaining in the team indefinitely.

 

The “New access package” screen in the Azure portal, setting the access package assignment lifecycle for the policy.

 

Furthermore, additional resources that users might need access to,including access to SaaS applications, in-house developed applications, other existing security and Office groups, and SharePoint Online sites, can be added to the access package. Users with assignments to the access package will then automatically be given access to those resources as well. 

 

To find out more about Azure AD identity governance, including access reviews, privileged identity management, and how to manage the lifecycle of business partner guests see What is Azure AD identity governance? and What is Azure AD entitlement management?.  There are also case studies for how digital innovator Avanade chose Azure AD Identity Governance for streamlined, highly secure collabor… and how the leading energy and services company Centrica solved collaboration challenges with Azure Active Direc….