Easily Manage Privileged Role Assignments in Microsoft Entra ID Using Audit Logs

One of the best practices for securing your organization's data is to follow the principle of least privilege, which means granting users the minimum level of permissions they need to perform their tasks. Microsoft Entra ID helps you apply this principle by offering a wide range of built-in roles as well as allowing you to create custom roles and assign them to users or groups based on their responsibilities and access needs. You can also use Entra ID to review and revoke any role assignments that are no longer needed or appropriate.

 

It can be easy to lose track of role assignments if admin activities are not carefully audited and monitored. Routine checks of role assignments and generating alerts on new role assignments are one way to track and manage privileged role assignment.

 

Chances are that when a user with privileged roles is approached, they’ll say they need the role. This may be true; however, many times users will unknowingly say they need those permissions to carry out certain tasks when they could be assigned a role with lower permissions. For example, a user will be able to reset user passwords as a Global Administrator, but that does not mean they can’t do that with another role with far less permissions.

 

Defining privileged permissions

 

Privileged permissions in Entra ID can be defined as “permissions that can be used to delegate management of directory resources to other users, modify credentials, authentication or authorization policies, or access restricted data.” Entra ID roles each have a list of permissions defined to them. When an identity is granted the role, the identity also inherits the permissions defined in the role.

 

It’s important to check the permissions of these roles. The permissions defined in all built-in roles can be found here. For example, there are a few permissions that are different for the Privileged Authentication Administrator role than the Authentication Administrator role, giving the former more permissions in Entra ID. The differences between the authentication roles can be viewed here.

 

Another example of having differences between similar roles is for the end user administration roles. The differences and nuances between these roles are outlined in detail here.

 

Auditing activity

 

To decide if a user really needs a role, it’s crucial to monitor their activities and find the role with the least privilege that allows them to carry out their work. You’ll need Entra ID audit logs for this. Entra ID audit logs can either be sent to a Log Analytics Workspace or connected to a Sentinel instance.

 

There are two methods that can be used to get the events of carried out by admin accounts. The first will make use of the IdentityInfo table, which is only available in Sentinel after enabling User and Entity Behavior Analytics (UEBA). If you aren’t using UEBA in Sentinel or if you’re querying a Log Analytics Workspace, then you'll need to use the second method in the next heading. 

 

Using Microsoft Sentinel

 

To ingest Entra ID audit logs into Microsoft Sentinel, the Microsoft Entra ID data connector must be enabled, and the Audit Logs must be ticked as seen below. 

 

Figure 1 Entra ID data connector in Sentinel with Audit logs enabled 

 

The IdentityInfo table stores user information gathered by UEBA. Therefore, it also includes the Entra ID roles a user has been assigned. This makes it very simple to get a list of accounts that have been assigned privileged roles. 

 

The query below will give a unique list of activities an account has taken, as well as which roles the account has been assigned: 

 

AuditLogs | where TimeGenerated > ago(90d) | extend ActorName = iif( isnotempty(tostring(InitiatedBy["user"])), tostring(InitiatedBy["user"]["userPrincipalName"]), tostring(InitiatedBy["app"]["displayName"]) ) | extend ActorID = iif( isnotempty(tostring(InitiatedBy["user"])), tostring(InitiatedBy["user"]["id"]), tostring(InitiatedBy["app"]["id"]) ) | where isnotempty(ActorName) | join (IdentityInfo | where TimeGenerated > ago(7d) | where strlen(tostring(AssignedRoles)) > 2 | summarize arg_max(TimeGenerated, *) by AccountUPN | project AccountObjectId, AssignedRoles) on $left.ActorID == $right.AccountObjectId | summarize Operations = make_set(OperationName) by ActorName, ActorID, Identity, tostring(AssignedRoles) | extend OperationsCount = array_length(Operations) | project ActorName, AssignedRoles, Operations, OperationsCount, ActorID, Identity | sort by OperationsCount desc

 

This will give results for all accounts that carried out tasks in Entra ID and may generate too many operations that were not privileged. To filter for specific Entra ID roles, the following query can be run where the roles are defined in a list. Three roles have been added as examples, but this list can and should be expanded to include more roles: 

 

