Skip to content

Microsoft Secure Score Series – 02 – Require MFA for administrative roles

In this series, I’ll be covering the Microsoft Secure Score improvement actions. Although Microsoft does a great job on telling you what to do, some actions have a much bigger impact and need to be balanced against business needs. Some actions might not even have value for your organization. In the end, Microsoft Secure Score is meant to strengthen your security, not a contest to reach the highest score possible. In this series, I’ll pick out random actions and try to make it as simple as possible, backed with notes from the field.

Articles in this series can be read separately since they are written at random order. The articles vary in case of impact and complexity and cover multiple categories. Here is a list of all the articles in this series:

01 – What is Microsoft Secure Score?

02 – Require MFA for administrative roles

03 – Enable Password Hash Sync if hybrid

04 – Ensure all users can complete multi-factor authentication for secure access

05 – Enable self-service password reset

06 – Enable policy to block legacy authentication

07 – Turn on sign-in risk policy

08 – Use Cloud App Security to detect anomalous behavior

09 – Do not allow users to grant consent to unmanaged applications

10 – Discover trends in shadow IT application usage

11 – Turn on user risk policy

12 – Turn on customer lockbox feature

13 – Set automated notifications for new and trending cloud applications in your organization

14 – Designate more than one global admin

15 – Do not expire passwords


Require MFA for administrative roles

Requiring multi-factor authentication (MFA) for all administrative roles makes it harder for attackers to access accounts. Administrative roles have higher permissions than typical users. If any of those accounts are compromised, critical devices and data is open to attack.


In this post, we take a look at enabling MFA for your administrators. As stated in the description, users with administrative roles are interesting targets for hackers. Of course, it is recommended to enable MFA for all your users, but this post will focus on the privileged users only. I hope to cover the MFA rollout for users in another blogpost.

Impact

When you complete this action, your administrators will have to register for MFA. Depending on your policy, the affected users then get prompted for MFA when they login to cloud applications or do administrative tasks. This can have an impact on their day to day tasks. For example:

  • Users with administrative roles will get prompted for MFA when accessing cloud resources such as email through the browser.
  • Users with administrative roles will get prompted for MFA when using mobile or desktop applications.
  • Users with administrative roles will get prompted when kicking off PowerShell scripts.
  • Users with administrative roles will get promoted when enrolling a new device.

What about the license?

Enabling MFA for your admin users can be done in multiple ways. The most common way is to use a Conditional Access policy. This requires an Azure AD Premium P1 license. In the next step, we are going to take a look at using dynamic groups, which also requires a P1 license. If you are using Azure AD Basic or Free, the options for MFA are limited. See this article for more information. If you have either an Azure AD Premium P2 or Enterprise Mobility + Security (EMS) E5 license, you can use Azure AD Privileged Identity Management (PIM) to enable MFA for your administrators. More on that later.

First things first

There a couple of things to keep in mind. When enabling this policy, all your selected roles will be impacted, including your service accounts for example. It is recommended to exclude your service accounts from this policy. The easiest way to this is by adding those accounts to an Azure AD security group and add them to the excluded groups in your policy. If you have a naming convention in place for your service accounts, you can use a dynamic group. New service accounts are then added to this group based on an attribute and will be excluded from your policy automatically. Using a dynamic group to exclude your service account is optional but is easier to maintain.

Also, it’s recommended to create emergency accounts, in case there is an MFA outage or a misconfiguration on your tenant that causes problems. This way, you can always log in, using a break glass account to change the configuration. You can exclude these accounts from your Conditional Access policy, just like your service accounts. Learn how to create these specific accounts.

Next, I would recommend enabling the combined security information registration portal for your administrators. Using this portal, your administrators can register not only for MFA but also for Self Service Password Reset. Normally, this registration process would take place in two different portals. The new portal is in preview for quite a while now, but I like it much more than the “old” one. The wizard is more intuitive and smoother. You can enable this combined portal trough the Azure portal -> Azure Active Directory -> User Settings -> User feature previews

My Profile showing registered Security info for a user

Implementation

Okay, so let’s get started with creating the Conditional Access rule. Keep in mind, that you can test this on a small group first, by selecting just 1 single administrator role at step 3. Also, you can choose to enable the report only mode at step 6, instead of turning the policy on. This way, you can first monitor the impact on a smaller group of users, or just monitor what would have happened when you enabled it right away.

In the Azure portal Conditional Access page
1. Select + New Policy. Start off by giving it a proper name.
2. Go to Assignments > Users and groups > Include > Select users and groups > check Directory roles
3. At a minimum, select the following roles: (exclude your service – and break glass accounts)

  • Security administrator
  • Exchange service administrator
  • Global administrator
  • Conditional Access Administrator
  • SharePoint administrator
  • Helpdesk Administrator
  • Billing Administrator
  • User administrator
  • Authentication Administrator

4. Go to Cloud apps or actions > Cloud apps > Include > select All cloud apps (and don’t exclude any apps)
5. Under Access controls > Grant > select Grant Access > check Require multi-factor authentication (and nothing else)
6. Enable policy > On
7. Create

(Admin)user experience

Administrators will get prompted to register for MFA the first they log in after the policy is enabled. Your users then can add multiple factors, depending on your MFA and SSPR settings.

You can track these events using the Azure portal. Go to Azure Active Directory -> Sign-ins and filter for Status: Interrupted

Azure AD Privileged Identity Management

If you want to take this a step further, and you have the right license, you can start using Azure AD Privileged Identity Management (PIM). Using this premium feature you can give your user just in time access (JIT) to privileged roles. This means that the privileged user is eligible to have certain admin roles, but does not have them permanently enabled. A quick overview of how Privileged Identity Management works:

  1. Privileged Identity Management is set up so that users are eligible for privileged roles.
  2. When an eligible user needs to use their privileged role, they activate the role in Privileged Identity Management.
  3. Depending on the Privileged Identity Management settings configured for the role, the user must complete certain steps (such as performing multi-factor authentication, getting approval, or specifying a reason.)
  4. Once the user successfully activates their role, they will get the role for a pre-configured time period.
  5. Administrators can view a history of all Privileged Identity Management activities in the audit log. They can also further secure their Azure AD organizations and meet compliance using Privileged Identity Management features like access reviews and alerts.

This way, you can stay on top of your privileges users and use the least privileged access model.

When you consider rolling out PIM for your organization, read the Microsoft docs on this subject. Apart from having MFA enabled for your admins, PIM can have a lot more value to your organization. It also can reduce costs and minimize risks.

Wrap things up

You can enable MFA for your privileged users in multiple ways. You can either configure a conditional access policy, user Privileged Identity Management or enable MFA manually (not covered in this article). Try to automate a much as possible to avoid mistakes. Choose the option that fits your license and business requirements, but start today when you do not have this in place.

Stay safe!

2 thoughts on “Microsoft Secure Score Series – 02 – Require MFA for administrative roles”

  1. Pingback: Microsoft Secure Score Series – 04 – Ensure all users can complete multi-factor authentication for secure access - JanBakker.tech

  2. Jan – I’ve the CA policy configured however what I’m noticing is that because we use PIM for groups and assign the privileged roles to the group and the membership is eligible. The conditional access policy doesn’t seem to factor in that these PIM groups are assigned active permanent Admin Roles.

    We have break glass which aren’t using pim and are permanent standing GA’s which are recognized as not having MFA
    so we get marked 0/10 for the score, have you seen this behavior before with PIM for Groups & Secure score mismatch ??

Leave a Reply

Your email address will not be published. Required fields are marked *