This post is part of a series.

Part 1 – The basics
Part 2 – Lifecycle Management and Provisioning/Deprovisioning
Part 3 – RBAC/ABAC, Entitlements Management, and Requests & Approvals
Part 4 –Separation of Duties, Certification / Attestation, and Privileged Access Management (this post)

Separation of Duties

SoD is sometimes referred to as ‘segregation of duties’. The typical example used for SoD is Accounts Payable and Accounts Receivable, because having access to both allows a single user to intentionally or unintentionally commit fraud and cover it up. This concept of checks and balances goes hand in hand with the concept of least privilege, which is imperative to enforce security policies for data access. Using SoD rules or policies when defining roles and entitlements is essential to prevent or limit the likelihood of a single user’s ability to negatively impact our systems. These policies not only protect the users from making mistakes, but they also limit how much damage an intruder can make if they are able to impersonate that user. SoD rules and policies ideally should be preventative measures. A good identity governance solution should provide the means to enforce these policies during the access request and approval process.

Azure AD currently offers this feature in preview. You can add specific incompabible access packages:

Or specific incompatible groups:

This means that if the user already has the incompatible access package assigned, or is a member of the incompatible group, then they cannot request this access package.

Certification / Attestation

We couldn’t possibly talk about access without mentioning access reviews. Because no process is ever perfect, including the JML process, we need to certify or confirm access. Access reviews are typically part of the Identity Governance solution and the purpose is to certify privileges a user is assigned are still required by the user. There are two main parts to the UAR process:

• Reviewers, who are typically the LOB owners for those privileges, review the users that are assigned and either approve or deny the access going forward.
• The privileges are automatically removed for any users who were denied by the reviewers.

Azure AD also offers options to send notifications and reminders to the reviewers to ensure they provide feedback within the allotted time. There are also options to automatically remove the access on denied or not reviewed outcomes, basically for anything that wasn’t specifically approved by a person.

Continuous access reviews for privileged access group membership and privileged role assignments are essential to re-certify, attest, and audit users’ access to resources.

Azure AD offers access reviews for:

• Access Packages
• Teams/Groups and Applications
• Privileged roles and groups managed via PIM (see next section)

Privileged Access Management / Privileged Identity Management

Privileged roles are at the top of the priority goals for attackers, that’s why they have to be protected with an equivalent urgency level. Microsoft has done a fantastic job of documenting recommendations to protect privileged users, especially when it comes to protecting those highly privileged users from on-prem attacks.

Azure AD offers Privileged Identity Management which provides the ability to assign privileged roles either active or eligible. This means that if a user doesn’t need access for their daily job, they can then be assigned that role as eligible, which means they have to activate it when they need to use it. That activation can then require additional requirements, such as:

• Azure MFA
• Justification for activation
• Ticket – if a support ticket is required for auditing purposes
• Approval

As you can see above, the activation can also be restricted to only a certain number of hours, and it can be scheduled. So, if someone is expecting to work on a Saturday morning, they can get their approvals earlier in the week and schedule the activation for the hours they plan to work.

Another great feature is the ability to expire those role assignments. Many times privileged roles are assigned for a specific project and sometimes in an emergency situation and there’s really no need for those users to keep the roles forever.

In this case PIM allows the assignments to expire and the users can then request extensions if they still need the roles.

Azure AD PIM currently supports the following groups and roles:

• Azure AD roles
• Azure resources (RBAC roles for subscriptions)
• Privileged access groups (preview), these are groups that can be assigned roles and have enabled privileged access.

Finally, one of my favorite features of PIM are the email notifications to ensure that once you implement PIM the assignments remain within the guidelines the enterprise has deemed necessary. The users that are assigned Global Administrator, Security Administrator, and Privileged Role Administrator will receive these notifications.

These administrators will be able to see if users are assigned roles outside PIM and/or assigned permanently, and they are provided with links to adjust the assignments as needed.

