Increase MFA Usage with a Conditional Access Policy

Updated: February 6, 2024

On November 6, Alex Weinert, Microsoft’s VP for Identity Security, announced the “auto-rollout of Microsoft Entra Conditional Access policies that will automatically protect tenants based on risk signals, licensing, and usage.” The text explains that Microsoft will deploy up to three conditional access policies to “eligible tenants” (those with Entra ID P1 licenses to allow them to use conditional access policies). The Microsoft-managed conditional access policies require account sign-ins to use multi-factor authentication (MFA) to access specific forms of data, such as Microsoft 365 admin centers.

Update: Microsoft’s roll-out continues. Read this post to find out more.

Microsoft says that their “data tells us they [the policies] would increase an organization’s security posture.” Microsoft also points to a May 2023 study by Cornell University that finds MFA reduces the risk of account compromise by 99.22%. This is broadly in line with previous assertions about the effectiveness of MFA in stopping password spray and other attacks.

The aim of the initiative is to increase the overall usage of MFA across Microsoft from the poor levels reported over the last few years. At the TEC 2022 conference, Alex Weinert reported the figure to be 26.18% for all Microsoft 365 accounts and 34.15% for accounts holding an administrative role. Since then, Microsoft has rolled out new features to drive MFA usage and improve security, such as hardening the authenticator app, including authenticator lite in Outlook mobile, and pushing registration campaigns to encourage users to move from insecure MFA response methods to the authenticator app.

New Conditional Access Policies Deployed to Tenants

Initially, Microsoft will deploy three conditional access policies to tenants, who’ll receive a notification when the policies are present. A 90-day countdown starts after which Microsoft will automatically enable the policies. During this period, administrators can go to the Entra ID admin center (Figure 1) to review the policy settings and decide whether to tweak the policy settings.

For instance, Microsoft recommends that you exclude break glass accounts from the set of users covered by the policies to avoid encountering access problems if you need to use the break glass accounts.

Initially, the Microsoft-managed policies are in the report-only state. If administrators leave the policies alone, Microsoft will automatically enable the policies after the 90-day countdown lapses. If you don’t want Microsoft to do this, set the policy to Off. The first order of business is therefore to keep an eye on notifications posted by Microsoft and then review whatever policies appear in your tenant. Of course, there’s nothing to stop you from putting these policies into operation immediately.

Microsoft-Managed Conditional Access Policies

Table 1 lists the three initial Microsoft-managed policies. You can see that the policies focus on tenants with Microsoft Entra ID Premium licenses. That’s because these licenses are necessary to manage conditional access policies. Entra ID Premium P1 is included the Microsoft 365 E3 and Microsoft 365 Business Standard products. Entra ID Premium P2 is included in Microsoft 365 E5.

See the documentation for more details about the Microsoft-managed conditional access policies.

The Case of Per-User MFA

The fact that Microsoft has chosen to include a managed conditional access policy for per-user MFA users deserves some comment. Microsoft says that this policy “helps organizations transition to Conditional Access.” Essentially, what they’re saying is that they don’t want customers to use per-user MFA any longer. This is the form of MFA included in licenses like Office 365 E3. Administrators manage per-user MFA by selecting users and enabling MFA for them (Figure 2).

Microsoft believes that enforcing MFA through conditional access policies is a better and more robust mechanism that results in better tenant security. Administrators don’t have to worry about enabling MFA for users when creating accounts nor do they have to deal with user queries about MFA on an individual level. MFA is enforced by policy and once the policy settings work, the policy serves as many accounts as the tenant has.

Sounds good. The downside is that to move away from per-user MFA, Microsoft forces customers to purchase Entra ID Premium licenses if their base product licenses (like Microsoft 365 E3) don’t include a Microsoft Azure multi-factor authentication service plan. I think this is wrong and believe that if Microsoft really wants people to move away from per0-user MFA, they should receive free Entra ID Premium P1 licenses. That’s unlikely to happen, but it would be the right thing to do.

