Look Out for Synchronized On-Premises Accounts Holding Administrative Role Assignments

An August 2 post by SpecterOps highlights the dangers for hybrid Microsoft 365 organizations of synchronizing on-premises accounts to Entra ID that hold administrative roles. This is a long-running story. Following the SolarWinds debacle, Microsoft explicitly recommended in December 2020 that “synchronized objects hold no privileges beyond a user in Microsoft 365, either directly or via inclusion in trusted roles or groups.”

Even with all the warnings, it seems that some organizations never received the memo or continue to allow synchronized accounts to hold Entra administrative roles. That’s a great pity, just like the failure to enable strong multifactor authentication to protect user accounts.

This brings me to the question of how to scan for accounts synchronized from on-premises that hold Entra ID administrative roles. As always, it’s great to build off community ideas. In this case, Nathan McNulty tweeted some Microsoft Graph PowerShell SDK code to find accounts holding administrative roles. Nathan doesn’t seem to have published anything in his GitHub repository, so my version is available from the Office 365 for IT Pros repository.

Previous Script to Report Administrative Roles

I’ve been down the road of reporting privileged role assignments before when I wrote a script in 2023 to look for assignments for the Global administrator and Exchange administrator roles. The information about role assignments is then used to disable PowerShell for all accounts except the holders of the two roles. The 2023 script used cmdlets from the now-retired AzureADPreview module, so I updated the code to use cmdlets from the Microsoft Graph PowerShell SDK instead.

Processing Steps to Find and Report Administrative Roles

The script to report administrative roles handles both Privileged Identity Management (PIM) and non-PIM assignments and does the following:

• Administrative role assignments can be scoped to the entire directory or specific administrative units. The assignments stores GUIDs for administrative units. To make sure that the report can include the display name for administrative units, the script loads details of administrative units into a hash table. As the script processes each assignment, it looks the administrative unit to find its display name.
• Runs the Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule cmdlet to retrieve the set of PIM active assignments. These are role assignments that are currently in use.
• Parses each assignment to find it if is to a user, group, or service principal. If a group, expand the set of group members. Add what’s found to a PowerShell list.
• Runs the Get-MgBetaRoleManagementDirectoryRoleEligibilitySchedule cmdlet to find the set of eligible assignments. Parse what’s found and add to the PowerShell list.
• If the script can’t find any PIM assignments, the likelihood is that the tenant doesn’t use PIM, so the script finds the set of members assigned to each directory role and report that.
• Outputs details of the assignments via the Out-GridView cmdlet plus either a CSV file or Excel worksheet (Figure 1), depending on whether the ImportExcel module is available.
• Finally, the script lists any on-premises users found with administrative roles.

Feel Free to Improve the Code

No doubt some improvements can be made to the code to make administrative role assignments easier to understand. The point is that the script is relatively simple PowerShell that should be easy to work with and update. It is best to make the changes direct in GitHub so that everyone benefits from your inspiration.

Learn more about how Microsoft 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Microsoft 365 ecosystem.

Taking Account of PIM When Blocking User Access to Exchange Online PowerShell

Updated 15 August 2024

In May, I wrote a Practical365.com article about disabling PowerShell access to Exchange Online for all but administrative accounts. Given the happiness of attackers to use PowerShell to attack Exchange (mostly against Exchange Server, but certainly also Exchange Online), it makes sense to remove the ability of “normal” users to run Exchange cmdlets.

In any case, the example script I use in the article demonstrates how to use the Get-MgDirectoryRoleMember cmdlet to find holders of the Exchange administrator and Global administrator roles. These are the people who need to run PowerShell against Exchange Online, so the script leaves their accounts intact. For anyone else, the script calls the Set-User cmdlet to disable PowerShell access. I suggest that the script is a good candidate for Azure Automation to make sure that new accounts can’t use PowerShell.

Privileged Identity Management

Everything works for most tenants. The problem is that some tenants use Azure AD Privileged Identity Management (PIM), an optional service that requires Azure AD Premium P2 licenses. PIM is most commonly used by large enterprises to control access to resources. Unlike normal open-ended permanent assignments to privileged roles like Exchange administrator, PIM allows the assignments to be time-limited on an on-demand basis.

To do this, PIM differentiates between eligible and active role assignments. An eligible role assignment is not currently effective. If needed, an administrator can activate the assignment to allow its holder to use the permissions available to active role holders. Assignments can be time-limited and expire after a certain period. A comment for the original article pointed out that it didn’t handle PIM assignments and the script is therefore unusable in tenants that use PIM.

If you look at role assignments through the Privileged Identity Management section of the Microsoft Entra admin center, you can see those with eligible, active, and expired assignments for the different roles used in the tenant. Figure 1 shows the active assignments for the Exchange administrator and Global administrator roles. You can see that some service principals are in the set of Exchange administrators. Azure Automation uses these service principals to allow managed identities to sign into Exchange Online and run cmdlets as an administrator.

