The Device Code Authentication Flow

In late February 2024, Microsoft introduced a preview setting for Entra ID conditional access policies to block authentication flows. Although the setting covers the device code and authentication transfer flows, my feeling is that Microsoft has the device code flow squarely in their sights, saying: “Device code flow is a high-risk authentication flow that might be used as part of a phishing attack or to access corporate resources on unmanaged devices.”

The device code authentication flow is defined in RFC8628. It exists in Entra ID to support devices that don’t have the ability to sign into Entra ID in a more orthodox manner, like a TV set. The mechanism works by allowing an app running on the device to post a request to the Entra login endpoint. The request includes the app identifier and the resource that the app wishes to access. The response is a direction to open a verification URL (normally https://microsoft.com/devicelogin) and input a 9-character code included in the response. If someone goes ahead and opens the page in a browser and inputs the code, the authentication request is successful and Entra ID issues an access token. The app polls for a successful outcome and proceeds if an access token becomes available.

The problem here is that attackers can exploit the flow by:

• Starting an app and requesting authentication.
• Asking the victim to open a browser and input the code. Obviously, some social engineering is in play here and the attacker probably prepared the victim to be ready to action a request.
• If the victim complies, the app is signed into the victim’s account and can use the permissions held by that account.

Detecting Device Code Authentication

It’s entirely possible that your tenant has never used device code authentication. A quick check is possible by checking the Entra ID sign-in logs as follows:

[array]$SignIns = Get-MgBetaAuditLogSignin -Filter "AuthenticationProtocol eq 'devicecode'"

$SignIns | Format-Table CreatedDateTime, ResourceDisplayName, UserDisplayName

CreatedDateTime     ResourceDisplayName UserDisplayName
---------------     ------------------- ---------------
01/05/2024 20:18:34 Microsoft Graph     Lotte Vetler
01/05/2024 20:15:51 Microsoft Graph     James Abrahams
27/04/2024 22:52:57 Microsoft Graph     Jane Sixsmith

The Entra ID sign-in logs are available for 30 days, so the data only covers that period. Nevertheless, it might be helpful in finding who uses the device code authentication flow and what resources they connect to.

Blocking the Device Code Authentication Flow

Returning to the original theme, support in conditional access policies for blocking selected authentication flows means that it’s easy to block device code authentications with a conditional access policy (follow the Microsoft instructions documented here).

Here’s an example of the policy in action. I attempt to start an interactive Microsoft Graph PowerShell SDK session by running the Connect-MgGraph cmdlet with the DeviceCode parameter. Entra ID responds with the instruction to open the browser and enter a code. But the authentication flow cannot complete because the block imposed by the conditional access policy and the attempt times out:

Connect-MgGraph -NoWelcome -DeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code FYK8NA4XS to authenticate.
Connect-MgGraph: Authentication timed out after 120 seconds due to inactivity. Please try again.

The browser interaction works, and the user is then prompted to sign-in to the requesting app. At this point, Entra ID checks the connection and the policy restrictions kick in. The user sees an error like that shown in Figure 1.

In passing, remember to consider securing interactive Microsoft Graph PowerShell SDK sessions to known users. Not everyone needs to run interactive PowerShell sessions to execute Graph requests.

Tightening Control over Inbound Connections

Microsoft continues to add new features to conditional access policies to examine different aspects of inbound connections. I can’t imagine that it will be long before blocking authentication flows becomes a generally available feature, but that’s no reason not to use the feature now to tighten security a tad. And remember, when you create a new conditional access policy, always add an exclusion for a breakglass account.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. 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.

Conditional Access MFA Gives Outlook Desktop a Problem with Protected Email

I think most Microsoft 365 tenant administrators would agree that multifactor authentication (MFA) is a good thing. MFA stops bad guys compromising accounts even if they have the password. Microsoft’s recent little bother with Midnight Blizzard could have been cut off had the account whose password was uncovered by a password spray attack been protected with MFA.

Sensitivity labels are also good in terms of their ability to protect sensitive Office documents and PDF files with encryption. The usage rights assigned in sensitivity labels stop people who don’t have access from being able to decrypt and view the content of protected files.

Two good things create a warm feeling of snug protection, or so it might seem. That is, until conditional access policies get in the way. Specifically, conditional access policies that insist on MFA for all cloud apps without exclusions. This seems like a very good kind of policy because it enforces MFA before users can connect to OWA, the new Outlook “Monarch” client, SharePoint Online, Teams, and so on. However, “all cloud apps” means all cloud apps, including the Microsoft Rights Management Services app. This is a multi-tenant app that exists in tenants that use Microsoft Information Protection, the basis of the encryption applied by sensitivity labels to protect files.

Get-MgServicePrincipal -filter "displayname eq 'Microsoft Rights Management Services'" | Format-Table DisplayName, AppId, SignInAudience

DisplayName                          AppId                                SignInAudience
-----------                          -----                                --------------
Microsoft Rights Management Services 00000012-0000-0000-c000-000000000000 AzureADMultipleOrgs

Let’s assume that you deploy a conditional access policy to enforce MFA for all cloud apps. With this configuration in place, users generate and send some protected email by applying sensitivity labels with encryption. Some messages go to external recipients, but that’s OK because the usage rights defined in the labels allow the external recipients to access the content.

The Problem with MFA for All Cloud Apps

All works wonderfully if the external recipients use OWA, Monarch, or Outlook Mobile to read the messages. Decryption for these clients is managed by Exchange Online, which obtains the necessary use licenses to allow the clients to access the content. However, Outlook desktop (Win32) uses a different scheme and must obtain use licenses from Microsoft Rights Management Services running on the originating (your) tenant. This is when you see the dialog telling you that Outlook is configuring the computer for Information Rights Management (Figure 1).

But the conditional access policy in the sending tenant insists on MFA for all cloud apps and there’s no way for Outlook to satisfy an MFA challenge in your tenant. Deprived of the use license, Outlook falls back to displaying the RPMSG wrapper for the message (Figure 2).

Clicking the read the message link brings the user to the Office 365 Message Encryption portal, where they can read the message. This proves that the usage rights given to the user allow access. The problem lies with not being able to obtain the use license due to the MFA challenge.

Excluding Microsoft Rights Management Services

The simple solution is to exclude the Microsoft Rights Management Services app from all conditional access policies that enforce MFA for user connections. This is easily done by editing policies through the Entra admin center (Figure 4).

PowerShell makes it easy to scan and update conditional access policies in the tenant. A similar approach to the one to add breakglass accounts to conditional access policies can be used to add an exclusion to policies.

The script (available from GitHub) performs these steps.

• Connects to the Microsoft Graph PowerShell SDK.
• Runs the Get-MgIdentityConditionalAccessPolicy cmdlet to find the set of enabled conditional access policies.
• Checks each policy to see if an exclusion for the Microsoft Rights Management Services app is present.
• If no exclusion is present, the script checks if the policy uses MFA (with or without authentication strength) as a control.
• If the policy applies MFA, the script checks if a forced password change is set (this eliminates the possibility of adding an app exclusion) and that the policy doesn’t use an authentication context. Both prevent the addition of an excluded app to the policy.

Once it’s sure that an exclusion is possible, the script adds the exclusion. Figure 5 shows the script in action.

It’s an Ecosystem Thing

It’s unfortunate when a clash occurs between two important parts of the Microsoft 365 ecosystem. It’s a reminder to us all about the importance of taking a holistic view of functionality instead of focusing on a single workload. Some will think that this problem is something that Microsoft testing should have found. That’s a fair perspective, and Microsoft’s documentation does cover some potential issues with conditional access and encrypted documents, but it’s unlikely that the testing regime considers how sensitivity labels work with Outlook desktop for external recipients when MFA is involved.

Any debate must be tempered by the realization that the clash appeared due to the increased usage of multifactor authentication (due to incessant campaigning by Microsoft) allied to increased use of sensitivity labels to protect information. Both are good trends.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Check Conditional Access Policies and Add Breakglass Accounts if Necessary

Breakglass accounts (or as Microsoft calls them, “emergency access accounts”) are intended for emergency use, such as when other administrative accounts are compromised or are locked out. Conditional access policies control inbound connection attempts and can lock everyone out if misconfigured. That’s why most experienced administrators make sure to exclude breakglass accounts from conditional access processing. Excluding the breakglass accounts means that Entra ID never imposes conditional access control on their connections. In effect, it guarantees access through breakglass accounts when all others fail. Well, if you remember the password for the breakglass accounts…

Best Laid Plans and Conditional Access Policy Exclusions

The best laid plans of mice and men often come undone and someone fails to insert the necessary exclusions into a conditional access policy. Given Microsoft’s ongoing focus on moving tenants to conditional access to enforce multi-factor authentication, the risk of being locked out due to a bad policy setting is obvious.

Automation through PowerShell offers a solution. The processing is simple:

• Find all conditional access policies in the tenant.
• Check if the necessary exclusions exist.
• If not, and the policy is active, add the exclusions and update the policy.

Alternatively, you could update all policies with a missing exclusion even if they are disabled or in report only mode.

Exclusions can be declared as individual user accounts or groups. In this scenario, something like a security group is overkill. The set of breakglass accounts should be limited to as few as possible and they don’t change over time unless necessary following the use of an account for emergency access to a tenant. In other circumstances, a group is a good way to exclude a set of user accounts from a conditional access policy.

Using the Microsoft Graph PowerShell SDK to Work with Conditional Access Policies

A script to check and update conditional access policies can use Graph API requests or cmdlets from the Microsoft Graph PowerShell SDK. This example uses the SDK. First, connect to the Graph endpoint with the necessary permissions:

Connect-MgGraph -NoWelcome -Scopes Policy.ReadWrite.ConditionalAccess

The next step is to declare the breakglass accounts. I do this by including the object identifiers for the accounts in a simple array. I also declare the same values in a structure to pass to the Update-MgIdentityConditionalAccessPolicy cmdlet to update user account exclusions in a conditional access policy. The structure is a PowerShell representation of the body posted to the underlying Graph API request. If you want to use a group, the parameters will include the object identifier of the group in the excludeGroups section of the structure.

[array]$BreakGlassUsers = "91813a30-f048-48f1-a0f2-fd7c72020515", "b7289bc7-7e4e-44e2-ae1b-7e13e94e3749"
$Parameters = @{
    Conditions = @{
        users = @{  
            excludeUsers = @(
                "91813a30-f048-48f1-a0f2-fd7c72020515"
                "b7289bc7-7e4e-44e2-ae1b-7e13e94e3749"
            )
        }
    }
}

With everything prepared, the script runs the Get-MgIdentityConditionalAccessPolicy cmdlet to find the set of conditional access policies before looping through each policy to check the exclusions. If the breakglass accounts are not present and the policy is active, the script runs the Update-MgIdentityConditionalAccessPolicy cmdlet to add the exclusions.

[array]$Policies = Get-MgIdentityConditionalAccessPolicy | Sort-Object DisplayName
ForEach ($Policy in $Policies) {
    Write-Host ("Checking conditional access policy {0}" -f $Policy.displayName)
    [array]$ExcludedUsers = $Policy.conditions.users.excludeUsers
    ForEach ($User in $BreakGlassUsers) {
        If ($User -notin $ExcludedUsers) {
           Write-Host ("Can't find user {0} in CA policy {1}" -f (Get-MgUser -UserId $User).DisplayName, $Policy.DisplayName)
           If ($Policy.State -eq 'enabled') {
              Write-Host "Policy is enabled so updating it with break glass accounts" -ForegroundColor Red
              Update-MgIdentityConditionalAccessPolicy -BodyParameter $Parameters -ConditionalAccessPolicyId $Policy.Id
           }
        }
    }
}

If you use a group instead of user accounts, the check should be against $Policy.conditions.users.excludeGroups. Figure 1 shows the script in action. This kind of check to make sure that everything’s OK is a classic example of something that should run on a scheduled basis, preferably using Azure Automation rather than Windows Scheduler.

You can download the script from GitHub.

No Excuse for Running into Conditional Access Problems

With so much experience about configuring and using conditional access policies in production plus tools like ID PowerToys to document policy settings, lack of knowledge is no excuse for misconfiguring policies. But life is hard sometimes and we all make mistakes, and that’s why it’s good to automate checks to make sure that anticipated backstops work when needed.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

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.

Extra Year to Give Tenants Time to Overcome Technical Limitations that Prevent Migration

Without much fanfare, the Exchange Online team decided to give tenants that use client access rules an extra year to make the transition to Azure AD conditional access policies. The original deprecation date of September 2023 is now September 2024. The kicker in this statement is that only rules that cannot be migrated to conditional access policies because of a “technical limitation” can continue working for the extra year.

First announced at the Microsoft Ignite 2017 conference, client access rules are only available in Exchange Online and exist to control connections coming into Exchange Online. You can do things like block POP3 and IMAP4 connections or restrict access to these protocols from specific IP addresses.

Client access rules are a solution created by Exchange Online for an environment that was very different to today. In 2017, customers wanted help to control inbound connections to Exchange Online. Azure AD conditional access policies didn’t have the feature set that’s available now and Exchange Online still supported basic authentication across all its connectivity protocols.

The Current State of Microsoft 365 Connection Management

Moving forward to today, Microsoft has largely eliminated basic authentication from Exchange Online to cut off techniques like password sprays that attackers heavily depended on to retrieve user account credentials. Attackers still try, but attempts to use basic authentication to check username/password combinations fail at the first hurdle. Apart from keeping access to SMTP AUTH, there’s no further need for authentication policies.

Deprecating client access rules could be construed as another side effect of modern authentication becoming the norm in Exchange Online. But the more important factor is that Microsoft 365 favors features that function across the entire ecosystem instead of being tied to a single workload. Azure AD is the directory of record and conditional access policies are how Azure AD controls inbound connections. Dropping client access rules (specific to Exchange Online) to embrace conditional access policies is evidence of that trend. We see the same in the compliance and information protection areas where Microsoft 365 policies take prime position.

Microsoft is pouring engineering effort into Azure AD conditional access policies. In the last year alone, Microsoft has added features such as:

• Granular access for external user types.
• App filters.
• Authentication strengths.

Conditional access policies are closely associated with multi-factor authentication and are often configured to ensure that inbound user connections use MFA, especially for administrator accounts.

Migration Away from Workload-Specific Implementations Can be Problematic

Moving from a workload-specific implementation to a platform-wide implementation can be problematic. It’s likely that the workload-specific code covers narrower use cases that only occur within a workload. For example, Exchange Online mailbox retention policies can process items at a folder level and move items to the online archive when their retention period expires. By comparison, Microsoft 365 retention polices process mailboxes as a single unit and don’t go to folder level and can only delete or keep items instead of being able to move them to the archive. Then again, because Microsoft is actively developing Microsoft 365 retention policies, they benefit from recent innovations like adaptive scopes and disposition reviews, neither of which are available for Exchange mailbox retention policies.

In the case of client access rules, Microsoft acknowledges that they “have encountered a few scenarios where it’s not possible to migrate current rules” and say that they will allow the ongoing use of client access rules “until we can support them” (presumably the scenarios that migration is not currently possible).

Microsoft doesn’t describe what scenarios are problematic. They also don’t say how customers can discover if their client access rules fall into the category of those that Microsoft consider to have a technical limitation that prevents migration. Microsoft plans to disable client access rules that they consider can be migrated to conditional access policies in September 2023. Only rules that receive Microsoft approval can continue running until September 2024, at which point the curtain descends for all client access rules (Figure 1).

Apart from not documenting the technical limitations that get in the way of migration, Microsoft also doesn’t say how customers receive approval for the one-year extension for client access rules. The blog says that customers should “open a support ticket so we can investigate and understand your needs,” but doesn’t explain how this process results in a rule being allowed to continue running past September 2023.

The Filtering Issue

Browsing the documentation for client access rules, the obvious issue appears to be in the areas of filtering. Like in other areas (like dynamic distribution lists), Exchange Online supports recipient filters for client access rules in a different manner than operated for conditional access policies. You can assign conditional access policies to specific users and groups (including dynamic Microsoft 365 groups), but that’s not quite the same as using a recipient filter. I’m sure that I am missing something else, but recipient filtering seems like the big obstacle for migration.

I strongly support moving away from client access rules to embrace more secure implementations like conditional access policies that operate across the complete Microsoft 365 ecosystem. Microsoft throws continuous access evaluation (CAE) into the pot. Although CAE is a very good innovation to revoke access from accounts immediately important events like password changes occur, the issue here is all about migration.

Client Access Rules Migration Might Need Updates to Conditional Access Policies

If you’re using client access rules, it’s time to review the state of the migration.

• Remove client access rules that are no longer necessary.
• Migrate the remaining rules to conditional access policies.
• If any rules cannot be migrated, contact Microsoft Support to discover if a technical limitation exists to prevent migration. If it does, the rules can continue working until September 2024. If not, Microsoft Support should be able to tell you how to migrate to conditional access policies before September 2023.

Microsoft doesn’t say how they will address the technical limitations that allow some client access rules to remain operational until September 2024. This might be because the Exchange Online team is waiting for their Azure AD colleagues to implement some features in conditional access policies. At least, I hope that’s what’s happening.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Manual and Automatic Documentation of Conditional Access Policy Settings as PowerPoint Presentation

Windows has its Power Toys and now Microsoft’s identity management team is getting into the act with Identity Power Toys (idPowerToys), an app to help Azure Active Directory power users get work done. The initial release of the app is limited to a Conditional Access Documentator, a useful tool to read the configuration of conditional access policies fromEntra ID and generate documentation in the form of a PowerPoint presentation (using components from Syncfusion). The IdPowerToys GitHub repository is available for all to browse and contribute to.

Conditional access policies set conditions and criteria for Entra ID to examine inbound connections to decide if a connection should be accepted or rejected. A typical conditional access policy is one that requires accounts to use multi-factor authentication (MFA). The policy could even define that the authentication method used for the MFA response should be a certain strength. For instance, an SMS response is unacceptable but a response from the Microsoft Authenticator app is OK.

Only its creators love the GUI used to manage conditional access policies in the Microsoft Entra (Azure AD) admin center. It’s easy to make mistakes and people have been known to lock themselves out by implementing conditions that they can’t meet. It’s also easy to create conditions that make the daily interaction between people and apps miserable, such as cranking up the sign-in frequency for connections. Many different policies might exist in large enterprise tenants, and it can be hard to understand the flow that a connection traverses as Entra ID applies conditions from the set of policies. Examination of records in the sign-in log throws some light onto the situation but can be a drag.

The Conditional Access Documentator

Enter the Conditional Access Documentator, the first IdPowerToys app. The app is available online and supports two modes:

• Automatic generation: IdPowerToys retrieves of conditional access policies using an enterprise app created in the tenant’s Entra ID and generates a PowerPoint presentation. You can opt to mask different elements of the output. For instance, if you choose to mask policy names, IdPowerToys generates its own version of the policy name based on what it does. If you choose to mask user names, IdPowerToys outputs their account identifier instead of their display name.
• Manual generation: A tenant administrator runs a PowerShell command or uses the Graph Explorer to retrieve the JSON-formatted information about conditional access policies and pastes the results into a text box. IdPowerToys uses the information to create the PowerPoint file. Masking isn’t supported for manual generation.

An enterprise app is a registered Entra ID app owned by another tenant that creates an instance of the app in other tenants. Alongside the app instance, Entra ID creates a service principal to hold the permissions needed by the app. An administrator must grant consent before the app can use the permissions to access Entra ID to fetch the information about conditional access policies.

Some will be uneasy about granting an app permissions like Directory.Read.All (read information about accounts, groups, and other objects) and Policy.Read.All (read all policy information for the organization). However, as shown in Figure 1, the permissions are delegated, not application, which means that an account holding an administrator role must sign-into the app to use the permissions.

If you’re uneasy about creating an enterprise app with permissions, use the manual generation method and run the Invoke-GraphRequest cmdlet to fetch the data and output it to the clipboard. This command only works when run by an administrator:

Invoke-GraphRequest -Uri 'https://graph.microsoft.com/beta/policies/conditionalAccessPolicies' -OutputType Json | Set-Clipboard

Figure 2 shows the results retrieved from the Graph pasted into the IdPowerToys app.

In either case, the PowerPoint presentation generated to document conditional access policies is the same. For my tenant, which has 12 conditional access policies (not all in use), the app generated a 609 KB file with 13 slides (one title slide and one for each policy), divided into sets of enabled and disabled policies. Within a set, policies are sorted by last modified date, so the policy with the most recent modification appears first.

Figure 3 shows a presentation generated by IdPowerToys with details of a conditional access policy in the slide. This is a common policy to require MFA for guest access, with tweaks to require a certain authentication strength and to set the sign-in frequency to 90 days. You can see that the policy is enabled.

Visualize Conditional Access Policies Differently

Conceptually, generating documentation for conditional access policies isn’t difficult. Graph API requests exist to fetch the information and after that it’s a matter of parsing the conditions, actions, access controls, and session controls to output in your desired format. Some might prefer their documentation in Word. I think PowerPoint is just fine. IdPowerToys delivers documentation that just might help organizations visualize, clarify, and rationalize their conditional access policies, and that’s a good thing.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Azure AD IPv6 Connections Supported from March 31, 2023

The Azure AD development group certainly believes in keeping tenant administrators on their toes. Not content with releasing a steady stream of new functionality, Azure AD is refreshing its infrastructure by introducing support for IPv6 starting March 31, 2023. Given the size of the Microsoft 365 infrastructure, it’s impossible to put an exact date when support reaches a specific tenant.

As Microsoft says, this will allow customers to “reach the Azure AD services over IPv4, IPv6 or dual stack endpoints.” In other words, requests to Azure AD for authentication and other services from clients can travel over an IPv6 connection in addition to the current IPv4 connections. Microsoft stresses that they are not deemphasizing support for IPv4 in any way.

The change should be transparent from a user perspective. Most users don’t pay much attention to networking configuration and accept the default settings necessary to connect via Wi-Fi, cell network, or LAN. If problems happen, they’re more likely to surface for network and tenant administrators.

Conditional Access, Named Locations, and Azure AD IPv6

In its support page for the introduction of IPv6 to Azure AD, Microsoft specifically calls out the need to update any conditional access policies that apply restrictions using named locations. A named location allows a condition access policy to identify incoming traffic from a specific place based on a country (using GPS location or IP address) or a specific IPv4/IPv6 address range. The policy can then allow or block the connection. The Microsoft Entra admin center currently only supports IPv4 addresses for country identification.

After Azure AD supports IPv6, it creates the possibility that clients will present IPv6 addresses when they attempt to connect. If the conditional access policy doesn’t recognize the address as a permitted connection source, the client cannot connect.

Microsoft says that organizations should check conditional access policies to find those that use named locations and then update the named locations used by those policies to include the range of IPv6 addresses that clients will use. Figure 1 shows how to assign an IPv6 range to a named location in the Microsoft Entra admin center (or Azure AD admin center).

Obviously, it might take some effort to determine the full set of IPv6 addresses that clients might use, so it’s best to start this work as soon as possible.

Other Places Where IP Addresses Lurk

A change in originating IP address has consequences for other parts of an infrastructure. For instance, connection data captured by Azure AD will now contain IPv6 addresses. For instance, the unified audit log ingests information about user sign-ins from Azure AD. The audit records contain the IP address used by the client. Here’s what an audit record found by the Search-UnifiedAuditLog cmdlet holds:

RecordType   : AzureActiveDirectoryStsLogon
CreationDate : 24/01/2023 18:33:13
UserIds      : Jane.Smithoffice365itpros.com
Operations   : UserLoggedIn
AuditData    : {
                 "CreationTime": "2023-01-24T18:33:13",
                 "Id": "78bb9d6f-afc2-4ea7-ab7f-16fdb7423e00",
                 "Operation": "UserLoggedIn",
                 "OrganizationId": "a662313f-14fc-43a2-9a7a-d2e27f4f3478",
                 "RecordType": "AzureActiveDirectoryStsLogon",
                 "ResultStatus": "Success",
                 "UserKey": "eff4cd58-1bb8-4899-94de-795f656b4a18",
                 "UserType": "Regular",
                 "Version": 1,
                 "Workload": "AzureActiveDirectory",
                 "ClientIP": "78.17.97.20",
                 "ObjectId": "797f4846-ba00-4fd7-ba43-dac1f8f63013",

Audit records generated by Azure AD can go elsewhere. For instance, a connector is available to import the data into Microsoft Sentinel. The flow of data from Azure AD to other applications highlights the need to check that reports and analysis of this data is capable of processing IPv6 addresses.

All Change in Azure AD

March 2023 is going to be a big month for tenant administrators. Already, work had to be done to upgrade PowerShell scripts to remove old Azure AD and MSOL cmdlets that perform license management operations. These cmdlets will stop working when Microsoft 365 introduces a new license management platform on March 31. Now work must be done to check what IPv6 addresses might show up once Microsoft enables IPv6 support in the tenant. It’s all go inside Microsoft 365…

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.

Custom Security Attributes Used for Conditional Access App Filters

In January 2022, I wrote about the introduction (in preview) of Azure AD custom security attributes. At the time, Microsoft positioned the new attributes as part of their Attribute-based Access Control initiative for Azure to give organizations the ability to manage resources at a fine-grained level. Not being an Azure expert, I tried the new custom security attributes out and felt that organizations would figure out ways to use them.

Lots of new stuff has happened recently with Azure AD conditional access policies, like the introduction of new checks for external user type and authentication strength. Now, Microsoft has added a filter for apps based on custom security attributes.

Mark Apps with Custom Security Attributes

The idea is simple. Organizations define custom security attributes to use to mark apps known to Azure AD. An app is an object and like any other Azure AD object, administrators can assign the app whatever custom attributes make sense. For instance, you could assign an attribute to indicate the department that uses an app or an attribute to mark an app as highly important. The point is that the custom attribute is then used by a filter (Figure 1) to identify apps that a conditional policy can allow or block access to.

For now, app filters in conditional access policies can only use string custom security attributes, but you can select attributes from any attribute set defined in the organization. The app filter can be combined with any of the other controls available in a conditional access policy.

The value in this approach is that you don’t need to amend a conditional access policy to accommodate new or additional apps. Simply update the app with an appropriate value for the custom security attribute used by the app filter and the app immediately becomes within the policy scope. That’s a big advantage in large organizations that might have to manage hundreds (or conceivably, thousands) of applications.

Graph X-Ray in Windows Store

In other Azure AD news, the Graph X-Ray tool that exposes the Graph API calls made by (some parts of) the Azure AD admin center is now available in the Windows Store (Figure 2). I recommend this tool to anyone who’s getting acquainted with the Graph API calls used for objects like users and groups.

The Graph X-Ray tool helped us enormously when we upgraded the PowerShell examples using the soon-to-be-deprecated Azure AD module to Graph API calls or Microsoft Graph PowerShell SDK cmdlets for the 2023 edition of the Office 365 for IT Pros eBook. Sometimes you need just a little hint to understand what approach to take and the Graph X-Ray tool delivers more than its fair share of hints.

Cmd.Ms

From the same fertile mind as Graph X-Ray comes Cmd.ms, an elegantly simple idea that delivers great value. Microsoft 365, as you might have observed, spans a bunch of administrative portals and consoles and it’s sometimes difficult to remember the URI for a specific portal. You can go to the Microsoft 365 admin center and rely on the shortcuts available there to get you to the Teams admin center, Exchange admin center, SharePoint Online admin center, and so on, but what happens if you haven’t loaded the Microsoft 365 admin center or need to go somewhere that isn’t available as a shortcut? That’s where Cmd.ms comes in.

Essentially, Microsoft has defined a set of web shortcuts to the admin centers (Figure 3). Entering teams.cmd.ms brings you to Teams while admin.cmd.ms loads the Microsoft 365 admin center. It’s tremendously useful.

Cmd.ms add-ons are available for Edge, Chrome, and Firefox to provide autocomplete suggestions in the browser address bar.

The only issue I have is that Microsoft chose to use ad.cmd.ms to bring you to the Entra admin center and azad.cmd.ms to the Azure Active Directory admin center. I know Microsoft wants to emphasize the Entra brand, but it would be nice to have aad.cmd.ms used for Azure AD rather than azad.cmd.ms. It’s a small buggette.

Continued Evolution of Conditional Access

Returning to the original topic, there’s no doubt that Microsoft is putting a great deal of effort into improving the functionality of Azure AD conditional access policies. The recent batch of announcements underline this point. It’s all about erecting more efficient barriers to unauthorized access. Hopefully attackers can’t get into an Azure AD tenant. If they do, conditional access policies can help restrict their ability to compromise resources. That’s the logic underpinning the deployment of conditional access.

And How to Block this Access

I recently noted that the Graph Explorer utility has some useful new features. Well, here’s another feature to consider that might be useful some day: you can sign into the Graph Explorer as a guest user in a tenant.

When you start Graph Explorer, you can run sample commands that operate against dummy data or sign into a tenant to use real data. Up to now, you sign in with a tenant account to access the data in that tenant, just like you’d sign into OWA or the Microsoft 365 admin center.

Signing into Graph Explorer as a Guest

However, if you add the name of a tenant where you have a guest account to the Graph Explorer URI, the tool will sign into that tenant. For example, the “normal” URI for the Graph Explorer is:

https://developer.microsoft.com/en-us/graph/graph-explorer

To sign into another tenant with a guest account, add the service domain or the tenant identifier. For example:

https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=o365maestro.onmicrosoft.com

or

https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=163e0495-8f47-46df-a823-685b61cc8d89

If you know a tenant’s domain, but not its service domain or tenant identifier, you can use this website to look up the tenant identifier.

When you sign in using the Graph Explorer, you can use your regular account. Azure AD will go through the normal sign-in process for the target tenant, including enforcement of multi-factor authentication as dictated by that tenant, and if your account is recognized as a guest, you’ll connect. To validate that you’re using a guest account, run the sample “my profile” query and you’ll see that the user principal name shown for the account belongs to a guest. For instance, Figure 1 shows that Chris.Bishop@office365itpros.com is connected to the O365Maestro tenant using the guest account Chris.Bishop_office365itpros.com#EXT#@o365maestro.onmicrosoft.com.

Guest accounts are limited in what they can do when connected to a tenant. In many cases, attempts to run queries such as listing all users or all groups in the tenant result in:

    "error": {
        "code": "Authorization_RequestDenied",
        "message": "Insufficient privileges to complete the operation.",

Which is a nice way of saying that although your account is a valued guest in the organization, that’s not an invitation to poke around and look for information. Other requests, such as anything to do with a mailbox, see errors like:

"error": {
        "code": "MailboxNotEnabledForRESTAPI",
        "message": "The mailbox is either inactive, soft-deleted, or is hosted on-premise.",

Guest accounts do have mailboxes, but they are special cloud-only mailboxes created and managed by the Microsoft 365 substrate to store compliance records like those captured for Teams chats and channel conversations.

Blocking Access

Although the Graph Explorer enables limited access to tenant data for guest accounts, you might not like the idea of guests connecting like this. Three solutions exist. First, you can block user access to the Graph Explorer Azure AD app. Open the Azure AD admin center, go to enterprise applications, and search for Graph Explorer. Open the app’s properties and update the Enabled for users to sign in setting to Off (Figure 2) and save the new app settings.

This is a crude but effective mechanism that blocks all access to the Graph Explorer, including to administrators. Anyone attempting to access the app encounters the error:

AADSTS7000112: Application 'de8bc8b5-d9f9-48b1-a8ad-b748da725064'(Graph Explorer) is disabled.

Second, you can assign specific users and groups to the app. The Assignment required slider is visible in Figure 2. When set to Yes, administrators must explicitly allow users and groups access to the app (through the Users and groups menu option on the left-hand side). If a user who doesn’t have an assignment attempts to use the app, they get the following error when they try to sign in:

AADSTS50105: Your administrator has configured the application Graph Explorer ('de8bc8b5-d9f9-48b1-a8ad-b748da725064') to block users unless they are specifically granted ('assigned') access to the application. The signed in user 'Chris.Bishop@office365itpros.com' is blocked because they are not a direct member of a group with access, nor had access directly assigned by an administrator. Please contact your administrator to assign access to this application.

Conditional Access Block

Conditional access (CA) policies offer the most precise way to control access. A simple CA policy to block access to the Graph Explorer app for guest users (Figure 3) does the trick.

Tenant users can continue to sign in and use the Graph Explorer, but guests run into the CA block (Figure 4).

We can also confirm the effectiveness of the CA policy by searching the Azure AD audit logs to look for sign ins to the Graph Explorer app. Here’s how to do it with the Microsoft Graph PowerShell SDK:

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
Select-MgProfile Beta
[array]$Records = Get-MgAuditLogSignIn -Filter "(appdisplayname eq 'Graph Explorer' and signInEventTypes/any(t: t eq 'interactiveUser'))" -Sort "createdDateTime DESC"

$Records | Format-Table createddatetime, userprincipalname, ConditionalAccessStatus

CreatedDateTime     UserPrincipalName                          ConditionalAccessStatus
---------------     -----------------                          -----------------------
28/08/2022 15:25:24 chris.bishop@office365itpros.com           success
28/08/2022 15:15:52 tony.redmond@office365itpros.com           success
28/08/2022 15:01:56 warren.gatland@o365maestro.onmicrosoft.com failure

Unknown User Case for Guest Access

After noodling on this subject for a few days, I still haven’t come up with a good use case why the Graph Explorer supports guest access. I suppose it’s a good thing and I’m sure that an Azure AD development engineer put forward an excellent case to justify the feature, but I know many will disagree. Now if I could use this access to update the photo for my guest account (possible with Azure AD PowerShell but not with the Graph), I’d have a good use case!

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Fixing the Achilles Heel of Office 365

Over the years, Office 365 has maintained a very high level of service, comfortably exceeding Microsoft’s financially-backed 99.9% SLA target since some initial glitches soon after Office 365 launched in 2011. When things have gone wrong recently, Azure AD has often been the source of problems. Authentication woes of one sort or another have existed since the start of Office 365. As long ago as 2015, I asked the question if Azure AD was the Achilles heel for Office 365.

In some respects, it’s natural that the directory service should be a hyper-critical component of any service, whether cloud or on-premises. If a client cannot authenticate, it cannot access resources. It’s a simple equation proven by the many instances when loss of authentication capability brought clients to a crashing halt.

The Backup Authentication Service and Its Three-Day Cache of Successful Authentications

Microsoft has gradually improved the resilience of Azure AD over the years by eliminating single point of failures (like the MFA service) and building out capacity. The latest innovation is a backup authentication service, aimed at underpinning 99.99% authentication uptime for Azure AD.

A November 22 blog post explains the plan. Microsoft has implemented a service which monitors Azure AD to detect any outages. When an outage occurs, the backup authentication service swings into operation to handle authentication requests from clients, which are routed to it automatically by the Azure AD gateway (the first point of contact When the primary instance of Azure AD recovers, the backup service dynamically reroutes requests to it and returns to monitoring (normal) mode.

The backup service handles authentication requests using information derived from successful authentication requests processed by Azure AD (Figure 1). This information can be up to three days old. It’s enough for the backup service to validate that an application successfully authenticated at a point in time within the last three days and go ahead to generate an authentication response to allow the application to proceed. According to Microsoft, more than 90% of authentication requests processed by Azure AD are for existing client sessions. These can all be handled by the backup service. On the other hand, because the backup service doesn’t have any data for new sessions, it cannot handle these requests (or requests from guest accounts).

Conditional Access and Resilience Defaults

Apart from dealing with authentication requests, the backup authentication service enforces multi-factor authentication, conditional access policies, and continuous access evaluation to ensure that invalid credentials cannot be used.

To ensure as high a level of continuity of service as possible, the backup authentication service uses resilience defaults for conditional access policies to allow it to continue without depending on conditions such as sign-in risk or group membership that aren’t available in real time when the primary Azure AD service is offline. Essentially, the policies proceed on the basis that conditions have not changed since Azure AD went offline. Organizations who don’t want this to happen can disable the resilience defaults for all or some conditional access policies through the Azure AD admin center (Figure 2) in the knowledge that this will affect the ability of some client connects to authenticate.

Gradual Introduction Since 2019

The best thing of all is that the backup authentication service has been in place for OWA and SharePoint Online since 2019. In early 2021, Microsoft added support for “native” apps, including the Microsoft 365 apps for enterprise (like Outlook) and the Teams desktop and mobile clients. Because the rerouting of authentication requests happens at the gateway level and the responses from the backup authentication service are identical to those issued by the primary Azure AD service, no client reconfiguration or special settings are necessary.

Microsoft is now upgrading support to bring in apps using Open ID Connect, starting with their own Teams Online and Office Online apps and progressing to customer apps. They expect to begin rolling out this support at the end of 2021. At that point, all of Office 365 should be protected by the backup authentication service, which should mean that any future Azure AD outage should be much less serious than previous events.

Reasonable Compromise

Storing information about successful authentication requests for three days and using that information to allow people to continue working if the Azure AD service goes offline seems like a reasonable balance between utility and security. We know that Azure AD outages have occurred in the past. We also know that Azure AD continues to handle more traffic over time (now at 500 million monthly active users generating tens of billions of authentications daily, according to Microsoft), which creates stress on its own. Some Azure AD outages can be expected in the future. The good news is that a backup supply for authentications, at least for the majority of client sessions, is now available.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Protect Most Confidential SharePoint Online Sites

Adding to their container management capabilities, a feature for sensitivity labels demonstrate how to use authentication contexts with Entra ID conditional access policies to ensure secure access to information in SharePoint Online sites.

An authentication context is a way to tag information which needs special attention. First introduced in March 2021, authentication contexts are additional information required by a service provider before it grants access to a resource. Microsoft positions authentication contexts as a method to “target policies for data and actions within an app.” Put another way, authentication contexts allow organizations to apply more granular control to targeted data.

As implemented for sensitivity labels, authentication contexts link conditional access policies to let applications like SharePoint Online know that users must provide some extra information before they can access information in labelled sites. Let’s work through an example.

Define an Authentication Context

The first thing to do is to define an authentication context. In the Security section of the Entra ID admin center, open the Protection section, select Conditional Access and choose Authentication context. I created a context called Require MFA (Figure 1). The name is what you’ll see in apps like sensitivity labels. The ID for the context shown towards the bottom of the screen (c1 in this case) is an internal value written into the settings of sensitivity labels which use authentication contexts.

The Publish to apps checkbox is set, meaning that this authentication context is visible to apps like sensitivity labels and can be used by conditional access policies.

Create a Conditional Access Policy

The next step is to create a conditional access policy to use the authentication context to force multi-factor authentication. Conditional access policies can range from very simple to very complex. To prove that everything works as expected, I created a simple policy which blocks access to resources tagged with the authentication context unless the user authenticates with MFA. The new thing here is that you select the authentication context instead of apps (Figure 2). The requirement to use MFA is selected in the Grant section (not shown here).

Another easy thing to include in a conditional access policy to protect sensitive data is to include a terms of use (TOU) check to force users to read and acknowledge conditions governing access before they gain access to a site.

Updating the Sensitivity Label

To protect SharePoint Online sites with the conditional access policy, we configure a sensitivity label with the authentication context. Figure 3 shows the UI for sensitivity labels where we’ve selected the authentication context.

Any attempt to access a site with the label causes SharePoint Online to look at the label settings to see if an authentication context is specified. If one is found, SharePoint Online queries Entra ID to find which conditional access policy is associated with the authentication context and invokes the policy. In our example, attempts to access the site succeed if the user authenticates with MFA and fail otherwise.

Using PowerShell to Assign Authentication Contexts to Sites

The value of Sensitivity labels is that they make it easy to assign a set of different controls to containers, including conditional access policy protection to SharePoint Online sites. However, if your tenant doesn’t use sensitivity labels (yet), you can update sites with PowerShell. After you assign a label with an authentication context to a site, SharePoint Online updates two site settings:

• ConditionAccessPolicy: Holds the name of the conditional access policy protecting the site. When using an authentication context, this value is “AuthenticationContext.”
• AuthenticationContextName: Holds the name of the selected authentication context. As per Figure 1, it is “Require MFA.”

Check the values by running the Get-SPOSite cmdlet:

Get-SPOSite -Identity https://office365itpros.sharepoint.com/sites/SuperConfidential | ft con*, aut*

ConditionalAccessPolicy AuthenticationContextName
----------------------- -------------------------
  AuthenticationContext Require MFA

Now we know the properties to update, we can update other sites using the Set-SPOSite cmdlet:

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/ProjectAjax -AuthenticationContextName "Require MFA" -ConditionalAccessPolicy "AuthenticationContext"

Testing the Block

To test that everything worked as expected, I used Teams. Many SharePoint sites created today are linked to Teams, so it seemed like a good test scenario. As expected, when I tried to access a site assigned the sensitivity label without using MFA, the Teams Files channel tab failed to connect and displayed an error (Figure 4).

Microsoft says that they are upgrading the Teams Files channel tab to prompt for MFA authentication when necessary. This will make access smoother and avoid users seeing the instant fail in the current experience.

When I tried to open the site using the SharePoint Online browser interface, it opened successfully. This puzzled me for a moment until I realized it was because the account had gone through a self-service password reset (SSPR) challenge and that the credentials gathered through that process satisfied the MFA requirement. This is because Microsoft now uses combined security information for MFA and SSPR (if your organization doesn’t use combined registration, you can enable it using these instructions). When I encountered the SSPR “your organization needs more information” challenge, it didn’t immediately make me think that MFA was involved, but it was!

To confirm that Entra ID enforces the conditional access policy for the site, you can check the Entra ID sign-in logs. Figure 5 shows that Entra ID invoked the policy because a user covered by the policy signed into SharePoint Online. The sign-in record doesn’t capture details of the site, but if only one sensitivity label uses the conditional access policy and you know who signed in, you can put two and two together to know what happened.

Increasing Control

Linking sensitivity labels with conditional access policies increases the granularity of control a label can exercise over SharePoint Online sites and increases the usefulness of sensitivity labels for container management. Multiple conditional access policies can use a context, which opens a bunch of different possibilities about how to control access in different circumstances.

Given the amount of confidential information stored in SharePoint Online, it’s nice to be able control conditional access so easily and a good example of how Microsoft is steadily building up the container management capabilities for sensitivity labels. Make sure that you have the necessary licenses before you use the feature!

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.

Reducing Account Compromises for Exchange Online

Last October, Microsoft introduced the ability for Office 365 tenants to disable basic authentication for Exchange Online using protocol authentication policies. A recent tweet from Alex Weinart, a Group program manager on the Azure Active Directory team said that disabling basic auth reduces the account compromise rate by 67%. This is more than enough evidence for anyone running an Office 365 tenant to disable basic auth now.

Alex’s tweet also pointed to an interesting post called Discovering and Blocking Basic Auth that gave further evidence for the case against basic auth, especially for tenants who still support really old protocols like IMAP4 and POP3.

Why Do People Still Use Old Email Clients?

I don’t quite know why people still use IMAP4 and POP3 clients. Both protocols originate in the early days of email when the world and the internet were safer places and attackers didn’t seek to piggyback on top of protocols with brute-force and password spray attacks.

The simple fact is that more modern and safer email clients are available. Clients that support modern authentication include OWA for browsers and Outlook mobile for Android and iOS. People using Outlook for Windows should be forced to use modern authentication. Apart from personal choice (“I really like using the old Thunderbird client”), no good reason exists to support the use of old and insecure clients. The bottom line is that if you move people to safer clients, you can disable the IMAP4 and POP3 protocols completely to close a big fat hole in your tenant’s defenses.

Exchange Web Services

Although it can also use basic auth, Exchange Web Services (EWS) is in a different category to IMAP4 and POP3. EWS is used by the Outlook for Mac client and it’s also used by backup and migration products to stream Exchange Online data from mailboxes (backup) or import information into mailboxes (migration). It’s also possible that EWS is used by other third-party products. Overall, it’s unlikely that you can block EWS any time soon.

Understand and Manage Connection Protocols

The post about discovering and blocking basic auth makes two excellent points. First, you should understand what protocols are being used to connect to Exchange Online mailboxes in your tenant. If you don’t know who uses what protocols, you won’t be able to plan to manage the phase-out or control of protocols using basic auth.

Second, although all important user accounts should be protected by MFA, Azure Active Directory conditional access policies are a very flexible and convenient way to restrict basic auth connections to the lowest possible set, providing that is, if you’re willing to pay for Azure AD Premium licenses (which also enable other useful features such as Office 365 group expiry and naming policies). As the post reminds us, “Last year, we added the ability to block legacy authentication in conditional access” and goes on to explain a scenario where IMAP4 connections are restricted to specific IP addresses.

The post also points to another article describing how to use conditional access policies to block basic authentication. Given the world of threat that we live in and the number of attacks that flow in a continuous stream against Office 365 tenants, you should at least ask the question if you should deploy such a policy (perhaps even to a select group of users or client platforms) to eliminate or reduce the risk posed by basic authentication in your tenant. It’s the right thing to do.

For more information about identities and authentication in Office 365, read Chapter 3 of the Office 365 for IT Pros eBook.