I support greater use of MFA within Microsoft 365. Protect yourself and protect your tenant by enabling and using MFA to protect all user accounts. You know it makes sense.

An Unreasonable Azure AD Sign-in Frequency Creates a Barrier to Productivity

I had an unpleasant surprise this week when the security team for one of the companies where I have a guest account decided to improve tenant security. I strongly support any effort to improve tenant security, especially when the effort means better use of multi-factor authentication. It’s a topic I’ll cover during the TEC Europe 2023 tour in London, Paris, and Frankfurt in April. Registration for those events is now open.

It’s always important to take a pragmatic and practical view of security and not to implement anything that has a significant impact on user productivity. All change can impact users, but most of the time people learn to live with change and it’s not disruptive. Unfortunately, deciding to increase the user sign-in frequency for Azure AD accounts can be extraordinarily disruptive if you go too far.

Azure AD sign-in frequency is the period before a user must sign in again when attempting to access a resource, like opening a SharePoint Online document, creating a message with OWA, or accessing a Teams channel. By default, Azure AD uses a rolling 90-day window for its sign-in frequency. In other words, once you successfully sign-into a tenant, Azure AD won’t ask you to sign-in again for another 90 days.

Revoking User Account Access

Ninety days sounds like a long time, and it is. But this period needs to be viewed through the prism of how Azure AD and Microsoft 365 applications work. For example, in early 2022, Microsoft enabled Continuous Access Evaluation (CAE) for all tenants. CAE is a mechanism that allows Azure AD to notify applications of a critical change in the directory, such as an updated password. Applications that understand CAE, like SharePoint Online, revoke existing access for the account to require the user to reauthenticate.

The Microsoft 365 admin center also includes an option to sign users out of all current sessions (Figure 1) to force them to reauthenticate.

Of course, you might want to do more than sign a user out. In some cases, like employee departures, you might want to block future sign-ins. This is an operation that’s easily scripted with PowerShell. For example, this code:

• Retrieves the identifier for an Azure AD user account.
• Disables the account.
• Sets a new password.
• Revokes all refresh tokens.

$UserId = (Get-MgUser -UserId Lotte.Vettler@Office365itpros.com).Id
# Disable the account
Update-MgUser-UserId $UserId -AccountEnabled:$False
# Set a new password
$NewPassword = @{}
$NewPassword["Password"]= "!DoneAndDusted?"
$NewPassword["ForceChangePasswordNextSignIn"] = $True
Update-MgUser -UserId $UserId -PasswordProfile $NewPassword -AccountEnabled:$True
# Revoke refresh tokens
$Status = Invoke-MgInvalidateUserRefreshToken -UserId $UserId

It might take a little time for the full block to be effective because tokens must expire, and clients recognize the need for reauthentication, but it will happen.

How Conditional Access Can Make Guest Accounts Miserable

The reason I had a problem was that the security team updated the conditional access policies for guest users to enforce a 60-minute sign-in frequency (Figure 2). This change had a horrible effect. Guests switching to the tenant with Teams inevitably resulted in an MFA challenge. Opening a document stored in SharePoint Online or OneDrive for Business in that tenant brought an MFA challenge. My day was filled with MFA challenges, except when sending email to people in the tenant to complain about the new policy. Email isn’t affected by conditional access policies.

As Microsoft notes in their documentation, “Based on customer feedback, sign-in frequency will apply for MFA as well.” They understate the matter. Sign-in frequency does apply for MFA too.

I understand the motivation on the part of the security team. Forcing people to reauthenticate before they can access resources is a good thing. Using MFA is a good thing. Forcing MFA challenges every hour must be a brilliant change to make.

Only it isn’t. As an external person working with another company, the change made my productivity much worse, and I doubt that it added one iota to the overall security effectiveness of the tenant. The tenant did not use number matching and additional context for MFA challenges, so the constant MFA challenges were a great example of how user fatigue creeps in as I clicked and clicked again to say “yes, it’s me.” System-preferred authentication wasn’t used either, so while I used the Authenticator app, other guests might use relatively insecure SMS challenge/response.

