How to block access to your Exchange Online organization using Client Access Rules

[Update] This post was updated on June 22, 2023 because of the plans to deprecate Client Access Rules in Exchange Online.

Client Access Rules (or CARs) in Exchange Online are rules that you can use to control which client connections are allowed and not allowed to access your Exchange Online organization. They let you define the conditions based on various properties of a client. These can be, for example, the protocol they use to connect, their IP address or an Active Directory attribute. Thanks to that, you have an option to block (or allow) certain client connections to better protect your Microsoft 365 (Office 365) organization.

Deprecation of Client Access Rules in Exchange Online

Although they are incredibly useful, the days of Client Access Rules are soon to be over.
As announced in this Exchange Team Blog, CARs were disabled in October 2022 for those tenants that hadn’t used them. Complete retirement was planned for September 2023.

But as with many other deadlines, the date needed to be pushed forward. According to this announcement, it turned out that the substitutes for CARs (AAD Conditional Access and Continuous Access Evaluation) don’t support all scenarios. While Microsoft boasts superior security, some rules simply cannot be migrated yet. That’s why the Redmond-based company decided to push the Client Access Rules’ retirement to September 2024. That’s when all scenarios should be supported.

In the meantime, September 2023 is when rules without technical limitations will be retired. So, what are those technical limitations? For example, defining auth policies for different connection methods. I’ll be sure to write an article on how to use AAD Conditional Access before the CARs deadline comes.

The elements of Client Access Rules

Client Access Rules are defined with the following attributes:

• Conditions – here you define the client connections you want to block or allow access for. Once the conditions are met (the client trying to connect to your EO matches the characteristics in the conditions), then the action is applied. 
• Exceptions – this attribute lets you narrow down the scope of the rule, which means that if the client connection matches your exceptions, the rule will not apply to that client connection. It’s optional.
• Actions – here you decide whether you want to allow or block the access to your Exchange Online organization.
• Priority – each rule has its priority number assigned. The lower the number, the higher the priority. By default, the oldest rules have the highest priority, so they are processed first.

Note: Once a rule is applied, no more rules are processed.

The cmdlets for Client Access Rules

When managing Client Access Rules, you can use the following cmdlets:

• Get-ClientAccessRule – shows a list of currently configured rules.
• Set-ClientAccessRule – modifies existing rules.
• New-ClientAccessRule – creates new rules.
• Test-ClientAccessRule – lets you test rule’s configuration.
• Remove-ClientAccessRule – removes the rules.

For more details on using Client Access Rules cmdlets, check out this Microsoft article.

Note: To manage Client Access Rules, it is recommended to use Exchange Online PowerShell V3 module, which supports modern authentication. This article shows how to start a remote session to Exchange Online using this module.

With Client Access Rules, you can cover so many different scenarios that it is impossible to discuss them all. That is why I will focus on just a few examples that may be a good start for your Client Access Rules exploration.

Block access to the Exchange admin center in Microsoft 365 (Office 365)

Client Access Rules can be your way to prevent external or internal client connections to your Exchange admin center. This will help you protect your organization against any unauthorized access attempt.

Important: Before you start, it is a good practice to run the below cmdlet which prevents remote PowerShell from being accidentally blocked for the administrator. You definitely don’t want to lose access yourself. The rule should have the highest priority.

New-ClientAccessRule -Name "Always Allow Remote PowerShell" -Action Allow -AnyOfProtocols RemotePowerShell -Priority 1

Block access for all users except for a specific IP address

To block access to the Exchange admin center for all users except for one IP address (e.g. Management), run the following cmdlet:

New-ClientAccessRule -Name "Allow EAC access only for MGMT" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 192.168.171.0 -Priority 2

Note: You can also provide an IP address range, for example, 192.168.171.0-192.168.171.254 or 192.168.171.0/24.

Get a list of Client Access Rules

To see what rules you already have configured, run the following cmdlet:

Get-ClientAccessRule

Verify if the rule works as expected

To test your client access rule, you can use the following cmdlet:

Test-ClientAccessRule

For example:

Test-ClientAccessRule -AuthenticationType BasicAuthentication -Protocol ExchangeAdminCenter -RemoteAddress 192.168.171.0 -RemotePort 443 -User [email protected]

Remove PS session

Once you have finished setting up your Client Access Rules, make sure to disconnect the session by using this cmdlet:

Disconnect-ExchangeOnline

Or, if you are not using the Exchange Online PowerShell V2 module, disconnect with the following cmdlets:

Get-PSSession | Remove-PSSession

Keep in mind that the Get-PSSession is the legacy method to connect to Exchange Online. Learn more about the deprecation of RPS protocol used in this method.

Prevent access to EAC based on user Active Directory attributes

Depending on Active Directory attributes of a user, you can define who can or can’t access the Exchange admin center. This is helpful, for example, when you can’t rely on IP addresses (different location and networks of users). Then, to create a Client Access Rule for a specific group of people, you can use one of the AD attributes, for example, the Department attribute. 

Removing old rules

So, to start creating this new rule, I first remove the rule for the IP address I added in the previous steps. The cmdlet for removing is as follows:

Remove-ClientAccessRule –Identity "Allow EAC access only for MGMT"

Creating a new rule

Now, to allow access to EAC only for members of the IT Department, you can use the following cmdlet:

New-ClientAccessRule -Name "Allow access to EAC only for IT" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -UserRecipientFilter {Department -ne 'IT'} -Priority 2

This will check if the Department attribute value matches “IT”. All access attempts that have different Department value will be blocked. For example, all members of the Marketing or Sales Departments will not have access to the Exchange admin center.

Checking if the rule works correctly

Once you have created the rule, it is a good practice to check if it works as expected. To verify that, try connecting to the Exchange admin center from a user account where the Department value equals “IT”. Then, repeat the testing but this time change the Department value for the user to, for example, “HR” or “Marketing” and see if the access is blocked for that user.

To test this, you can also run the Test-ClientAccessRule cmdlet. For example:

Test-ClientAccessRule -AuthenticationType BasicAuthentication -Protocol ExchangeAdminCenter -RemoteAddress 192.168.171.0 -RemotePort 443 -User [email protected]

Bottom line

As I mentioned, these are just examples of what you can do with Client Access Rules to manage client connections to your Microsoft 365 organization. Feel free to explore the topic and strengthen your business security.

See also:

• How to block external access to the Exchange admin center in Exchange 2019 via Client Access Rules?
• How to prevent Office 365 users from sending emails outside the organization?
• New-ComplianceSearch: how to use the newer version of Search-Mailbox
• Update your Exchange Online PowerShell module to V3 before it’s too late