Client Access Rules 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 Office 365 organization.
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 V2 module, which supports modern authentication. This article shows how to start a remote session to Exchange Online using the V2 module. Keep in mind, however, that in WinRM you still need to configure Basic authentication setting even if using module V2 (more information on this Microsoft’s site).
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 Exchange admin center in Office 365 (Microsoft 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 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 meganb@example.com
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
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 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 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 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 meganb@example.com
Bottom line
As I mentioned, these are just examples of what you can do with Client Access Rules to manage client connections to your Office 365 organization. Feel free to explore the topic and strengthen your business security.
See also:
It is worth mentioning, that:
a) UserRecipientFilter can only use a very limited subset of filterable attributes — see the full list in New-ClientAccessRule documentation.
b) the rules are actually applied to mailboxes and not to user accounts, despite Microsoft documentation stating otherwise. Big deal if you’re using delegation or impersonation.