Stop the bad guys from getting into your Microsoft 365 tenant
Protecting access to a Microsoft 365 tenant should be a primary concern for the tenant administrators. With that thought in mind, it’s baffling that less than half of Entra ID monthly active accounts are protected by multifactor authentication.
Poorly protected user accounts create vulnerabilities in Microsoft 365 tenants that can result in tenant compromise and data loss. The best example of such an attack is the midnight blizzard attack against Microsoft’s own tenant in early 2024, where an account compromised in a test tenant eventually resulted in movement into the Microsoft production tenant. If that account had been protected with multifactor authentication, the attack could not have succeeded.
Smaller Microsoft 365 tenants are protected by Security Defaults, a basic set of preconfigured user settings to help protect tenants by enforcing controls such as requiring administrators to sign in with multifactor authentication. Microsoft also encourages better practice by insisting that any access to Azure administrative tools (like the Entra admin center) requires multifactor authentication. The same requirement for multifactor authentication will extend to the Microsoft 365 admin center in February 2025.
Conditional Access policies
Conditional access (CA) policies are the preferred method to enforce multifactor authentication for inbound connections to Microsoft 365 tenants. The older per-user multifactor authentication (bundled with Office 365 E3 and E5) still works, but Microsoft would like customers to move from per-user controls. CA policies are more flexible and powerful in terms of defining what kind of connections to control and it’s where their development resources are focused.
A CA policy works by evaluating inbound conditions to understand where the connection comes from (its physical location or IP address), the account involved in the connection, and the apps or resources the connection wishes to use. If a connection matches the conditions defined in a policy, Entra ID applies the controls set in the policy. Simple multifactor authentication, like responding to an SMS challenge with a number, is an example of a control. Simple challenges and responses are better than nothing, but you’re better off using a stronger authentication method that is resistant to phishing or man-in-the-middle attacks such as the Microsoft Authenticator app, passkeys, or FIDO2 keys (Figure 1). CA policies can help here by insisting that people use a strong authentication method for their connections.
Figure 1: Choosing a strong authentication method for a CA policy
The appearance of simplicity
On the surface, creating a CA policy for Microsoft 365 sounds like a straightforward operation that could be boiled down to a simple statement like “protect all connections with strong multifactor authentication.” If that’s all you need, the resulting policy might be very simple indeed. However, under the apparent mask of simplicity lurk many complexities waiting for unwary administrators.
For example, every Microsoft 365 tenant should have at least two breakglass accounts. These accounts are not intended for day-to-day use. Instead, they exist to allow administrative access to the tenant in case of emergency when normal administrative accounts are unavailable. Breakglass accounts should be excluded from CA policies, if only to ensure that a mistake made in a CA policy that prevents “normal” accounts from accessing the tenant doesn’t stop emergency access. In this scenario, administrators can sign in with a breakglass account and modify the CA policy to restore normal access.
The problem here is that CA policies can be too good at controlling access. A mistake in policy configuration can lock everyone out of the tenant. This sounds improbable and you’d imagine that it couldn’t happen, but it does. For this reason, the Entra admin center cautions administrators to be careful when they create and enable CA policies. Need more convincing? Read Brandon Colley’s article about five common CA policy misconfigurations to discover where tenants go wrong.
CA policies can really mess with your head if too many policies exist in a tenant. Good reason might exist to create a new CA policy, and good reasons might keep on coming along to justify the creation of more policies, but the simple fact is that each policy adds to the complexity of connection processing. Figure 2 shows an example where Entra ID might have to evaluate the settings from eight separate policies to decide whether to accept a connection.
Figure 2: Multiple Conditional Access policies might be evaluated for a user sign-in
Entra ID is very good at interpreting and applying policy conditions, but human beings are less adept at understanding the full set of conditional processing that results from multiple CA policies. In this situation, troubleshooting user connections can be very difficult. It also becomes easier to make mistakes and either let bad connections through or block good connections. Seeking simplicity is always better than chasing complexity.
Reduce your AD attack surface.
Smart Conditional Access management
Given the dangers of inadvertent lock-out, it pays to spend some time thinking about what a tenant needs Conditional Access policies to do. In other words, be able to enunciate clear goals for the overall CA framework in a plan that guides policy creation and enforcement. This work should take existing mechanisms into account. For instance, your tenant might have received some predefined CA policies created and distributed by Microsoft to reduce the friction of introducing conditional access.
Before creating any Conditional Access policy, you should be able to document:
- What set of users come within the scope of the policy. Groups can be used to identify subsets of users for specific processing.
- What apps or resources are being protected. It could be that you simply want to protect Microsoft 365.
- What devices or locations are allowed for connections.
- What exceptions should exist. Breakglass accounts are an example. The rights management app might be another, if you use sensitivity labels with Outlook classic.
- What controls to apply before a connection is accepted. As a rule, don’t use weak authentication methods like SMS and favor strong authentication from the start. This might mean that some work is required to ensure that users have the ability to respond to authentication challenges with an app, passkey, or FIDO2 key. Users also need Entra P1 licenses for CA policies.
Some tools are available to help plan. Paul Robichaux’s article covers a practical approach to CA planning and implementation and is a good start. A community initiative exists to maintain a tool to document CA policies in PowerPoint. Seeing the conditions, exclusions, and controls illustrated in slides works surprisingly well. It’s possible to automate CA policy configuration updates with PowerShell, something that’s probably more useful in large enterprise tenants.
Takeaways
I expect Microsoft to continue to find new ways to require connections to Entra ID to be protected by multifactor authentication. The percentage of protected connections is rising and will continue to rise in the foreseeable future. Conditional Access policies are the best way to control connections and should be implemented in any Microsoft 365 tenant that’s serious about security. Just don’t rush in and go crazy with CA policies. Plan, take a measured approach, test, implement, and tweak. It’s the tried and trusted approach that really works.
