A warm welcome to my next blog series! In this blog series I will explain to you what Azure AD Identity Governance is, what options currently are available, how to implement them and how to best get started with Azure AD Identity Governance.

Each organization around the world is using an identity platform, where some are using Active Directory, some are using Azure Active Directory and some are using them in a hybrid mode (and some of them don’t use a Microsoft directory). Without an identity, and therefore an identity platform, it’s quite hard to access applications and resources. Therefore the Identity platform must be seen as the control plane within your organization.

Nowadays I see lots of organizations struggle with actually using the Identity platform as the control plane, I’ve summarized some of the most common struggles below:

• End user accounts of new employees are still created manually by the IT department;
• End user accounts aren’t disabled / deactivated when employees leave the company;
• Role based access control isn’t implemented for end user accounts. Roles and / or Job Titles within an organization aren’t connected to RBAC which will give the end user the necessary access to do their daily job;
• When employees switch job role within an organization they aren’t removed from groups belonging to their previous role;
• Access requests consist of manual actions by the IT department;
• Access to resources and applications, in most cases, is given permanently and therefore never reviewed if still required;
• Guest Users (External Identities) have been provided access to information but access is never revoked.
• IT has no idea what permissions users have, and this is not traceable;
• IT Administrators have a permanent admin role assignment in like forever.

All of the above mentioned points are a (big) risk in IT environments but how do you get back in control as an IT admin? Most of the above mentioned points can be solved easily by implementing Azure AD Identity Governance. However, to start with Azure AD Identity Governance I would strongly urge you to first start with an Identity Governance Strategy for your organization to make the Identity the control plane within your organization!

Identity Governance Strategy

Starting with an Identity Governance strategy is the first step in making the Identity the control plane within your organization. Without a solid strategy there are to much blanks to fill in, therefore there is a high risk that the implementation will fail or doesn’t have the result you wanted to achieve. To determine the strategy for your organization I’ve determined the following eight pillars :

1. Make sure your identities are centrally managed in Azure AD and are secured;
2. Make the HR department responsible for the identity lifecycle(s), HR data will become the ‘source of truth’ in your environment. IT should empower them in this;
3. Make sure that user access & provisioning to (3^rd party) apps is managed from Azure AD;
4. Identify Access Packages & Access Reviews which can be created for your organization;
5. Implement the identified Access Packages and Access Reviews;
6. Implement (Just in Time) JIT permissions for your administrator accounts with Azure AD PIM;
7. Define and implement a ‘terms of use’ which your end users have to accept to use organization-data and -applications;
8. Monitor usage and make the necessary changes / additions within the Identity Governance strategy when, and if, needed.

Once you have determined your Identity Governance strategy, start the implementation from point one and walk through them point by point. Don’t try to implement your whole strategy in once, take your time to do things the right way. This does mean that it can take time to transition, but it is better to have a solid strategy & implementation which is adopted by your end users than an Identity Governance service & strategy which nobody is using.

For services which can’t be transitioned to an Identity Governance strategy, like traditional on-premises applications which don’t support provisioning, you still have to do it the old fashioned way for now. This is another good reason to modernize your identity- & application landscape.

Azure AD Identity Governance options and use cases

Now maybe you already do have an Identity Governance Strategy, or looking to write one, it’s always good to explore the options. So let’s have a look at what options we have in Azure Active Directory, which of those we can use to solve some of our challenges and therefore need to be incorporated into the Identity Governance Strategy.

1. Centrally manage your identities

It all start with a solid and strong identity foundation. Making the Identity the control plane in your organization can only be done when there is a good foundation (compare this to your house which, I hope, you also won’t build without a strong foundation).

The foundation in that case will exist of either a hybrid identity or a cloud identity. If you are running a hybrid identity, make sure all your identities are synchronized from one on-premises Active Directory forest. If you are running Azure AD standalone (non-synced cloud identities) make sure all identities are available within one single tenant (when possible of course).

In both scenario’s I would strongly urge you to at least protect these identities with Azure AD multi-factor authentication, better would be of course to provide them with a more secure, Conditional Access Based, and user friendly password-less experience, for which I wrote several blogs in the past.

2. Identity lifecycle

Once you’ve verified that there is a strong identity foundation which we can use to build the Azure AD Identity Governance service on. The first step would be to look at the Identity lifecycle process. These days, most organizations are still using a manual provision process where HR will simply notify the IT department via an email or a ticket of a new starter for which a user account needs to be created.