There is a LOT more to identity governance, but hopefully I have given you an idea of what an enterprise level solution should include and the tools that Azure AD provides to build on top of the robust solutions offered. On the road to implementing zero trust solutions, establishing a solid JML process is a big step forward for any enterprise. I know it’s called ‘governance’, but it’s much more than governance, it’s preventive security.

This post is part of a series.

Part 1 – The basics
Part 2 – Lifecycle Management and Provisioning/Deprovisioning (this post)
Part 3 – RBAC/ABAC, Entitlements Management, and Requests & Approvals
Part 4 – Separation of Duties, Certification / Attestation, and Privileged Access Management

Lifecycle Management

Lifecycle Management targets the creation of users and their privileges as they join, move, or leave an organization. It must be done from a central solution, in order to ensure accurate reporting and auditing, and because that’s the only way to ensure there are no lingering accounts or access when they are no longer needed.

User Lifecycle – Provisioning / Deprovisioning of users

User identities go through various main stages in the lifecycle. The typical stages are non-existent, active, disabled, and finally deleted. There are also possible transitions between those stages, as depicted below:

Each of these transitions is triggered typically by either the initial record creation on the “source of truth” or by updates to the attributes of the existing user records. This is the first component of the JML process, the provisioning and deprovisioning of users. When those transitions occur within the sources of truth, the provisioning solution receives that data and processes the equivalent required transitions on the target applications. For example, the hiring of a new user in an HR solution, will trigger the creation of a user in various target applications, including the main enterprise directory, an email solution, etc. A transition that triggers the creation of all users on a specific target application is sometimes referred to as a “birthright” application, because ALL users get access to that application, one example is an email target application, because typically all users require an email account.  Some applications will only trigger the creation of users based on a specific attribute, for example, only users that are hired for the finance department will need accounts created on a financial application.  A provisioning automation solution can use the value of ‘department’ to trigger the provisioning of users on a target application.

Some target applications do not require the users to exist at all in the target application to be able to grant access, because they use a type of federation that doesn’t require a local user to exist. You can see an example of that setup on my AWS Single Account Access blog post. You still need the user to exist on the identity provider (IdP), but they don’t need to exist on the target application. The privileges granted to the user are tracked on the identity provider only. This is a great setup because it eliminates the need to update users on those target applications.

However, the simple provisioning or deprovisioning of users on target applications does not constitute a full JML process. Normally when a user is provisioned to a target application, birthright or otherwise, they can be assigned “default” privileges, but most users will need different privileges, so default privileges are not always sufficient. That’s where the access lifecycle explained below comes into play.

Access Lifecycle – Provisioning / Deprovisioning of privileges

In the same way that users are provisioned and deprovisioned on the target applications, when required, they also may need specific privileges assigned and removed as they move through the lifecycle.  For instance, an engineer that is part of a cloud implementation team will need access to specific accounts and specific resources within that account. In her first job role, she may initially need privileges such as Key Vault Contributor for a specific vault for a specific project. Later on the same engineer moves to a 2nd position in a different department, and she will no longer need the access to the previous account, but now needs a different level of access on different subscription, such as Azure Kubernetes Service RBAC Admin.  This is the second component of the JML process, the provisioning and deprovisioning of privileges.

This second component of JML in itself has two main options:

• Some privileges can be automatically assigned and removed as the user moves through the lifecycle.  The automation of the assignment and removal of these privileges can be achieved using existing tools, such as Logic Apps that communicate with the Microsoft Graph API to trigger assignment of access packages. More on that on part 3.
• Other privileges have to be requested because they require additional approvals.

Azure Active Directory & SCIM

As mentioned on part 1, SCIM (System for Cross-domain Identity Management) is the standard protocol used for provisioning and deprovisioning. Azure AD supports SCIM protocol for a large number of applications and services, including well known enterprise solutions , custom apps, and on-prem applications.

For example, on my demo tenant I configured a few solutions to provision users and their roles to target applications. This example is for ServiceNow, where I configured provisioning and the job runs every 40 minutes.

