Review Entra ID role assignments and create a strategy to offer such roles

Review all privileged accounts and remove any unnecessary permissions

Problem description:

Most organizations assign the built-in Entra ID roles to users, groups and service principals to operate their environment. It is common that highly privileged roles with excessive permission levels are used for performing daily tasks.

Microsoft has made over 30 different built-in roles to give administrators just enough privileges to do their job, but most organizations have adopted just a few of them.

Users or service principals holding these roles are rarely reviewed and from a security perspective this is a huge problem. There are also some decisions to be made when it comes to how you distribute these roles and how you protect them.

General considerations:

Highly privileged roles should be assigned individual identities using Privileged Identity Management (PIM) and it is also a good practice to enforce approval for activating such roles.

These users should be cloud native and you should configure Identity Protection.

These features requires an Entra ID P2 license per user benefitting from PIM and Identity Protection.

All identities having privileged roles should be protected with phishing resistant MFA. Licensing these identities with access to services like Exchange Online or Teams should be avoided and handled with care.

Due to the nature of newer web browsers it is not recommended to use the same computer for administrative tasks as daily consumption of email and teams. Most web browsers have support for running several profiles running different user contexts. When clicking an external link you must avoid that the link starts in a browser signed in as an elevated user.

Considering implementing Privileged Access Workstation (PAW) is a good idea to avoid usability of stolen credentials and unintentional behaviour like a click on an external link ending up in an elevated browser.

Considerations assigning roles to different identities:

Personal user accounts:

Entra ID roles are often assigned to normal user accounts on a permanent basis, meaning that if a user falls for a phishing attack or clicks on a malicious link in teams or email the result could be catastrophic. Users change roles over time and if a user needed Sharepoint Administrator role years ago we find that most organizations don’t have good routines in removing this access when no longer needed. If you enforce proper security measures on these "admin" users to protect Entra ID, usability on these accounts would be limited.

Personal administrator accounts:

It is considered better to use separate dedicated personal administrator accounts to operate the environment. But technicians could still end up clicking a link ending up in the web browser that holds privileged permissions. These administrator accounts also tend to be unmanaged, and based on our experience, it’s normal to find several accounts not registered MFA or not been used for a very long time with permanent assigned privileged roles. It is also considered a security risk to license these accounts to Exchange and/or Teams. The requirement of phishing resistant MFA in combination with the usage of Privileged Identity Management (PIM) should be the minimum requirement for such users.

Guest accounts:

Even guest accounts can be assigned these roles, but these accounts are, in most organizations, unmanaged. If you assign permissions to a guest account, you automatically trust the organization, from where the account resides, to have very good on- and off-boarding routines and you trust their security setup. We’ve had several major incidents in Norway where guest accounts were compromised and resulted in organizations being attacked.

If You decide to assign Entra ID roles to guest accounts, you must use Privileged Identity Management (PIM) and set the eligibility to each role to expire in the very near future. It could also be a good idea to require an approval before elevating the guest user.

Groups:

Assigning roles to groups is also a common way of distributing permissions. It is an easy way of distributing permissions, but it is harder to figure out which user has which role and there is some downsides, like the possibility for self elevation from lower permissions and running automated access reviews on Entra ID roles. If you still want to use groups please read and follow best practices from Microsoft: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/groups-concept#how-are-role-assignable-groups-protected

You should also carefully review membership in these groups on a schedule. Access reviews is a great way to review membership in such groups.

If You still want to use groups for eligible role assignments, you should require additional approval on highly privileged roles.

Service principals:

It is common to use SaaS solutions and integrate them into your environment. Migration tools, backup tools and normal production software often need some sort of access into your environment to function properly. Very often providers of such software ask for way more permissions than they need. We’ve seen follow me print solutions holding SharePoint administrator role and systems controlling meeting room panels holding full access permissions to all mailboxes within organizations. If the application provider gets a security breach, how exposed are you, since the attacker then will have access to your environment with the permissions given the application?

As a side comment it is also important to evaluate from where these service principals sign in in from. If you gave an application provider a service principal to consume your data, you should evaluate from where the application is processing your data. Is your data protection officer informed?

How to clean-up your environment:

1. Review your current environment by using the Bsure Insights - Security - Entra ID Roles report
2. Remove roles and permissions from users, groups and service principals not needing them.

3. Ensure that all accounts holding such permissions are protected with phishing resistant MFA or ensure to protect them with conditional access policies ensuring that they can only be used from a specific ip or other measures that decreases usability of the account.
4. Ensure that all privileged accounts holds an Entra ID P2 license and configure Microsoft Entra Privileged Identity Management to get these features:

   • Provide just-in-time privileged access to Microsoft Entra ID and Azure resources

   • Assign time-bound access to resources using start and end dates

   • Require approval to activate privileged roles

   • Enforce multifactor authentication to activate any role

   • Use justification to understand why users activate

   • Get notifications when privileged roles are activated

   • Conduct access reviews to ensure users still need roles

   • Download audit history for internal or external audit

   • Prevents removal of the last active Global Administrator and Privileged Role Administrator role assignments

5. Review your current strategy on how you assign roles and permissions to your users:

   • Ensure separate administrative accounts to operate your environment

   • Don’t give privileged access to guest accounts unless you have proper governance on such users or set a short timeframe for the eligible role access

   • Only use groups for lower privileged roles, and if you use groups, you should create an access review policy on them.

6. Consider protecting usage of users with privileged roles by leveraging a Privileged Access Workstation and configure conditional access to only allow sign-ins from that device. This could be a virtual machine in Azure or a Windows 365 device