Azure AD identity governance — Part 1 — The basics

I start this blog series with a quote from the Microsoft Docs on Azure AD identity governance.

“Azure Active Directory (Azure AD) identity governance allows you to balance your organization’s need for security and employee productivity with the right processes and visibility. It provides you with capabilities to ensure that the right users have the right access to the right resources, and it allows you to protect, monitor, and audit access to critical assets — while ensuring employee productivity.”

In this blog series, we will take a detailed look at all Azure AD governance topics. From the simplest settings to attestation processes with access reviews to complex provisioning processes and reporting.

The blog series

Part 1 — The basics

Part 2 — Govern identity lifecycle

Part 3 — Govern resource lifecycle

Part 4 — Govern Azure AD B2B

Part 5 — Govern access lifecycle

Part 6 — Reach back to on-premises

The basics

Before we deal with complex governance processes we need to ask ourselves a few basic questions. I call this the basics, but in the course of this blog series you will quickly notice that these are the challenge. Once this foundation is laid, it’s easy to put more complete processes on it.

• What identities are there in my environment?
• Where do these identities come from and who is allowed to create them?
• What resources are there in my environment?
• Where do these resources come from and who is allowed to create them?
• Who is responsible for these identities and resources?

In the following section I will try to answer these questions, but what is important is that even if processes are implemented for all areas, it is important to check that they are not circumvented. For example, the Identity Lifecycle can be automated based on a HCM (human capital management) system, but if certain groups of people still have permissions to create users manually, they might do so […The HR department takes so long again, I just create a user manually…]. Therefore, it is important to ensure that the processes cannot be bypassed or alerted when this happens.

Identities

To answer the above questions for identities, we divide them into different categories. This categorization can be done from two angles 1) contractual relationship 2) technical classification.

Contractual relationship

Internal employees

Owner: Human Resources

For many organizations, identity lifecycle for employees is tied to the representation of that user in an HCM (human capital management) system. The HCM system should therefore provide a solid foundation of data on which internal employees exist and need accounts.

External employees / Contingent workers

Owner: Sponsor or Human Resources

At very few companies, external employees are managed by the HCM system. Often internal employees (“the sponsors”) create a ticket at the IT department for the creation of a user account for an external employee. How exactly this process is handled differs from company to company, but two things should be mandatory for external employees.

1. A owner / sponsor
2. An expiration date (Contract end date)

Auditors

Owner: Requestor

Auditors should basically be subject to similar processes as external employees, I will only mention them separately, because they are often specially treated and should not be lost sight of. Especially because they often have access to many and sensitive company files.

Technical classification

It is important to understand that there is no one-to-one connection between contractual relationship and technical classification.

An external employee can have an ADDS account. An external employee can have an administrative account. An internal employee could be a B2B user in the environment after a company acquisition.

The technical classification is simply intended to broaden the angle of view, just because we cover a sub-area with processes does not mean that we have control yet, but somewhere we have to start.

1. Synchronized Active Directory Domain Services (AD DS) users
2. Azure AD cloud only users
3. Azure AD business-to-business (B2B) users
4. Administrative accounts
5. Service accounts

Resources

For resources the same applies as for identities, first we have to understand which resources exist to determine which processes are needed. In this blog I will not go into the resources in detail. The only important thing is to get an overview about which resources we should think about. Ask yourself the above mentioned questions for the resources listed here.

Azure AD resources

• Security Groups
• Distribution Groups
• Office 365 Groups
• Enterprise applications

Other resources

• Microsoft Teams
• SharePoint Online site collections and sites
• Exchange Online site mailboxes
• Exchange Online shared mailboxes
• Exchange Online public folders
• Azure Resources

Summary

We should now have a good overview of the identities and resources involved in the Azure AD Identity governance area. In the following blog articles we will complete the picture.

Stay tuned for part 2!