Principle of least access. It’s a fundamental concept in both cloud and on-premises security architectures, but one that can be difficult to achieve and maintain, especially with multiple mechanisms for both implementation and enforcement.
In an Active Directory environment, privileges are almost entirely managed through group memberships. Everybody with the slightest hint of administrative burden asks for Domain Admin group membership, and nobody ever wants to give it up once they have it. This is an obvious security nightmare, but it’s also a compliance hassle for the beleaguered admin who has to report to the auditors every 6 months on why there are 27 Domain Admins for a 1100-seat organization. But it’s even worse than most realize, because there’s a tiny little attribute hiding in your AD Schema called ‘isadmin’, and it’s value can only be changed once per account. That value starts its life as 0, but the moment the user gains access to any built-in administrative group, it flips to 1. It cannot be reverted, and bad guys with LDAP access to your Active Directory can shortcut lateral movements by simply querying for all accounts where isadmin=1. Game over. Worse still, because the only method for assignment was group membership, we often group nesting resulting in massive over-assignment. I once worked for an organization that had, through nesting, given every single user in the multi-domain AD Forest effective membership in Enterprise Admins.
In Azure Active Directory, roles are aggregated sets of permissions that were traditionally assigned as a single unit to a user. We call them things like User Administrators, Global Admins, etc. Global Admins, just like Domain Admins, are massively over-assigned, and extend to both human and non-human entities. Every app in the world insists it needs Global Admin, as does every vendor. We can also query Azure AD for standing access to these roles, and in fact the Microsoft 365 default dashboard includes a built-in query for Global Admins. A bad guy with console access has the same visibility they had in AD. Game over, again.
Privileged Identity Management in Azure AD P2 can reduce this risk by up to 95%. Roles can still be assigned directly to a user, but time-bound. A user then would be eligible for access to their Global Admin role, but it would not be permanently active. To activate that role, the user would have to navigate to the Privileged Identity Management dashboard and request an elevation, which can kick off a workflow requiring approval, step-up authentication, and even service ticket information. When that account is not active in the admin role, things get even more interesting, because that ‘isadmin’ attribute from AD DS doesn’t exist, and a user eligible for a role is not reported in the default Microsoft 365 dashboard.
The whole concept is a huge win for least-access, but the requirement to do it all by direct assignment was difficult. If a user needed multiple roles, that meant multiple activations, which could mean multiple approvals, and exceedingly long lead-times to deliver the right permissions to do the job.
Microsoft has worked to bridge this gap with what was originally called Privileged Access Groups. These groups themselves were assignable to roles, both with permanent standing access and eligibility. This feature recently got a rename to the completely unexciting “PIM for Groups”:
But the announcement teased some interesting new roles that previously weren't available to PIM, namely those workload-specific roles buried in the Purview, Exchange Online, and Intune portals. I asked some of my Microsoft contacts to confirm if they meant all of the roles, and they suggested yes, but in fact the answer is no, at least not directly, and certainly not in the way detailed by the article.
If you've ever tried to enable PIM for Purview roles, you may have discovered that Purview has 2 different role sources: Azure AD and Purview itself:
While the Azure AD roles are powerful, they are by no means exhaustive, and any Purview veteran will tell you you HAVE TO use the Purview solution roles to get visibility into case management, eDiscovery, or just about anything else. And they're all super granular and there's no "Global Admin" equivalent in that space. In short, it's not fun. And to make it super duper not fun, you used to not be able to assign Azure AD groups to roles, so without a heap of careful documentation it was easy to put users into roles and then never find those permissions again. But if you can assign an Azure AD group to a role, you should be able to manage just-in-time access to the role through Azure AD P2's entitlement management.
By placing an Azure AD group into the relevant Purview roles, and then managing membership in that group with an Identity Governance Access Package, Azure AD will provision access on-demand with up to 3 levels of approvals. And if that access is time-bound (and it should be), Azure AD will programmatically remove that membership at expiry.
Logging is more robust, too, because not only can you can track access package activations and configure access reviews, but you also can directly monitor group membership changes thru the Azure AD Audit Log (and SIEM that may be consuming that data). Also, by doing it through Access Packages, you can consume secondary benefits of the compliance space like enforceable separation of duties, such that if your Compliance Officer access package is incompatible with your Help Desk Tech or CIO access package, users cannot leverage both at the same time, even if the user is accidentally added to groups that enable both:
To start managing workload-specific roles through Entitlement Management Access Packages, you must first build some empty groups in Azure AD. If these roles were visible to Azure AD, we would tick YES in the box for “Azure AD roles can be assigned to the group”, but they’re not, so that setting won’t do any good for us, and we should leave it set to “no”. Changing it to “yes” has implications on group nesting and other settings that we likely don’t want to impact right now.
It’s also important to keep these groups empty because we're going to manage and monitor their membership entirely through Entitlement Management, so no members at creation time, and ideally we should only create the groups we need to achieve principle of least-access.
Once you have the groups you want to map to roles, cruise over to the Purview portal and add them to their corresponding roles:
Now head over to Azure AD Identity Governance, create a catalog for Compliance, and add your newly-created groups:
Now add the role group to your access package and define the level of access to the group (member should suffice unless you're doing some real next-level stuff).
Then add assignment policies, separation of duties, access reviews, etc:
And now, in public preview, you can also require a Verified ID in the activation policy!
But wait--where's the MFA step-up that PIM is so famous for? Well, it's not there, but you can enforce a step-up authentication on members of that group with a Conditional Access policy. Remember that the group is currently empty, so the only way we’ll see any impact is if someone activates the access package.
When the access package expires, so too will all the restrictions that are imposed on their membership in that group. And it's not a dynamic group--the user is literally instantaneously added to the group by Azure AD Identity Governance itself--so there's no waiting for "cloud replication".
And if we add periodic access reviews to the provisioning policies, we can ensure there will be no lingering access:
So what does it look like for the user and the security-conscious admin? Let’s walk through an activation!
In this side-by-side, Annamiek is on the left, and the admin is on the right. Annamiek wants to activate the Insider Risk Mgmt role. She opens her browser and goes to https://myaccess.microsoft.com, where she sees the list of Access Packages that are available to her:
She clicks “request” and is prompted for a justification.
This Access Package requires a single level of approval, and we chose Manager by default, so nothing will happen until her manager, Marianne Vos, logs in and approves the request.
Marianne can then check her email for an “action required” message providing her a link to directly approve or reject the request in the MyAccess portal:
Once Marianne hits Submit on the approval popup, Azure AD takes over and processes access to the package resources.
On the left, above, as Annamiek, you can see that the package is now active, with an expiry date of March 1. On the right, the admin can see that the package is in “delivered” state, and clicking on “Request history” shows the entire chain of events:
But it gets better, because Azure AD group membership will now reflect a single user in the Insider Risk Management Admins group, and the Audit Log will show exactly what actions were taken, when, and by whom:
The user now has access to the Insider Risk Management section of the Purview portal, and the admin can see that step-up authentication was enforced by group assignment.
And just like with Privileged Identity Management for Azure AD roles, when the time comes to end access, the user can let it expire naturally or click “Remove access” from the MyAccess portal:
This will cause Azure AD Identity Governance to remove the user from relevant groups, applications, sites, and teams, and place the access activation into the “Expired” tab of the MyAccess portal:
After access is removed, Annamiek sees the following when trying to access Insider Risk Management, and the admin can see all of the processed removals in the user’s Audit Log:
And that's how you manage PIM for workload-specific roles that don't surface to Azure AD.
Notes:
- Some roles do not calculate effective permissions as quickly as others. Azure AD roles tend to check access continuously, but Purview roles may continue to believe the user has access for up to an hour after revocation. This may be outside the limits of some organizations’ accepted risk, however it’s worth noting this behavior can also be observed with direct assignment to the role.
- The shortest lifespan possible for assignment via Access Package is 1 hour, compared to 0.5 hours for traditional PIM assignment.
- For the best experience, users should already be enrolled in the step-up authentication mechanism you choose.
- Microsoft is continually adding new roles to Azure AD, and some roles that would currently need this solution may fall under direct control of PIM in the future. Windows 365, for instance, has 2 roles in Intune, and one of those roles has recently been ported to Azure AD. As more roles surface into Azure AD, it may be worth revisiting whether to convert management to PIM or PIM for Groups.
Would you like to find out more about Azure Active Directory? Learn how you can deploy Azure Active Directory today.
Comments