One of the most interesting security options in Exchange 2019 is the Client Access Rules feature. It allows the administrator to define rules to block or limit access to EAC (former ECP) and to EMS (Exchange Management Shell). This functionality was not present in previous versions of Exchange and now it is a security milestone for small organizations, which cannot afford solutions like firewall operating at OSI layer 7 (application layer) to restrict access from the outside of the organization.
The purpose of Client Access Rules
Managing Client Access Rules is possible only from the Exchange Management Shell level. There is no GUI you can use to manage them. The Client Access Rules feature allows you to block:
- Individual IP addresses, e.g. 192.168.0.1
- Ranges of IP addresses, e.g. 192.168.0.1 – 192.168.0.10
- Subnet IP, e.g. 168.0.0/24
With the use of more advanced rules, you can also block elements like authentication protocols, selected users in Active Directory or users having specified attributes in AD like e.g. Department, Company, etc. To get more information about Client Access Rules, visit this Microsoft document.
The elements of Client Access Rules
A single Client Access Rule consist of the following elements:
- Condition – identifies the client connection to which the rule applies.
- Exception – identifies the client connection to which the rule should not apply.
- Action – defines what actions need to be taken when the client connection meets the condition.
- Priority – defines the order in which rules are executed. Every rule has a 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.
The cmdlets for Client Access Rules
There are different cmdlets available to manage Client Access Rules. See the list below:
- Get-ClientAccessRule – this cmdlet will return the results showing a list of currently configured rules.
- New-ClientAccessRule –this cmdlet lets you create new rules.
- Set-ClientAccessRule – use this cmdlet to modify existing rules.
- Test-ClientAccessRule – a useful cmdlet that lets you test a rule configuration.
- Remove-ClientAccessRule – use it to remove rules.
How to block access to EAC (ECP)
You can use Client Access Rules to block access to Exchange admin center. In my example below, I want to block access for all users except for one internal network, VLAN 192.168.171.0/24, which is Management. Thanks to that, other subnets within the organization as well as users from outside of the organization will have no access to Exchange admin center. The main purpose of it is to keep organization secure and protected from unauthorized access.
To start, it is a good practice to run the following cmdlet:
New-ClientAccessRule -Name “Always Allow Remote PowerShell” -Action AllowAccess -AnyOfProtocols RemotePowerShell -Priority 1
This command will prevent Exchange Management Shell (EMS) to be cut off in case the administrator makes a mistake during the configuration.
Block access for all users except for one network
In order to block the access to EAC for all user except for the particular network e.g. in my case it is VLAN Management 192.168.171.0/24, run the cmdlet like this:
New-ClientAccessRule -Name „Allow ECP only for VLAN MGMT” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 192.168.171.0/24 -Priority 2
As a result, only VLAN Management can access EAC. Users from other VLANs\subnets will not be allowed to access EAC.
Check a list of Client Access Rules
To check a list of configured rules, run the following cmdlet:
Get-ClientAccessRule
It will return results where you can see details about each rules like name or their priority on the list.
Check if the rule works properly
To test the rule to verify if it works as expected, try to log in to EAC from the network other than, in my case, 192.168.171.0. If the rule works correctly, you should see something similar to:
To test the rule, you can also run abovementioned cmdlet Test-ClientAccessRule. This will simulate the connection e.g. from IP address 192.168.169.2 to EAC for the Administrator user:
Of course, this is only an example of how you can use cmdlets to manage a wide range of functionalities offered by Client Access Rules. Let’s now see how to block access to EAC by using different Active Directory attributes.
Block access to EAC depending on user Active Directory attributes
Let’s assume that your company security policy requires that only employees of the IT Department can have access to Exchange admin center. To make this case more complex, let’s also assume that the IT Department is located in different parts of the world as well as there are different networks to take into account (LAN, VLAN etc. which is really problematic to write rules based on IP addresses).
To meet the abovementioned requirements, you can create the Client Access Rules based on, for example, the Department attribute in Active Directory. I created two new employees in AD who are members of the IT Department and assigned them with Organizational Management rights.
Before I start a new rule configuration, I remove the rule based on the IP subnet by using the following cmdlet:
Remove-ClientAccessRule
Now, I can create a new rule, which will check the value of the Department AD attribute. If the value is different than “IT”, the access will be denied. This is the command:
New-ClientAccessRule -Name „Allow access to ECP only for IT” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -UserRecipientFilter {Department -ne “IT”} -Priority 2
Now it is time to test the new rule. I will use a newly created account of Jon Snow to access EAC (Jon is a member of the IT team). For this purpose, I run this cmdlet:
If there are no results returned, it means that no Client Access Rules apply to the user. And this is correct as I configured a blocking rule. Let’s now test what happens when I change the value of the Department attribute to “HR”.
To check the results of the rule, I use the same cmdlet as for the example above:
You can see that once I changed the value of the Active Directory attribute, the Client Access Rule works correctly by blocking access to ECP.
This is what it looks like from the browser (for Jon Snow if he is in the “HR” Department):
And here is an example for another user, Tyrion Lannister who is from the “IT” Department. As you can see, the user has access to ECP:
Bottom line
Those examples are just a small part of what you can really get from the Client Access Rules functionality in Exchange 2019. The list of scenarios that you can cover by using this feature is almost endless and will definitely help you meet strict security requirements in your Exchange 2019 environment.