In the first post of the series I focused on blocking legacy authentication options, and some of the special challenges that Microsoft 365 Business users were facing. This post will discuss the updates that have occurred since then, and then move on to using Conditional Access to enforce MFA for admins and users.

First things first, the changes I just mentioned. Well, a few things have changed in the last couple of weeks. In the last post I mentioned that you don’t get the per tenancy view without AAD Premium, but now clicking on the Sign-in events chart takes us to Sign-in events instead of the AAD Premium trial suggestion.

The sign in events provides seven days worth of sign-in logs, so you can now see this at the tenancy level as opposed to a user by user basis.

The other news was that Microsoft 365 Business will be moving across to Azure Active Directory Premium P1 instead of a subset of that functionality, which means amongst other things, you will start to get 30 days of Sign-in events history. This will roll out over the coming months, and is a very welcome addition to Microsoft 365 Business.
Moving on to the main topic, enforcing MFA for Admins and Users. We could create a policy that does both in one, such as just creating it for all users and all apps, but creating two policies gives us a bit more flexibility, and makes it easier to allow staged rollouts to admins, and then selected groups of users before going all in.
Jumping in to the Administrators MFA policy, we start by selecting Directory roles (Preview) and then selecting the roles. There isn’t a select all option, so just click through all of the roles on the list. This also means that we will need to periodically check on this list to make sure newly added roles are also being protected. Don’t worry too much about any exclusions yet, just make sure you already have at least a Global Admin successfully able to use MFA.

Next we need to select the apps we want this to apply to, and we don’t really want any exceptions for now.

Last but not least, we need to Grant access if MFA requirement is met, and enable the policy. You will be prompted to exclude the current user, but if you have already verified that MFA is working for that account it’s safe to ignore it and apply to all roles.

We don’t really need to change much to create the All User policy, I’ve kept All cloud and require MFA the same as the previous example.

You might also want to also create a policy for All guest and external users (Preview) even if the environment isn’t quite ready to invite external users into Teams or other collaborative tools. If we are setting up the other policies, we might as well add this one as well, even if it’s planning for the future.

If you haven’t already started rolling out MFA, and are going to proceed cautiously, start with the admin/directory roles before rolling out to users. Before rolling out to users, make sure you have advised them in advance, and if possible, prepared them for using tools such as Microsoft Authenticator if app based MFA is your goal. You could even start with voluntary user enrolment for capabilities such as self service password reset, and have that drive the MFA enrolment process before you start enforcing it for the stragglers.