So, when I assign Patti to ServiceNow with the role of User in Azure AD:

The user is then provisioned automatically to the ServiceNow instance with that role:

And when I remove Patti from the assigned users/groups, she is also disabled in ServiceNow:

I will expand on how roles for various applications can be packaged together for specific users in the follow-up posts on this series.

I have only scratched the surface of what is possible with Azure AD and SCIM. Azure AD App Gallery continues to increase the number applications and services that support provisioning of users and roles as our partners continue to develop their own SCIM connectors. Additionally, solutions for on-prem applications are also being used that support SCIM protocol.

The ability to use the SCIM protocol for all types of provisioning requirements is a huge Azure AD benefit for performance, reliability, and security reasons. Unfortunately, I have seen what happens when identity providers create their own solutions to provision users that do not follow the SCIM protocol and the results are often unpredictable, which in turn cause unnecessary headaches for IT Operations, Governance, and Security teams.

Update September 2022 – Microsoft released a new service called Lifecycle Workflows that helps with the automation of tasks based on the Joiner-Mover-Leaver cycle. I will write a separate post on this topic soon.

In the next post, part 3, I cover the concepts of RBAC/ABAC, Entitlements Management, and Requests & Approvals.

TL;DR – An overview of the Joiners-Movers-Leavers process and how it can be implemented using Microsoft Azure Active Directory.

When we read about the zero trust model and specifically, the principle of least privileged access, most people think about just the authentication and authorization process. Although that is a huge part, we cannot forget about the processes associated with identity governance that are there to control the specific access those identities possess and how long they have the access. The ultimate goal for any enterprise should be to have one central Identity Governance solution because that is the only way to guarantee an auditable joiners/movers/leavers (JML) process for all employees. That’s the topic of the posts in this series:

• Part 1 – The basics (this post)
• Part 2 – Lifecycle Management and Provisioning/Deprovisioning
• Part 3 – RBAC/ABAC, Entitlements Management, and Requests & Approvals
• Part 4 – Separation of Duties, Certification / Attestation, and Privileged Access Management

I grew up in the Caribbean in a house that didn’t have A/C, needless to say it was HOT! When we go back to visit, my sons can’t understand how I survived all those years without A/C. The truth is I didn’t know there were better options. That’s what comes to mind when I see enterprise customers depending on identity providers that don’t provide all the identity governance tools to implement a full JML process. So, this post is an attempt to share what enterprise customers should expect from their identity providers when they refer to identity governance solutions to accomplish an enterprise level JML process. All of which is available with Azure Active Directory.

What is JML?

• Joiners – The joiners process covers the identities that are created for the employees that join the company. The joiners process will also include providing the minimum required access on a variety of applications and services for that user to be able to do their job.
• Movers – The movers process covers the removal and addition of access to the identities of employees that move to a different position, department, location, project, etc. For example, if the employee transfers from the accounting department to the sales department, then they should no longer have access to accounting applications and services, now they should be granted access to sales applications and services.
• Leavers – As the employees retire or are terminated, the access they had should be removed, and their users should be disabled and/or deleted.

A simple goal, an enormous challenge.

The goal of a JML process is to provision, and eventually deprovision, user identities and their privileges to the target applications and services only for users that need it and only for the time they need it. It is a simple goal, but it is an enormous challenge to achieve for all identities in an enterprise. The challenge comes from the number of target applications and services and the number of identities. The higher those numbers are, the higher the complexity. Keep in mind, identities can be the individual user identities as well as their non-user accounts, such as accounts used for administrative tasks.

This complexity is why any enterprise should aim to automate the JML process as much as possible. And that is where a good Identity Governance solution comes in. Partners can then build upon the available solutions to automate the identity governance requirements for enterprises. I’ll cover the details of how that automation can be achieved in the follow-up posts of this series.

What about workload identities?