This process has a very high risk in misconfigured end users accounts, i.e. lots of manual actions, copied accounts with too much access rights (of a previous employee, which is used as a source for the copy), wrong spelling of user names, etc. Not even mentioning the leaver process where I’ve seen loads of examples where HR doesn’t send an email to IT of an end user leaving the organization, whereby the account stays open after the user has already left the organization.

To automate this process (joiner, updates & leaver) to prevent misconfigured accounts and therefore high risks in your environment, Azure AD currently has a solution. This solution is based on user provisioning from HR apps to Azure and is at the time of writing only available for SAP SuccessFactors and Workday HR applications.

Configuration on both ends is required to get this working and will make sure that the HR information is your source of truth and will therefore provision, update or delete user accounts in either Active Directory and / or Azure Active Directory. Doing this will make sure that if HR will create or change a user in their system, the user is also created or updated in Active Directory and / or Azure Active Directory with the respective changes (including the disablement of end user accounts). This way IT empowers HR to be in control of the user-information of all colleagues within the organization. IT should not be the intended owner of this information and by implementing this approach HR is enabled to control this data.

By making the HR-application the source of authority for Identity-related information, HR is in control and IT only has to connect Identity- and apps to that system.

Arranging the identity lifecycle process will solve several challenges and frustrations:

• When a user starts there is always an account for the end user. HR is the first to know the exact start date of a new employee and can therefore insert this information a long time before the actual start date of the end user. If/Once an automated process is in place, the information can get processed and the related account is created in an automated way;
• When the user ends his contract, HR is always the first to know and can update their information. Therefore, after the user has left the organization the account is automatically disabled;
• All data set on the account, like a display name or job title is always matching the HR data, nothing is more frustrating for an end user than incorrect personal information set on his account (think of marriage, divorce or internal job switches).

This lifecycle process only has a focus on user accounts. This means that the above mentioned lifecycle process doesn’t include shared mailbox accounts, room accounts, service accounts, service principals, etc. So keep in mind that this will solve 80% of your lifecycle process challenges. For the other scenarios, think about a suitable (manual) process to also keep track of their lifecycle.

3. Access and provisioning to 3^rd party applications

In the previous step we have learned that we can make the HR data the source of truth for the end user accounts which are available in Active Directory and / or Azure Active Directory. But most organizations have way more applications then just an HR application. Therefore, it’s important to make sure access and provisioning to these other 3^rd party web-based applications is also managed from the Azure AD. This, as you don’t want to have someone of your finance department still being able to access the finance application when he or she left the company. The first step to achieve that result would be to get those applications connected to the Azure AD, which I already described in one of my previous blog post.

Once those apps are connected to the Azure AD, we can have a look at provisioning user accounts from the Azure AD to these 3^rd party web-based applications. First of all, the provisioning in Azure AD to these connected web-based applications is based on System for Cross-domain Identity Management (SCIM), an open industry standard. By default Azure AD has a SCIM endpoint available in Azure AD for (supported) applications, and is therefore able to talk to your application via the SCIM 2.0 REST API. So, it’s important to check if the application supports provisioning via SCIM, or if it’s an in house developed application make sure that the application supports SCIM by building the SCIM 2.0 REST API for the application.

If (or once) the application supports SCIM we can use it within the provisioning feature within the Azure AD within the settings of the application. This will give you the ability to synchronize the attribute values of users (and groups) to your connected application from the Azure AD. Additionally, costs can be saved on excessive licenses being used/configured for 3rd party apps for accounts that are no longer being used by the user. All of this has already been described in my previous blog post.

Doing this will make sure that if someone at HR is changing the job title for one of the end users, this change is reflected in the HR system, Active Directory, Azure Active Directory, but even more important: this job title change will also be reflected in the connected 3^rd party web-based applications which are enabled with provisioning in Azure AD (via SCIM). This is all part of an automated fully supported scenario without any kind of integrations that you have to build your own.

4. Entitlement Management

Now that whole identity lifecycle process, from HR to a user account and from a user account to an account within an application has been determined, the next step is to look at entitlements. These days I still see a heavy load on IT when it comes to access requests for specific resources. Instead of requesting this via IT we should, in a modern world, let the user request their access themselves with an approval process by their manager or the owner of the specific resource. Do this so IT only needs to provide an access package, or access to a specific group of end users, to manage those access packages (that they own).

