Secure by default – Microsoft Managed

First look at Microsoft-managed Conditional Access Policies

“Microsoft Managed” is a concept I was introduced to in Entra ID Authentication Methods. The idea was introduced when Microsoft were previewing a new feature. The Microsoft Managed state allows Microsoft to enable or disable the feature. This is supposed to be a convenient way to allow Microsoft to create the setting for those that would like to configure it, or if left untouched to tell Microsoft to enable it in the future. These settings have had their own release schedules and therefore the Microsoft Managed state meant different dates and states for different settings. You can review the current Microsoft Managed state of each of these Authentication Methods at https://aka.ms/msmanaged.

The Microsoft Managed is a way for Microsoft to improve on an organization’s security posture and ensure that the default configuration settings are the most secure.

Secure by default

In February 2020, Microsoft introduced “Security Defaults” and I blogged about enabling security defaults here. The idea then was originally targeting customers with the free Entra ID SKUs or the Entra ID included with Office 365. Customers with Entra ID Premium Plan 1 or 2 (Also known as AAD P1 or P2) could only switch on security defaults if they didn’t already have any Conditional Access policies configured. What that last statement meant however, was that some customers would have at least one Conditional Access policy (usually an MFA policy) but not complete coverage for all risk types. That means that you might have your MFA policy for users which is great, but it doesn’t mean your tenant is secure. So, to enhance those tenants that have Conditional Access (Entra ID P1 or P2), and fill the gaps, Microsoft have introduced “Microsoft-managed Policies”

This is a new feature that Microsoft started rolling out in November 2023. Targeting tenants that don’t have a policy covering Multifactor authentication (MFA) requirements for three scenarios:

1. Multifactor authentication for admins accessing Microsoft Admin Portals
2. Multifactor authentication for per-user multifactor authentication users
3. Multifactor authentication and reauthentication for risky sign-ins

As threats evolve, or new features and functionality become available, Microsoft may create other policies or modify these existing policies to improve their function.

I have seen the first of the 3 in a production tenant recently and have captured what the admin experience looks like. The “Multifactor authentication for admins accessing Microsoft Admin Portals” policy aims to require MFA for users with privileged roles accessing any Microsoft admin portal (such as portal.azure.com or admin.microsoft.com).

There are many things alerting you to the fact that there is a Microsoft-managed policy in your tenant. If you look at the image below, you’ll see, near the top the banner that says there are Microsoft-managed policies that will be turned on “soon” unless turned off. It’s worth mentioning that if you turn the policy off, Microsoft won’t switch it on after the 90-day review period. I’ll go into the other options you have later.

The second thing that is new to the Conditional Access Policies blade in Entra ID is the summary of policies with the split showing the number of Microsoft-managed policies out of the total. In my case I see only 1 out of the 13 policies. I assume the more policies you have in total, the less likely you are to have Microsoft-managed policies.

The list of policies also has the Microsoft-managed policy surfaced at the top of the list automatically for visibility. The alert column tells us that action is required. Clicking on the learn more link takes you too https://aka.ms/MMAdminMFA for this specific policy.

Note, there is an extra column called “Tags” in this view, and I don’t see a way of setting your own tag on a custom policy (perhaps via MS Graph you can), so for the moment only Microsoft managed policies will have a tag, saying:

MICROSOFT MANAGED

If you click on the Policy Name “Multifactor authentication for admins accessing Microsoft Admin Portals” in the list of policies, instead of taking you to the policy edit experience of a normal policy, you are presented with a flyout panel which explains Microsoft-managed a bit more and gives you limited configuration options:

The flyout panel says “Microsoft-managed policy” as a title, and the name of policy as a subtitle. Then there is another warning block of text which says: “Microsoft-managed policies will be enabled no sooner than 90 days after creation unless you take action. We recommend that you review these policies and take the recommended actions. Learn more“

The learn more link takes you directly to the applicable policy in the documentation. In this case it’s the MFA for Admins accessing Microsoft Admin Portals policy.

Next in this flyout panel, we are given some recommended actions. In this case review the policy and switch it on now, or leave it in report-only mode to monitor the effects it WOULD have. Alternatively, if you switch it’s state to OFF now, Microsoft will leave it off.

We don't know if Microsoft will leave it off forever or if they will bug you to switch it on again in the future.

We could also exclude some accounts, and in this case, it’s a good idea to exclude our break-glass accounts.

An important aspect of the policy details in this flyout panel, is the Created date, because that will give you an indication of when Microsoft will enable the policy if you don’t make changes yourself. In my case the policy was created on 11/30/2023, 8:02:07 PM which means at 8PM on 28th February 2024, this policy will go into effect if I don’t make any modifications before then. By the way, February has 29 days in 2024 because it is a leap year 😊

Then the flyout panel gives us some information about the policy settings, like the admin roles that are affected (14 roles). This list is not editable, but you can “exclude” a role.

You are only able to edit two aspects of the policy. The state (On/Report-only/Off) and the excluded users, groups or roles.

The really useful aspect of the flyout panel is the “Policy impact on sign-ins” section which give you a quick summary of the effect of the policy over the last week or so.

It seems to show 7 days worth of analytics of the policy. I can’t see how you can change the time-frame in this view, but if you have access to Conditional Access Insights and Reporting, you could view the data over a longer or shorter period.

This sample in my case, shows 15 thousand sign-ins in the period were granted access because they were not affected by this policy, but 34 sign-ins were granted access because they WOULD have successfully satisfied the MFA requirement. However, there are 10 sign-ins where the user needed to do something (user action required). Something for me to look into a little deeper (thanks Microsoft).

These insights should help you decide whether or not to enable the policy now, or let Microsoft enable it in ~3 months time.

Actions

Now one of the actions I could take, is create a duplicate of the policy, by clicking the duplicate button at the top of the flyout panel. This creates a brand new CA policy with a default name of “Microsoft-managed: Multifactor authentication for admins accessing Microsoft Admin Portals COPY” – this name can be edited though. In fact you can edit all aspects of the duplicate policy if you wish, unlike the Microsoft Managed policy which limits you to editing only the exceptions and the state.

My understanding if you duplicate this policy and tailor it to your needs, Microsoft will not enforce their Microsoft-managed policy on your tenant, as long as your custom policy covers the risk that their policy would cover sufficiently.

Note: You can't delete a Microsoft-managed policy.

Finish up

Once you have finished editing the aspects of the policy that you can edit, the policy will continue to be listed on your tenant as a Microsoft-managed.

My recommendations

At a minimum you should enable the Microsoft-managed policies as soon as you see them in your tenant, so as to protect your tenant with the base-level of protection Microsoft would like you to achieve.

For an enhanced protection, you can edit the exclusions on the policy or duplicate the policy. My recommendation for admins and MFA is to require phishing resistant MFA by creating an authentication strength. The other recommendation if you have Entra ID P2 is to enable Privileged Identity Management (PIM) and PIM for Groups to manage Just-in-time privileged access to your tenant instead of having standing privileged users.

If you need some guidance on other recommended Conditional Access policies to enable in your tenant before Microsoft-managed policies get automatically applied to your tenant, take a look at the templates in Conditional Access and also common Conditional Access policies.

All text in this post are my original thoughts, no large language models (LLM) or generative AI was used in the creation of the blog post.