Even workload identities for machine-to-machine access should be included in some of the identity governance processes, such as access reviews, because they also have permissions associated and therefore we also want to enforce the principle of least privilege on those identities.

A quick note on sources and targets

I mentioned above “target applications and services”, but let’s cover the source first, because for a target to exist, there must be a source. What is commonly referred to as the “source of truth” in identity management is typically an HR system or some directory, where the users are created initially when they are hired as employees or contingent workers. Sometimes you have more than one “source of truth”, for example, if you have one system for employees and another one for contingent workers or if you are getting attributes from other sources. Keep in mind, the “source of truth” is not necessarily the identity provider, in other words, the source of truth is just the initial location of the user data where it exists, where any identity provisioning solution will pull information from about the user and its attributes. Which is not to be confused with the identity provider (IdP), where users authenticate for a SSO solution, because that’s a topic for a different day.

What are the targets then? The identity provisioning solution will get the data from the “source(s) of truth” and based upon the values of those attributes it will then provision and deprovision user identities and privileges to those target applications and services. You can see another over simplified diagram of the solution above. I am not going too deep, but just keep in mind we can also reconcile specific attribute data from target applications back to the provisioning solution, making the targets also sources for specific attributes, because other target applications may need those attributes as well.  

As you can imagine, the values of those attributes don’t remain the same for the entire lifecycle. Attributes such as last name, department, job position, and many others are updated constantly. This is why a central identity management solution integrated with all target applications and services is essential to ensure all those dependent values are updated on target applications as changes occur. And more importantly, the updates of those attributes is what triggers the stage changes and privilege assignment/removal in target applications.

What does Identity Governance include?

A full identity solution should include identity governance and what that includes sometimes can be represented in different ways by different identity service providers, depending on what they offer. Some identity service providers do not provide identity governance solutions and if they do, sometimes they only provide a portion of these. Fortunately, Microsoft, and specifically Azure Active Directory, provides the full range of identity governance solutions required for a successful joiners-movers-leaver process at an enterprise level. Here is a simple list of what an enterprise should require:

• Lifecycle Management – We need to be able to manage both the user lifecycle as well as the access lifecycle. It is very important that we do this from *one* central location, because that is the only way to ensure we know what access a specific identity has on any target application/service. This is also the only way to ensure accurate auditing.
• Provisioning/Deprovisioning (SCIM) – Some applications and services require local identities to be created, so we need to be able to provision those users to the target applications when they are onboarded and then deprovision them once they no longer require access to those applications and services. SCIM (System for Cross-domain Identity Management) is the standard protocol used for provisioning/deprovisioning.
• RBAC / ABAC – Role Based Access Controls and Attribute Based Access Controls. Basically, we need to assign those identities the access that is appropriate for the job they are doing, which can be based on their role, the project they are working on, the location they work from, etc., and only while they need it.
• Entitlements Management – Entitlements are the access permissions that can be assigned to users. They can be in the form of group membership, application roles, OAuth scopes, etc. We need to be able to manage or group these permissions to enforce RBAC/ABAC. By now you know my opinion on groups vs roles and I also gave you some basic info on OAuth and it’s scopes.
• Access Requests and Approvals – Users need to be able to request additional access that was not automatically assigned to them for valid reasons. And that access should be approved by the proper LOB owners or managers, etc.
• Separation of Duties (SoD) – We need to be able to mitigate and reduce risk by isolating privileges that when combined can cause significant errors or intentional fraud. Think of this as ‘checks and balances’. SoD is sometimes referred to as ‘segregation of duties’.
• Certification / Attestation – We need someone to be able to certify or attest that the permissions those identities have at that time are in fact required. This is normally achieved via scheduled access reviews.
• Privileged Access Management – The access to roles that are considered highly privileged should have controls in place that reduce the risks by enforcing JIT (Just-In-Time) access.

I’ll cover how an enterprise can use Microsoft Azure Active Directory security solutions and how partners can build upon them to address all these requirements in parts 2, 3, and 4 in this series.