let PrivilegedRoles = dynamic(["Global Administrator", "Security Administrator", "Compliance Administrator" ]); AuditLogs | where TimeGenerated > ago(90d) | extend ActorName = iif( isnotempty(tostring(InitiatedBy["user"])), tostring(InitiatedBy["user"]["userPrincipalName"]), tostring(InitiatedBy["app"]["displayName"]) ) | extend ActorID = iif( isnotempty(tostring(InitiatedBy["user"])), tostring(InitiatedBy["user"]["id"]), tostring(InitiatedBy["app"]["id"]) ) | where isnotempty(ActorName) | join (IdentityInfo | where TimeGenerated > ago(7d) | where strlen(tostring(AssignedRoles)) > 2 | summarize arg_max(TimeGenerated, *) by AccountUPN | project AccountObjectId, AssignedRoles) on $left.ActorID == $right.AccountObjectId | where AssignedRoles has_any (PrivilegedRoles) | summarize Operations = make_set(OperationName) by ActorName, ActorID, Identity, tostring(AssignedRoles) | extend OperationsCount = array_length(Operations) | project ActorName, AssignedRoles, Operations, OperationsCount, ActorID, Identity | sort by OperationsCount desc

 

Once the query is run, the results will give insights into the activities performed in your Entra ID tenant and what roles those accounts have. In the example below, the top two results don’t pose any problems. However, the third row contains a user that has the Global Administrator role and has created a service principal. The permissions needed to create a service principal can be found in roles less privileged than the Global Administrator role. Therefore, this user can be given a less privileged role. To find out which role can be granted, check this list, which contains the least privileged role required to carry out specific tasks in Entra ID. 

 

Figure 2 Actions taken by users in Entra ID

 

Using Log Analytics Workspace

 

Figure 3 Configuring the forwarding of Entra ID Audit logs to a Log Analytics Workspace

 

To ingest Entra ID audit logs into a Log Analytics Workspace follow these steps. 

 

Because there is no table that contains the roles an identity has been granted, you’ll need to add the list of users to the query and filter them. There are multiple ways to get a list of users who have been assigned a specific Entra ID role. A quick way to do this is to go to Entra ID and then select Roles and administrators. From there, select the role and export the identities that have been assigned to it. It’s important to have the User Principal Names (UPNs) of the privileged users. You’ll need to add these UPNs, along with the roles the user has, to the query. Some examples have been given in the query itself. If the user has more than one role, then all roles must be added to the query.

 

datatable(UserPrincipalName:string, Roles:dynamic) [ "[email protected]", dynamic(["Global Administrator"]), "[email protected]", dynamic(["Global Administrator", "Security Administrator"]), "[email protected]", dynamic(["Compliance Administrator"]) ] | join (AuditLogs | where TimeGenerated > ago(90d) | extend ActorName = iif( isnotempty(tostring(InitiatedBy["user"])), tostring(InitiatedBy["user"]["userPrincipalName"]), tostring(InitiatedBy["app"]["displayName"]) ) | extend ActorID = iif( isnotempty(tostring(InitiatedBy["user"])), tostring(InitiatedBy["user"]["id"]), tostring(InitiatedBy["app"]["id"]) ) | where isnotempty(ActorName) ) on $left.UserPrincipalName == $right.ActorName | summarize Operations = make_set(OperationName) by ActorName, ActorID, tostring(Roles) | extend OperationsCount = array_length(Operations) | project ActorName, Operations, OperationsCount, Roles, ActorID | sort by OperationsCount desc

 

Once you run the query, the results will give insights into the activities performed in your Entra ID tenant by the users you have filtered for. In the example below, the top two results can cause problems. Both have the Global Administrator role, but their operations don’t necessitate to have that role. The permissions needed for these operations can be found in roles less privileged than the Global Administrator role. Therefore, these users can be given a less privileged role. To find out which role can be granted, check this list, which contains the least privileged role required to carry out specific tasks in Entra ID.

 

Figure 4 Actions taken by users in Entra ID

 

If this user still requires the Global Administrator role then the Security Administrator role will become redundant as the Global Administrator contains more permissions than the Security Administrator role.

 

Conclusion

 

Keeping accounts with privileges that are not required is keeping your attack surface greater than it needs to be. By ingesting Entra ID Audit logs, you can query and identify users who have unnecessary and over-privileged roles. You can then find a suitable alternative role for them. 

 

Timur Engin

LinkedIn  Twitter  

   

 

Learn more about Microsoft Entra:   

• See recent Microsoft Entra blogs  
• Dive into Microsoft Entra technical documentation  
• Learn more at Azure Active Directory (Azure AD) rename to Microsoft Entra ID  
• Join the conversation on the Microsoft Entra discussion space and Twitter  
• Learn more about Microsoft Security