The problem is that the Get-MgDirectoryRoleMember cmdlet only reports active role assignments. The assignments eligible for activation are ignored. For the purposes of this exercise, tenants using PIM must include accounts with eligible assignments when determining what accounts can access PowerShell.

Privileged Identity Management APIs

After some searching, I found a script written by Paul Contreras that explains how to get PIM role assignments for Azure AD. The script uses the Get-AzureADMSPrivilegedRoleAssignment cmdlet from the AzureADPreview module to retrieve assignments.

Given that the AzureADPreview module is due for deprecation in March 2024, I looked for an equivalent Microsoft Graph PowerShell SDK cmdlet. Microsoft’s cmdlet map to help developers move from the Azure AD and MSOL modules to the SDK didn’t help. I had great hope for the Get-MgBetaRoleManagementDirectoryRoleAssignment cmdlet but the cmdlet appears to only return “normal” role assignments.

One complication is that the current (beta) Graph API for governance role assignments is due for deprecation. Its documentation points to “Privileged Identity Management iteration 2 APIs.” Obviously, the underlying APIs are in a state of change, so the lack of SDK support isn’t surprising.

Amending the Role Assignment Script for PIM (Updated)

I amended the original script to use the Get-AzureADMSPrivilegedRoleAssignment cmdlet to fetch the assignments known for the Global administrator and Exchange administrator roles. This was fine until the retirement of the AzureAD module. V2.0 of the script replaces the AzureAD cmdlet with the Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule cmdlet from the Microsoft Graph PowerShell SDK (V2.22).

Write-Output "Retrieving assignment information from Privileged Identity Management..."                    
# Get PIM assignments for accounts holding Exchange administrator or Global administrator roles
[array]$ActiveAssignments = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "(RoleDefinitionId eq '$($ExoAdminRoleId)') or (RoleDefinitionId eq '$($GlobalAdminRoleId)')" -ExpandProperty RoleDefinition, Principal, DirectoryScope -All

# Filter out the Exchange administrators
[array]$ExoRoleMembers = $ActiveAssignments | Where-Object {$_.RoleDefinitionId -eq $ExoAdminRoleId} | Select-Object RoleDefinitionId, Principal, MemberType   
If (!($ExoRoleMembers)) { Write-Output "Can't find any Exchange administrators! Exiting..." ; break }                                                                                                

# Do the same for global administrators
[array]$GARoleMembers = $ActiveAssignments | Where-Object {$_.RoleDefinitionId -eq $GlobalAdminRoleId} | Select-Object RoleDefinitionId, Principal, MemberType
If (!($GARoleMembers)) { Write-Output "Can't find any global administrators! Exiting..." ; break }

The script then loops through the arrays of assignments to fetch details of user account (with Get-MgUser) and members of groups used for PIM (with Get-MgGroupMember). The script stores information about the assignments that we can report (Figure 2).

The next step is to create an array of administrator user principal names to check against Exchange mailboxes. Basically, if a mailbox belongs to an administrator, we allow PowerShell access. If it doesn’t, we block PowerShell access.

[array]$ExoMailboxes = Get-ExoMailbox -Filter {CustomAttribute5 -eq $Null} -ResultSize Unlimited -RecipientTypeDetails UserMailbox -Properties CustomAttribute5
ForEach ($Mbx in $ExoMailboxes) {
   # If not an admin holder, go ahead and block PowerShell
   If ($Mbx.userPrincipalName -notin $AdminAccounts) {
     Write-Output ("Blocking PowerShell access for mailbox {0}..." -f $Mbx.displayName)
     Try {
         Set-User -Identity $Mbx.userPrincipalName -RemotePowerShellEnabled $False -Confirm:$False
         $MessageText = "PowerShell disabled on " + (Get-Date -format s)
         Set-Mailbox -Identity $Mbx.userPrincipalName -CustomAttribute5 $MessageText
     }
     Catch {
         Write-Output ("Error disabling PowerShell for mailbox {0}" -f $Mbx.userPrincipalNane )
     }
   }
} # End ForEach

An improvement to the original script is that the final step is to check that administrator accounts have PowerShell access. This is to pick up new administrators that receive individual PIM assignments or join a group with a PIM assignment.

Write-Output "Checking administrator mailboxes to make sure that they have PowerShell access..."
ForEach ($Mbx in $AdminAccounts) {
   [string]$mbx = $mbx
   $PSEnabled = (Get-User -Identity $Mbx  -ErrorAction SilentlyContinue).RemotePowerShellEnabled
   If (!($PsEnabled)) {
        Write-Output ("Resetting PowerShell access for admin account {0}" -f $Mbx)
        Set-User -Identity $Mbx -RemotePowerShellEnabled $True -Confirm:$False 
   }
}

The full script is available from GitHub.

Always Learning

The nice thing about working with Microsoft 365 is that there’s always something to learn. Authors learn from the comments posted for our articles. The comments force us to research before we can answer questions posed by readers. That’s a good thing.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.