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 from Azure AD 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 Azure AD 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 Azure AD applies conditions from the set of policies. Examination of records in the Azure AD 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 Azure AD 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 Azure AD app owned by another tenant that creates an instance of the app in other tenants. Alongside the app instance, Azure AD 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 Azure AD 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 from Azure AD) 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 in your Azure AD, 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.