Now to achieve users are able to request access to a resources themselves, we need to determine what entitlement controls within Azure AD Identity Governance we are going to use. Within the Entitlement management blade in Azure AD you can configure several options, like the configuration of:

• Access Packages; Create access packages which can be requested by end users to provide access to resources. These can be combined resources (like the access that you need for your role), but can also exist of single resources (like access to a Microsoft Teams team which contains highly confidential documents). For each access package you can define loads of settings like: a justification reason, approval, expiration, access reviews and more.
• Catalogs; Catalogs can be used to delegated the control of access packages to a specific group of users. As users can (possibly) create a Microsoft Teams team themselves, it is a great benefit if these users can add that Microsoft Teams team to the already existing access package in your environment.
• Connected Organizations; Connected Organizations are, in simple words, whitelisted external directories, which you’ve allowed to request an access package which resides within your environment.

Now that you know what is possible, determine what your approach would be for entitlements. Are you giving some control ‘out of your hands’ by letting some end users manage some catalogs, or are you going to create and manage access packages for your end users yourself? Both solutions are perfectly fine, but for both cases you need to think of the scenario’s you want to cover with entitlement management. I will name a few which will give you a good starting point:

• Define an access package per department, which you have in your organization, which users are able to request when joining the company or switch from roles within the company (i.e. HR, IT, Finance, etc.);
• Define an access package for licensed software which is either connected to the Azure AD or deployed via Endpoint Manager (i.e. Visio, Project, Dynamics 365, Slack, Salesforce, etc.);
• Define an access package for access to a confidential document store (SharePoint Sites, MS Teams);
• Define an access package to approve very specific access (i.e. by making the user a member of a group which will give the end user access to use the USB ports on their desktop/laptop);
• Define for all packages you’re planning to create if an expiration is needed to either let the access expire anyway or provide the end user with an option to extend their current access (with an approval flow if required);
• Define for all packages you’re planning to create if an access review is needed to let the user, or someone specific, review if the access is still required.

At this time there is unfortunately no way to provide access to synchronized groups or other resources/objects from you on-premises Active Directory, so for now this is a cloud only feature and usable with resources connected to the Azure AD.

5. Access Reviews

Now we know what entitlements are, and you possible already have some ideas how these should be created. The next step would be to have a look at the current estate of access which is already in place (unless you’re starting a brand new tenant from scratch of course). This, as creating an access package, which we talked about earlier, won’t help the reviewal of the access which is already given and provided to end users in your tenant.

This step requires you to, again, make a good inventory of the access which is already in place and for which of those you want to let the end users or the owner of a group do the reviewal. This process can be seen as simple housekeeping, but can help you to make sure the access which is given is really required and still needed.

Imagine if those copied accounts, which I mentioned earlier, had some highly confidential access. This would indicate that the access which is in place is incorrect and need to be reviewed by the owner of that group so that the ‘copied access’ is reported and can be removed.

Another good example are guest accounts which do reside within your Azure AD, as an IT admin you really don’t know if those particular users still work for that organization or even worse if they still do need the provided access. This can be considered, in some situations, as a high risk in which access reviews will bring a solution for you. This is also part of the lifecycle management you want to have in place but then specifically for guests in this case.

Access reviews are a perfectly fit for the above two scenarios and will therefore help you to build a better strategy and implementation of your Identity Governance solution.

6. Privileged Identity Management

Now once the access reviews are determined, we are getting somewhere. Most of the user focused Identity Governance parts are now in control and covered within an Identity Governance plan. There is, however, one extremely important part which falls out of scope when only looking at user functionalities. This is Azure AD Privileged Identity Management (Azure AD PIM), which can provide administrators with just in time (JIT) access to perform administrative tasks within your Azure AD Tenant. Meaning an account is only granted the specific (additional, privileged) access permissions for a specific, limited period of time. During that time the tasks can be completed, after which the permissions will be automatically relinquished.

The biggest advantage of Azure AD Privileged Identity Management is that you can assign yourself and your co-administrator(s) multiple roles. Which will give you or your co-administrator(s) the ability to activate one (or more) of the assigned roles, which they require at that point in time to execute their administrative task(s).

An example can be a change in Exchange Online for which the administrator needs the Exchange Administrator role or a change in SharePoint for which the administrator does require the SharePoint Administrator role. For both of the examples the user first goes to the Azure AD Privileged Identity Management portal, activates their role for a specific time period and executes their task(s). Once the assignment expires the user is removed automatically from the role and the user needs to activate the required role again once needed.

