The time has come to write a blog about Entra ID Governance. There are a lot of cool functionality that can help managing Users and their permissions during their lifetime. This blog can to be used as a guide on how to get started but Microsoft just released a really nifty “how-to” guide on implementing ID Governance, link here: Entra ID Governance deployment guide.
Identity is the most important thing to protect in a modern cloud environment. Most of the cyberattacks that we witness nowadays almost explicitly begins with a users identity that has been compromised through phishing or other means. It’s not that cool and sexy as it is in movies where a person with a black hoodie chops away at the keyboard, disables three firewalls and says “I´m in”. Sure black hoodies are the fashion choice to many, but all of the other stuff doesn’t happen.
It is therefore important to have a consistent process on managing identities, their access and lifecycle. This is mostly done via traditional IT-department processes and with close cooperation with HR. Manual processes that rely on humans to know how to do something and their memory to actually do it is flimsy at best. We also want to cut corners and minimize the workload that is increasing all of the time. This leads to mistakes very easily and mistakes cost cybersecurity posture and in time will lead to compromise of company systems.
Entra ID Governance brings IT teams the tools to automate, govern and delegate these processes in a way that is easily managed and auditable.
Prerequisites
The main prerequisite is (as always) to have the proper licenses. Entra ID Governance is not included to any major licenses like Microsoft 365 E5 but it can be purchased as an add-on for a relatively low cost per user. These functionality will free up the time of your IT staff to do things that provide value above the cost of these licenses. They are that cheap.
If this is the first time using these tools, you also have the option to use the 90-day trial licenses in order to try it out and see if the benefits are there for you.
Entra Suite vs. Entra ID Governance
At minimum you need a base license of Entra ID Plan 1 which comes included in Microsoft 365 E3 and Microsoft 365 Business Premium licenses. On top of that you need to purchase Entra ID Governance add-on license. There is also an option to upgrade to Entra Suite license which includes ID Governance, it does not cost that much more and gives access to Entra Private Access and Entra Internet Access. I’ll write a separate blog post about Global Secure Access in which I’ll go deeper in to them.
Quick note about Entra ID Plan 1 and 2. You really should consider upgrading to Plan 2 if you are currently using Plan 1. The cost is not that high as a standalone license (although it’s beneficial to upgrade the whole license if it comes from Business Standard for example) and you get powerful functionality. Two functionalities worth mentioning are Privileged Identity Management and Risk-Based Conditional Access. These two alone makes it worth the price in my opinion.
Enough of prerequisites, time to dive into the reason why you are reading this blog.
Entra ID Governance
The base idea in ID Governance is that you are able to shift from manual processes to automated ones as I explained at the beginning. Managing identities is an important process and a one that a lot of organizations find painful. It takes a lot of time and effort to manage then efficiently.
Entra ID Governance consists of three main functionalities or concepts. Entitlement management, Access reviews & Lifecycle workflows. These three work in unison to protect the lifecycle of an identity and its governance. I also like to think that the Entitlement management and Access reviews are within Lifecycle workflows even though each one of them can technically exist without the others. However, in order to make any of these “usable” or efficient, you should have basic information of user properties in order. Fields like Department, Company, Title are important in automating things later.
I tried and tried to draw some form of picture that can visually show how these tie together. I did not manage so I asked ChatGPT to make me one and here it is.
Entitlement Management
As the name suggests, the main function of Entitlement Management is to, well, manage entitlements. Entitlements is a fancy word for access but it describes nicely the side that users are entitled to access some information or apps.
Catalogs
Managing access is traditionally an IT process and it is something that is quite hard to do great. IT teams do not know what type of access a person needs or which apps they use. The access packages are more often than not modeled after old employees and this can lead to oversharing and privilege creeps. I once worked in a place where one user had access to every folder in the fileshare, this was the result of years of adding access but never removing the old access.
Catalogs help to create logical containers of apps, SharePoint sites, M365 groups and Entra ID roles. These containers can then be assigned as “scopes” to access packages from which the access package can be built. So instead of giving the ability to provide access to everything through an access package, you can limit it with catalogs.
The idea behind this is to outsource the creation and assignment of access packages to stakeholders instead of IT. There is a full mindset shift ahead if you want to utilize the ID Governance in its full potential. For example: IT admins have the ability to create whatever access packages, but the manager of Marketing can only create access packages that contain resources that the marketing team need to use.
Catalogs are also something that you do not necessarily need. They help if the environment is really large and you need to offload operational work outside of IT. It is quite easy to implement ID Governance without catalogs and maybe take them into use later.
Access Packages
Access packages is where the bread and butter of ID Governance lies. You can create a collection of resources to be assigned based on different rules. You may for example have an access package for Marketing users that is auto-assigned to every user that has the Department properties value of Marketing. You just need to make sure that the data is correct when creating a new user. I will use my test user Luke as an example for the rest of this blog. Picture below shows his info.
Now because Luke is a part of the marketing team. He gets access to some basic stuff like applications that Marketing uses as well as SharePoint sites. The way he gets the access is that we have an access package “Marketing basic” that has all of the resources that are needed and then we have an policy where we can define who gets the access. In this case we have a policy (picture below) which automatically assigns and removes itself to and from users if users department is Marketing. This is a simple but powerful way to create ways to distribute access because you can create general access policies which you can auto assign as well as give users the possibility to “elevate” their access by request.
Let’s say that you have users in sales that want to sometimes access the marketing materials. That’s ok but you dont want them to have standing access to said resources. You can just use the same “Marketing basic” and create another policy that enables users to request access.
Here I made a policy that does that. The policy states that one user needs to approve the requests, the requester needs to provide an justification and after approval, the access expires in 14 days.
Now we have some basic functionality for Marketing but as Luke is a Jedi after all, he needs to be able to elevate himself to a SharePoint Administrator. We will create another access package just for that and via it, Luke can gain the eligibility to activate SharePoint Administrator from Privileged Identity Management. We also could define the Entra ID role to be Active within the access package, but that would be an assignment outside of PIM and that’s not good. In fact, you can only give eligible assignments though access packages if the role is privileged, SharePoint Administrator is not.
Luke can now activate the package for himself without approval, but this time we configured access reviews monthly. Lukes manager will have to check monthly if Luke still needs the access or not.
We could take this even further by requiring Verified ID and Face Check on activation. This is something that I have tested briefly and deserves a whole another post. Imagine having this on top of PIM for let’s say, Global Administrators. In order to even get eligibility to activate your Global Admin role, you would need to have Verified ID on your device and you would have to perform a Face Check. 🤯
My Access
Users with the possibility to activate access packages have their available and active packages visible to them on their My Access portal.
Lifecycle workflows
Do you have the problem of having a new employee start and people are scrambling around for his/hers password and then you find it from a random mailbox created two weeks ago? Many organizations have. This is something that’s on the grey area when looking at it from the security perspective. It might be convenient to send the password to manager or service desk who then can share it to the employee once they start but there is a possibility to do something malicious with the users account before that.
Next problem would be the case when user leaves the organization. Are you sure to which apps the user has access to? Is there some exit actions that could be automated like booking an exit review or adding the user to a watchlist in Sentinel to increase monitoring for data exfiltration actions?
Think of Lifecycle Workflows as automation rulesets for different parts of employee lifecycle. You start with a template and create your custom rules to fulfill the need in your org for that process. Here are the templates available right now:
Let´s take Onboard pre-hire employee as an example. You might want to enable the new users account before they actually start in order to activate their calendar for some onboarding meetings and welcome emails and such. Normally Service Desk creates the account in advance and that might be quite a long time that the account just floats there with the manager and service desk having access to it because the initial password is known to them.
With joiner workflow you can automatically create the account based on the hire date attribute and do some other magic as well! Here is an example workflow task that you could do 2 days prior of the user starting (prerequisites would be that the user has been created automatically via HR system integration as a disabled user):
- Enable account
- Assign licenses
- Generate Temporary Access Pass and send it to the manager via Email
- Send Welcome email to user
- Add user to groups
Options are limitless as there is an option for Custom Task Extension which means that you can run a Logic App triggered by the workflow. Below is all of the tasks that can be done:
Whoa. This was a wall of text and took a while to create as pre summer is quite busy as a consultant. I hope that you got some ideas from this! Please don´t hesitate to contact me if you need help with Entra ID Governance.
Remember to check my other posts as well: Blogs
Leave a Reply