Overall, the change made it unpleasant to work with the tenant and that’s bad. A one-hour sign-in frequency is just too rigid and strict. I don’t know of any other tenant (where I am a guest) that uses such a short frequency. Most tenants I know of use the 90-day default. Some use 7 days. The most security-conscious (before now) uses a 1-day frequency.

No Best Answer for All Tenants

In truth, I don’t know the best user sign-in frequency to use for either tenant or guest accounts. It all depends on the security posture that an organization wants to assume. But I can say that most tenants would be better off making sure that all accounts use MFA and eliminating the use of the less secure authentication methods before reducing the sign-in frequency. If you’re concerned about guest hygiene (in this case, how secure a guest account is), have a different and more restrictive conditional access policy for guest access while remembering the need to get work done through Azure B2B collaboration. And review guest accounts annually to remove unwanted and obsolete crud.

To me, bringing users along on the journey to better security is a better tactic than ramming heightened security down their throats. It’s always been that way.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

New Conditional Access Policy Settings to Exert Granular Control Over External Users

Building on their recent work to improve Azure AD conditional access policies by adding a control to require specific authentication strengths for connections, Microsoft has released another interesting control (in preview). You can now differentiate between the different kinds of external users that connect to your tenant in a feature that Microsoft calls “fine-grained Azure B2B access control.”

Azure AD recognizes different kinds of connections based on the authentication flow, so it’s able to focus on connections such as B2B Collaboration like guests accessing a SharePoint Online site or when an account authenticated in another tenant uses B2B Direct Connect to access a Teams shared channel. The differentiation between connection types allows Azure AD to apply conditional access to impose conditions on specific connections.

Adding Control for External Users

To try the new control out, I created a new conditional access policy. Under the assignments section, I chose to include specific users. This option has always been available, but now you get to pick from the different types of external users supported by Azure AD (Figure 1).

For most Microsoft 365 tenants, the interesting options are B2B Collaboration and B2B Direct Connect. Guest accounts created using Azure B2B Collaboration have been in use since mid-2016 to support external access to resources in Outlook Groups, Teams, SharePoint Online, OneDrive for Business, Yammer, and Planner. The Azure B2B Collaboration policy is available to control the creation of guest accounts using a block list of domains. Even with a policy in place, tenants end up with large numbers of guest accounts and need to do some pruning to remove obsolete guests.

External accounts that use B2B Direct Connect to access Teams shared channels (the only workload currently supported) don’t have a presence in the tenant directory. Instead, these accounts authenticate against their own directory and present the credentials to gain access to the resources in the host tenant. If the cross-tenant access policies configured in both tenants permit access, the accounts can work with the resources.

The external user control includes other account types used in more specific circumstances. The point is that a lot of flexibility exists in the control of inbound connections. For instance, you can restrict the control to specific Microsoft 365 tenants (Figure 2) using either the tenant identifier or a registered domain for the tenant to add it to the policy (if you don’t know the tenant identifier, you can find it using an online service).

The new control works alongside the other controls available in a conditional access policy. In this instance, I configured the policy to apply to Office 365 apps and to require multi-factor authentication to grant access.

Planning Conditional Access Policies

An Azure AD tenant can support up to 195 conditional access policies. It takes planning to make sure that you don’t create a set of conditional access policies that conflict with each other and that each policy serves a well-defined purpose. For instance, the new ability to control external connections from specific tenants might tempt administrators to create to create multiple policies to control external access for external access from specific tenants. This is a bad idea and will probably be a maintenance nightmare. Try to use the one policy to handle external access from all partner tenants as it’s likely that much the same kind of controls will apply to all.

To make sure that other policies didn’t interfere with testing, I put any policy relating to external access into report-only mode.

Testing the Control

To test that the new policy worked as expected, I signed into Teams using an account belonging to the tenant specified in the policy. I then opened a shared channel and was immediately promoted with an MFA challenge. After satisfying the challenge, the client connected to the shared channel and the account could post messages. Figure 3 shows the authentication and conditional access details for a sign-in processed by the conditional access policy.

One More Control for Connections

