I.D.E.A #002 – Will the real admin please stand up?

It’s finally time for another I.D.E.A. here at agderinthe.cloud, following up on the first I.D.E.A. which hopefully helped you get your break-glass accounts under control.

As you may remember, the I.D.E.A (Identity Engineering Artifacts), is the small scripts or tools to help with a specific challenge or report on a certain issue. Like I wrote in the earlier post: A bridge between “doing it manually” and “building a platform”.

Introducing I.D.E.A. #002

This I.D.E.A. started with a simple question: “Who is, or can activate, any roles in this tenant and are they protected with MFA?”.

I thought this was a simple thing at first, but looking more closely I realized that this was much more complex. Because there are several ways for an account to obtain a role, depending on the configuration:

1. User is assigned a role (active permission)
2. User is eligible to activate a role (eligible permission)
3. User is member of a role-assignable group with active role (active membership, active role)
4. User is member of a role-assignable group with eligible role (active membership, eligible role)
5. User is eligible member of a role-assignable group with active role (eligible membership, active role)
6. User is eligible member of a role-assignable group with eligible role (eligible membership, eligible group)
7. oh…. and a role-assignable group, can be eligible for another role-assignable group…which again can be eligible for another role-assignable group…..
8. Also… a user can be a member of a completely normal security group, which is a member of a role-assignable group, which can be eligible for another role-assignable group…
9. and so on…..
10. 🥵

So with this realization things got out of hand VERY quickly, and the once “simple reporting” tool is currently a script with over 3000 lines of PowerShell code 😱

Looking at I.D.E.A. #002

Link: I.D.E.A. #002

I.D.E.A #002 consists of 2 scripts:

1. Create-PrivilegedAccountReportApp.ps1
2. Get-PrivilegedAccountReport.ps1

The first one, Create-PrivilegedAccountReportApp.ps1, is optional and creates an app-registration in your tenant with the required app permissions. Connecting using app permissions for this tool is strongly recommended, because the main tool checks Restricted AUs, and it will likely fail with a interactive sign-in, unless the user is delegated sufficient permissions inside each relevant RMAU. So this script simply makes sure you can connect with the correct permissions, using a self-signed certificate with 90 days validity.

Alternatively, you create your own app registration with the following app-permissions:

•  User.Read.All
•  Directory.Read.All
•  RoleManagement.Read.Directory
•  RoleEligibilitySchedule.Read.Directory
•  UserAuthenticationMethod.Read.All
•  PrivilegedAccess.Read.AzureADGroup

The second one, Get-PrivilegedAccountReport.ps1, is the reporting tool itself.

The script attempts to discover and analyze users in every path to administrative privileges in your Entra ID tenant. This includes:

• Direct role assignments (active/permanent privileges)
• PIM eligible role assignments (can activate privileges)
• Group-based role assignments (privileges inherited from groups)
• PIM chains (groups eligible to activate membership in other groups that grant roles)
• Complete nested group resolution (tracks privilege paths through multiple group layers)
• Service principals with administrative roles

I want to stress that there are so many potential ways to set up PIM (badly) that I cannot guarantee, in any way, shape or form, that this script will reliably identify all users who have a path to privileged roles. But it is a lot better than the native reporting in Entra.

For each privileged user, the script performs a combined security risk assessment based on two factors: (1) MFA method strength (strong methods like FIDO2/Authenticator vs vulnerable phone/SMS vs none), and (2) RMAU protection status.

• Accounts with NO MFA are always CRITICAL risk.
• Accounts with both phone MFA AND no RMAU protection are HIGH risk (vulnerable to SIM swapping plus lateral movement).
• Accounts with only one weakness (either phone MFA with RMAU protection OR strong MFA without RMAU) are MEDIUM risk.
• Fully secured accounts (strong MFA + RMAU) are LOW risk.

SMS as MFA

Admin accounts protected by SMS-based MFA represent a disproportionate security risk compared to their level of privilege. SMS is vulnerable to SIM‑swapping, number port‑out attacks, social engineering etc etc. These are attack paths that are actively exploited because they bypass even well‑designed identity architectures. When the blast radius of compromise is “full tenant control,” relying on the weakest MFA method becomes indefensible. Flagging these accounts isn’t about shaming users or admins, it’s about surfacing a high‑impact misconfiguration early, before it becomes the root cause of a breach

RMAU, one of my personal favorites

So the question is: Should you always put privileged accounts, or accounts eligible to roles, in a separate RMAU?

Short answer: YES!

Long answer: YYYYYEEEEEEESSSSSSSS!

Longer (and serious) answer: Placing administrative identities in a Restricted Management Administrative Unit (RMAU) creates a hard boundary around who can modify or reset these accounts. Readers of this blog knows that an RMAU effectively removes all privileged access to the accounts within. A common misconfiguration is that accounts who are eligible for a role or a role-enabled group, does not receive the same protection as accounts with active roles assignments.

What do I mean by that? Well, let us use the “User Administrator” role in an example. Let’s say that User A has the “User Administrator” role in Entra. User A can therefore reset passwords and other settings for all non-admin users in the tenant. User B is eligible (not active) for Global Admin. While User B has not activated the role, its account is for all intents and purposes an ordinary user account. So User A can reset the password for User B, hijack it and use it to leverage it to Global Admin. If User B is placed in an RMAU however, then User A has no admin rights over User B, unless it is specifically delegated.

So an RMAU reduces lateral movement, limits insider risk, and prevents well‑meaning (or rogue) helpdesk staff from escalating privileges. An RMAU also enforces a clean separation between operational support and privileged identity lifecycle management. That is why I always recommend to put privileged, or otherwise important, users or groups in RMAUs for additional protection.

The output

The output is displayed in the PowerShell terminal and shows statistics and details for each role/group, each user/SPN and finally a summary at the end. It also provides an optional .csv export of the per-user information and per-role information. Sample pictures below. 👇

⬆️Sample per-role information

⬆️Sample per-user information. Notice the group nesting there! Yes, the groups are named ‘PIM –’ and ‘PIM – PIM –’ just to make the nesting painfully obvious. Creativity has never been my forte. 😂

⬆️Part of the summary

That’s it for this time

If you decide to try this tool, I’d appreciate it if you shared it with others who might benefit from it. It’s built to make privilege reviews faster and more transparent, but like any automated approach, I can’t guarantee full coverage or catch every edge case. That’s why it’s still critical to keep a clear, up‑to‑date overview of who actually has privileged access and why. The moment that visibility slips, risk rises. So use the tool, adapt it to your needs and keep your access governance tight.

I truly hope this is helpful for you.

Thank you all!