Raising the Curtain
There are some things that regularly bother me – for example, I often wonder how all the Entra ID API rights demanded by applications are justified.
I have spent quite some time with the Privileged Access Management piece – but let’s not get ahead of ourselves, first let’s get to know our actors for today’s play about excessive rights.
The Monster – Overprivilege
You may know it as the buzzword counterpart to Least Privilege. Or it thrown in your face by the security officer / department as an argument for an Identity Governance solution.
In more technical IT teams, however, it is more likely known as the first request made by a co-administrator or developer – of course, everyone needs root, dbowner, and local administrator. Because the primary focus is usually on getting something up and running, not making sure we don’t overshoot the goal.
This is how more and more unused rights creep in, that often merely invite misuse.
The Fortress – Entra ID
Entra ID is not only the wall around our Office 365 data but also around an increasing number of connected applications – at this point often more powerful than Active Directory used to be. Accordingly, we want to ensure that those who are behind the walls to really only have access where we expect and want them to.
The Gatekeepers – (PAM) Developers
So, we depend on the software that is built to be very precise in its needs. Developers (and admins too) often don’t consider whether there might be solutions with fewer permissions, or whether the requested permissions could be misused. In the worst case, Microsoft themselves offers only suboptimal options, so there’s not even a better alternative.
Thus, it is almost a miracle when there’s nothing to complain about 😉
Point of Entry – Password rotation
Reminder: we are currently focusing on Overprivilege, PAM solutions are usually a very good gateway
I will not try to sell a PAM system here, as there are plenty of manufacturers who promote their solutions
Imagine a Privileged Access Management solution is in use. This makes life harder for malicious actors, but often for regular admins as well. So, there are always two motivated groups that would prefer to work without PAM. Part of closing bypasses is rotating the passwords of accounts, ideally after each login.
There are also plenty of other situations where one might just want to reset a password, but here we can look at specific examples.
So, we continue with the desired result that our system can rotate passwords – nothing else – and review the documentation of the three best-known manufacturers (to me). We will quickly realize that we often bring more into the fortress than we want…
The Assault
I assume that the PAM solution is not also in charge of account lifecycle management – meaning it doesn’t create user accounts or assign rights.
Otherwise, the consideration becomes more complex than I dare to unravel in a blog post.
If your PAM solution is also an Identity Governance system, please enjoy this chapter with a grain of salt.
If anyone finds good articles by consultants or admins on how to do it in practice, feel free to pass them on to me – I am well aware that manufacturers are often not best at handling their product
| ____ | CyberArk | BeyondTrust |
|---|---|---|
| Demanded Permissions | Service Account User Admin Password Admin Global Admin |
Application Permissions UserAuthenticationMethod.ReadWrite.All Domain.Read.All Group.Read.All User.Read.All Entra ID: Helpdesk administrator "For Service Account Management" Entra ID: Privileged Authentication Administrator Directory.AccessAsUser.All |
| Overpermission | Changing one’s own password (not just restoring it) requires admin rights in the system | UserAuthenticationMethod.ReadWrite.All cannot be used for password change – it’s not entirely clear to me what the scope is supposed to be used for |
| Misc | Allegedly, a system-internal Global Admin account is only necessary to manage Global Admins, but in reality, even for members of a Role Assignable Group a Privileged Authentication Administrator is needed | Changes on users in Role Assignable Groups or with admin rights will fail unless, by chance, service account management is in use |
The Result: We now have new service accounts in our environment with Global Admin rights (Privileged Authentication Admin can also grant Global Admin), just to manage passwords. These applications can now exercise full access to our M365 environment – endpoints, data, authentication to Entra ID Enterprise applications, etc.
Ouch!
In defense of the PAM manufacturers, Entra ID is only one authentication provider among others like SSH, AD, Okta, etc., which can be integrated – so there are more than enough areas being worked on. Nonetheless, I find the implementation quite uncumfortable for large, security-focused companies. And Microsoft doesn’t really make it easy for them either.
The Lord’s Share of Blame
We don’t get tools to manage only specific authentication methods from Microsoft. If, for example, we have an application that should only be able to generate Temporary Access passes for user onboarding, it can also manage MFA methods at the same time…
As of January 2024
If we search in the API rights for AuthenticationMethod, we only find the following:
A UserAuthenticationMethod.ReadWrite.Passwords Scope would be really helpful…
The Resistance
I quickly discarded the idea of using Administrative Units as a restriction – the necessary roles are not available. It would also generally make no sense to limit a Global Admin to certain users if they could simply override the tenant settings anyway.
Those who have been reading closely will remember that I wanted to examine three major PAM solutions.
With Delinea, I didn’t find a dedicated Entra ID password manager. Based on the results with the other providers, I considered counting this as a plus, but I think a "Did not Qualify" is more fitting. Why didn’t I just remove them from the topic, then?
For Delinea, one would need to build a custom password connector for Entra ID – which I would also suggest for the other two providers if the option exists. So the question arises – what would I do to avoid having this Global Admin Monster in my castle?
Well, as already mentioned in my password-centric blog post – a user can always change their own password if they can authenticate and know the old one – If we have a user’s password in the vault, then the changePassword endpoint is available to us. Theoretically, we don’t need to grant any admin rights at all!
Now we just need to find a solution so the PAM system knows the password of it’s managed users from the start.
The downside would be that unfortunately no automatic correction would be possible if a password deviates from the one stored in the PAM solution (reconciliation) – in such a case we would need admin intervention. For me, this would be an acceptable tradeoff, because it shouldn’t happen often.
If automatic reconciliation is mandatory, an Azure Function that does nothing but rotate passwords could be an alternative.
With Entra ID authentication, of course, so that only authorized identities can retrieve a new password. Then, although the Azure Function would be overprivileged, it could be bound to a Managed Identity, creating a much stricter separation between the application and its rights – additionally, the identity would ideally be managed by someone who already has the same high-privileged rights, rather than being made available to someone new.
Review
For those expecting a proof of concept in the second act, I must disappoint you – the practical part is a separate post.
However, we have already established that even security-focused Applications like PAM solutions do not perfectly adhere to concepts like Least Privilege, but there are still options that we could explore. Hopefully, I have inspired you to pay closer attention to the rights you grant in the future, and I look forward to feedback on solutions or ideas!
I will not moderate comments and I do not want your email address; please participate in the discussion through my associated LinkedIn Post.
If you are interested in the things I do follow me on LinkedIn.
Translation Assisted by ChatGPT