Each role which is available from Azure AD PIM can be customized with settings, which can be of great benefit for highly privileged roles like the Global Administrator role. Think of approvers who need to approve that kind of access, justification reason which need to be filled in by the requestor, expiration of assignments, Require Multi-Factor authentication on activation, etc.

An Identity Governance strategy without JIT via Azure AD Privileged Identity Management can be compared to ‘forgetting to lock the back door of your home when going on a holiday’ in normal life. Over-privileged accounts form a risk from the security point of view as, if an account is breached, the intruder automatically ‘inherits’ its applied permissions. Therefore this is a hard requirement to have in your strategy and is one of the must haves for the implementation.

7. Terms of use

Now we have described loads of technical features which you can use to get you Identity Governance Strategy defined. There is one thing we are still missing, which is the Terms of Use.

Terms of use is a feature which you can use to let your end user ‘accept the terms of use’ to use the cloud environment of your organization. Users must accept the Terms of Use and/or have to consent on every device and eventually, when you want to, have to do that with a recurrence of i.e. 90 days.

The advantage of this is that you can actually have the user to accept the terms of use before they can even use the environment, tis data and its apps. Even more important you can actually trace that this has been accepted by the end user if required.

This way you can make sure everyone has had the chance to read the terms of use and therefore is informed of the official terms of use applied and active for your organization. This also enables you to leave that paper-process behind where each colleague that joins the organization has to sign the printed agreement on using IT-services. Everything is auditable and helps save some trees!

8. Monitoring and Reporting

Now that your whole Identity Governance Strategy is defined, it’s time to start the implementation. During the implementation it’s good to do reporting and see if your implemented strategy is actually being used and adopted by your end users. Maybe you’ve missed some groups or some settings need to be altered? Providing a good user experience is key here, this as we don’t want users to start complaining.

To help get insights in the actual use of the created access packages and access reviews there are some dashboards available. It’s good to review those with the actual use within your organization once the implementation is finished. Based on those reports you can conclude that some access packages and reviews are configured correctly and maybe some of them need to be changed.

On the other hand it’s really important that you need to keep monitoring to see if there are (new) services which you can add to your Identity Governance Strategy. Like newly created groups for applications or access to SharePoint or Microsoft Teams. Therefore this should be an ongoing process in your organization and should always have your attention when adding new services to your tenant.

Conclusion

Now you know all the options Azure AD Identity Governance has to offer and you’ve defined your Identity Governance Strategy it’s time to go through some of the actual implementation steps. In the upcoming blogs I will go over all of the above mentioned features one by one. I will do this by showing you some examples on how to start your implementation (if you want to see some examples, please leave your example request behind in the comments, I do however make no promises that I can cover them all 🙂 ).

I hoped you enjoyed reading my first blog of this series about Azure AD Identity Governance! Stay safe and stay tuned for more Azure AD Identity Governance blogs soon! 🙂

• An Introduction to Azure AD Identity Governance
• Identity Governance 1 of 10: Implementing a Strong Identity Foundation
• Identity Governance 2 of 10: Implementing Identity Lifecycle management for guest users – part 1
• Identity Governance 2 of 10: Implementing Identity Lifecycle management for guest users – part 2
• Identity Governance 2 of 10: Implementing Identity Lifecycle management for guest users – part 3
• Identity Governance 3 of 10: Configuring Provisioning in 3rd party apps for (guest) users
• Identity Governance 4 of 10: Implementing Lifecycle Workflows – Configure the basics
• Identity Governance 4 of 10: Implementing Lifecycle Workflows – Configure onboarding workflows
• Identity Governance 4 of 10: Implementing Lifecycle Workflows – Configure offboarding workflows
• Identity Governance 5 of 10: Using the hidden gems in Azure AD access packages, all you need to know! – Part 1
• Identity Governance 5 of 10: Using the hidden gems in Azure AD access packages, all you need to know! – Part 2
• Identity Governance 5 of 10: Using the hidden gems in Azure AD access packages, all you need to know! – Part 3
• Identity Governance 5 of 10: Using the hidden gems in Azure AD access packages, all you need to know! – Part 4
• Identity Governance 6 of 10: Implementing Access Reviews
• Identity Governance 7 of 10: Implementing Privileged Identity Management
• Identity Governance 8 of 10: Implementing a Terms of use
• Identity Governance 9 of 10: Review by Monitoring and reporting
• Identity Governance 10 of 10: Implementing Identity Lifecycle management for employees