Been working on this blog post for a while as this talks about an important service in Azure AD. In a standard organization environment, how many resources will a user access from the point where they have Onboard to the day that they are offboarded from all the systems? Are you able to keep a track of all the access requests? or are you able to automate user access and apply some smarts throughout the employee lifecycle for those scenarios? Limit IT Service Desk interactions from those types of activities so they can focus on important matters.
My solution is mainly around Lifecycle workflows (LCW) – The newest member in the Identity Governance family which is still in the preview that looks very promising in automating the tasks.
Along with that, Dynamic Groups, Entitlement Management, Access Reviews, PIM, and Features of Microsoft Entra Identity Governance can build a near-perfect solution to address many Identity-related malpractices and can close loopholes. When I say near-perfect, it is because no system is 100% perfect and it’s a continuous effort to keep it relevant.
In this blog post, I would like to look at the above features and try and come up with a connected solution.
Rather than presenting a 100% technical approach with all the nitty gritty, as the heading says, I like to connect the dots and make a strong case as to why you need the feature set to be inter-connected rather than treating them as separate entities in the Identity Governance bucket. Yes, there are situations where you need to treat them as separate entities depending on the situation but not by default.
What I will be covering 👇🏽
- Ad-hoc Tasks we are carrying out today
- What’s lacking?
- Is Lifecycle Workflows The Missing Link?
- ♻ Building The Identity Governance Eco-System ♻
- Licensing Requirements
- Wrapping Up
Ad-hoc Tasks we are carrying out today
When a hire in the organization, most of the time it’s a request to the IT Service Desk from HR to create the user account prior to the start date, new hires’ particularly along with the department, manager and etc. This is a very standard and no-brainer situation. Some organizations use Power Automate to set up a workflow and make everything automated up to some extent while some organizations use 3rd party HR applications with hooks to the On-premises AD or to Azure AD to create users once they fill out the form. These are all acceptable practices as the basic objects are getting created etc.
Once the user account is created, it’s most likely another IT Service Desk manual task to add the user to the relevant mail distribution lists, Teams, SharePoint sites, etc.
During the user’s lifetime at the organization, there are many access requests to sensitive data and in most cases, someone needs to provide access with the relevant RBAC (Role Based Access Control) but forgets to remove that when the task or the period is finished.
Inter-departmental moves happen very often and once the user is moved they will be getting more access to resources on top of the existing access and added to more groups but most of the time the previous access is not removed and chances are the user ends up with a bunch of access that doesn’t require anymore.
Or the chances are sometimes the user doesn’t know which access to ask for when they joined the organization so they might check with a team member and advise IT to mirror the access. This approach will have a 50/50 chance of that user ending up having access that does not require.
When was the last time you advised IT Service Desk to remove these users as they no longer need access to that sensitive Team? Usually, group membership reviews are done not very often or not done at all. Users might ask IT to remove them from some mail distribution lists as they see the mails are coming in that they are not needed, but access to systems, RBAC, and other resources – this can result in piling up members that do not need any access anymore to that resource as the access is sitting there silently.
When the user resigns, again the HR would send the last working day, etc. IT does the necessary work to disable the account. Sometimes mistakenly the account can remain in the system without any changes being made despite the HR request. This can be a challenge when auditing comes into play and generally to your whole identity management practices and to the overall Security.
Above all are ad-hoc type activities which are not most of the time not interconnected. If everything is interconnected in some way or another – Kudos to you 🎇
Now that we went through a few scenarios, let’s discuss what’s lacking in that practice.
What’s lacking?
In three words – Modern Identity Capabilities. That starts with Automation. Setting up will take some time as you need to plan your scenarios and run a proof of concept may be or run a Pilot for a while, but it can be an investment and the right use of the licenses. Most of the time, it’s a question where you utilize the full capability list of the licenses. Most of the time the answer is NO. Mainly because of the incorrect understanding of the usages or not knowing the capabilities of a connected scenario.
Is Lifecycle Workflows The Missing Link?
Microsoft recently introduced the Lifecycle Workflows feature which is in Preview under Identity Governance. And to answer the above question, I think yes it is the missing link. Before introducing this feature Identity Governance had pretty much everything other than a user Onboarding related feature other than the Graph API to creatively adopt it in the apps. With this feature, you can directly plug in the HR Management application so it will be a seamless process. Check this link for more info
As always you can create your Lifecycle Workflows without connecting to an app and let it run according to the given schedules or run on-demand. For my solution, Lifecycle Workflow will be the base.
Introducing New Attributes
employeeHireDate
employeeType
employeeLeaveDateTime
This is a new attribute set Microsoft introduced lately that can be used for the LWCs. These can be mapped with your HR management application (link below), or customExtensionAttributes can be set up from the Local AD that will be mapped onto these cloud attributes accordingly.
If you are in a hybrid environment, you can setup the Custom Attributes of the user object which will correspond to these attributes and depending on the workflow, the user object will be added to the scope.
Ideally, these can be setup using Sync Rules in AAD Connect Sync. 🔗Check this well written artile by MVP Jan Bakker on setting up the rules for the employeeHireDate attribute
🔗More on HR App and attribute mapping can be found here
You need special permissions to use the attribute employeeLeaveDateTime as it can be sensitive.
🔗Check this document for more about that
♻ Building The Identity Governance Eco-System ♻
Below is an illustration I did for the purpose of understanding the features. You can see I’ve added Dynamic Groups in the mix even though it is not a direct part of the Identity Governance. I will explain that shortly.
As I mentioned earlier, you can certainly use the individual features depending on your scenario.
Also, this is not a full-on technical approach. I will reference the relevant technical documents as I go.
🖱️Click to enlarge the image
Below is an illustration is a workflow of the full feature set.
🖱️Click to enlarge the image
These figures look like a lot and can be a bit hard to understand. But let me explain
Life Cycle Workflows
Ideally, either Onboarding or Onboarding Pre-Hire templates for Joiners are the ones to use. Basically, you can use the Temporary Access Pass option so you have the option to go Passwordless or get the user to set the password.
🔗Understanding Lifecycle Workflows
🔗Check this link to setup TAP for your accounts
Adding to the groups is the key to this. Because my idea is to manage access via Entitlement Management’s Access Packages, I will not add the user to any Teams.
In the above tasks, I noticed an issue with the Send Welcome Email task. Task 2 will add a user to the group which is also the step to assign a license. The mailbox will take time to provision. Because of this, the email sending step can be failed.
Now that the onboarding has been done, we can look at the next steps of the employee journey.
Entitlement Management
The goal is not to explain what Entitlement Management is, however, I want to use the Access Packages in it to make sure users would get the right access to resources.
There are a few things you can do here. Either set a base package for the users that you have added to the groups in the LCW. So when the user is added to the group, in this step, they will get the assigned package access by default. If you don’t want to provide auto access, you can setup to ask for approval when the user needs access. In this case, they have to know the URL to go to and ask for the Access Package access.
The example below is for a new user who came to the IT team. Because he was added to a group in the LCW depending on the department, he will get this specific Access package.
Additionally, if you need more access you can do the same by creating more Access Packages. Time them or set them to never expire.
🔗Check here to understand more about Access Packages and Entitlement Management Capabilities
Tip: If you are creating more Access Packages later, you can assign them to Dynamic Groups and make sure you have added the additional membership rule with an AND operator (user.accountEnabled -eq true)
What this means is, when the user account is disabled, they will lose access to this Access Package automatically. Pretty neat ha?
I hope you now have an idea of how to plug Entitlement Management into the mix.
Privileged Identity Management Based Groups
The next thing I want to look at is Privileged Identity Management (PIM). PIM plays (Must play, if it hasn’t yet) a major role in the Identity Governance landscape and is a must-have as Just In Time Access and Just Enough Access is the recommended method to proved access to resources. Again, I’m not going to deep dive into how to set up access, but you can use Azure AD Dynamic groups to provide necessary access. Also, use (user.accountEnabled -eq true) in your rule so when the user account is disabled, the user will be removed from the Dynamic Group.
Initially, I wanted to add the PIM-enabled groups in the LCWs, but in the real world, that access will come later. As well as other access-related requests. You can deliver the base access package by adding groups to the LCW tasks, but if you need to provide more access to Teams and other resources, it is best to go with more access packages.
This article below is something I wrote a while ago regarding Group Based Admin roles, but the same can be used to create a Dynamic Group, rule and the required RBAC
🔗How to Assign Admin Roles to Azure AD Groups with Access Reviews and Just in Time Access?
Dynamic Groups
As I mentioned earlier, I want to chat about the Dynamic Groups. Even though it’s not a part of the Identity Governance bucket, it can be very helpful in building your solution. At the time of writing you, Dynamic Groups are not allowed in LCWs. And I think that’s for a reason. Simply LCWs dynamically add the user to groups already.
Especially when the user resigned and if you create your LCW to run a Leaver schedule, you have the option to disable the user account. That will make the user.accountEnabled -eq false and remove the users from the group.
At the time of the writing, the LCW Mover (changing departments) templates are not available, but you can use Dynamic Groups with the attribute department to provide access to resources and licensing.
Azure Resource Access
Also – to provide access to Azure resources, for example, you can set it according to the Job Title. Again this goes hand in hand with Access Packages as it can be set to groups and the same group can be a member of an access group for an Azure resource.
Licensing
Use Dynamic Groups to provide licenses OR you can add a static group and add that static group to the LCW. I have illustrated that in figure 2 above.
Access Reviews
It’s a no-brainer to have Access Reviews set up in your groups which has access to resources in this day and age. If you haven’t, you are not too late 🙂 This is another main feature and it is vital to set this automation for your groups. As I mentioned earlier the chances of you or the group owner reviewing access periodically is an additional task and it is hard to keep a track of all the groups and what access the users got and go through each and every member.
You can set Access Reviews when you are creating your Access Packages or manually set it for your Groups. Once you set it, it will run periodically for you. However, this should be a part of your Identity Governance practices so you or the group owners are aware of the members in them.
🔗Check here for more about Access Reviews
Coming Back to LCW – Leaver Template
I want to quickly touch base on this template as well. Same to the joiner template, there are some tasks that will be running to make sure the employee’s access has been revoked.
Which in result the access will be blocked as below.
Further to this, they will be removed from the group.
And now because the account is disabled, they will be removed from the Dynamic Groups automatically.
Example: Account disable Syntax (user.accountEnabled -eq False) and (user.jobTitle -eq "SysEng_L3")
This will remove from the RBAC groups
Audit Logs
Audit logs can be useful when it comes to understanding the activities that took place in this landscape. This will record all activities and furthermore if you have the ability to connect the Azure AD to an Azure Log Analytics workspace. You can query the AuditLogs table using KQL.
And for all the Identity Governance features, there is a separate Audit Logs section where you can explore the activities and have the ability to download the CSV as well.
Licensing Requirements
To use Identity Governance you need to have an Azure AD Premium P2 license. The tricky part is how to have the license for the different parts not the same. I will be discussing the requirements below.
🖱️Click to enlarge the image
Example Licensing Scenarios
Privileged Identity Management: 🔗 Also check this for example licensing scenarios
Entitlement Management (Access Packages): 🔗Also check this for example licensing scenarios
Access Reviews: 🔗Also check this for example licensing scenarios
Wrapping Up
Identity Governance is a vital part of your security posture and if you are doing manual tasks or do not have a process now is the best time to think of one. I hope this post helped you to do a deep dive into the features and to understand how everything connects. Onboarding a user is no more an ad-hoc task. It’s a journey and Azure AD got the tools to support that journey if you are ready to unlock the full potential of its capabilities.
Discover more from EMS Route
Subscribe to get the latest posts to your email.
EMS Route 
One thought on “Microsoft Entra Identity Governance – Connecting the Dots”