Conditional access policies are not a universal panacea for keeping a Microsoft 365 tenant safe and secure from attackers. However, correctly configured and deployed, conditional access policies can stop people who shouldn’t access tenant resources from getting in. The new find-grained external access control is helpful in this respect. Remember that conditional access is an Azure AD Premium feature and deploy it alongside Exchange Online authentication policies to gain maximum protection from attacker probes.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Allows CA Policies to Differentiate Between MFA Methods

Building off yesterday’s discussion about Azure AD authentication methods and the discussion at the TEC 2022 conference about the need to do better with MFA, Microsoft released an important improvement to MFA effectiveness this week by enhancing conditional access policies with authentication strength for MFA challenges.

Last year, Microsoft added number matching and additional context to the Authenticator app to help address the issue of MFA fatigue. This is when people mindlessly respond to MFA prompts without registering what they’re doing, something that attackers can exploit to compromise user accounts. However, even if people pay attention to MFA prompts, there’s no doubt that SMS-based challenges deliver weaker protection than other methods.

Expanding Conditional Access Policies

Conditional access (CA) policies operate by applying rules to connections to determine if a user can connect to the requested resource. For example, can they access an Office 365 application like OWA. Combined with authentication policies, CA policies can severely limit the ability of an attacker to compromise user accounts and stop incidents like the OAuth exploit against Exchange Online recently reported by the Microsoft 365 Defender Research Team.

CA policies have been able to insist that accounts use MFA for many years. Up to now, one kind of MFA has been as good as another. Microsoft now differentiates the strength of authentication gained through the available methods (Figure 1).

SMS is graded at medium level and its usability is high because most people have smartphones. I’m not quite sure why it shows up as medium availability. Microsoft defines this as “an indication of the user being able to use the authentication method, not of the service availability in Azure AD”. Most people I know are very able to use SMS given that it’s a messaging capability in general use since the mid-1990s.

In any case, Microsoft acknowledges the problems with SMS when it responds to an authentication challenge, and they want to encourage people to use more secure methods. In reality, this means that Microsoft wants people to use their Authenticator app, Windows Hello, or FIDO2 key.

Using Authentication Strength in CA Policies

To test the new capability, I created a CA policy to control access to Office 365 and set the policy to grant access based on the authentication strength of the user connection. The default strength is multifactor authentication, meaning any of the traditional methods like SMS will satisfy the condition. I selected the next step up, requiring the use of passwordless MFA (Figure 2).

The strongest method is phishing-resistant multifactor authentication. Using a FIDO2 key satisfies this requirement. At TEC 2022, Alex Weinert, Microsoft’s VP for Identity Security, said that the Authenticator app will meet this requirement “soon.”

Note the warning about cross-tenant access settings. These are the Azure AD Direct Connect policies that underpin Teams shared channels. A cross-tenant access policy setting controls if your tenant accepts the multifactor authentication performed by the home tenants of external users who participate in shared channels in your tenant. You should accept those claims to allow external users to continue to collaborate even if they don’t measure up to the authentication strength required for tenant users.

Effect of Authentication Strength

The effectiveness of authentication strength was immediate. Users configured to use the authenticator app continued have access while those who used SMS were allowed to connect and told to select a new authentication method (Figure 3).

In Figure 3, Azure AD shows that a FIDO2 key is the only available method. This was because the user account had the authenticator method but it needed to be fully configured. Once this was done, the user could connect successfully.

Like any other authentication failure due to a CA policy, details of the failed connection are in the Azure AD sign-in log (Figure 4).

Heading to the Sunny Highlands of Secure MFA

It will be interesting to see how many organizations try to move users away from SMS-based MFA to more secure authentication methods. Just because Microsoft wants this to happen is no reason why it will in the real world. Some customers will love the new capability and rush to embrace it, but I suspect that the real challenge that needs to be fought first is to increase the current percentage of Azure AD accounts protected by MFA from 26.64% to well north of 50%. After killing basic password authentication and pausing for a breath, moving to really secure MFA might be the next hill to climb.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.