[Update]: This post was updated on May 08, 2020.
One of the most interesting security options in Exchange 2019 is the Client Access Rules feature. It allows the admin to define rules to block or restrict access to EAC (formerly ECP) and EMS (Exchange Management Shell). This functionality was not present in previous versions of Exchange and is now a security milestone for small organizations that cannot afford solutions such as firewalls that work at OSI layer 7 (application layer) to restrict access from outside the organization.
The purpose of client access rules
Management of client access rules is only possible at the Exchange Management Shell level. There is no GUI you can use to manage them. With the Client Access Rules feature, you can 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
Using advanced rules, you can also control items such as authentication protocols, selected users in Active Directory, or users with specific attributes in AD such as e.g. B. Block department, company, etc. (the last option seems to be reserved for Exchange Online, for the moment). For more information about client access rules, see this Microsoft document.
The elements of the client access rules
A single client access rule consists 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 action to take when the client connection meets the condition.
- priority – defines the order in which rules are executed. Each rule is assigned a priority number. The lower the number, the higher the priority. By default, the oldest rules have the highest priority, so they are processed first.
The Client Access Rules cmdlets
Various cmdlets are available to manage client access rules. See the following list:
- Get-ClientAccessRule – This cmdlet returns the results showing a list of the currently configured rules.
- New-ClientAccessRule –Use this cmdlet to create new rules.
- Set-ClientAccessRule – Use this cmdlet to modify existing rules.
- Test-ClientAccessRule – A useful cmdlet that you can use to 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 the 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. This prevents other subnets within the organization and users from outside the organization from accessing the Exchange admin center. The main purpose is to keep the organization safe and secure from unauthorized access.
A good place to start is to run the following cmdlet:
New-ClientAccessRule -Name “Always Allow Remote PowerShell” -Action AllowAccess -AnyOfProtocols RemotePowerShell -Priority 1
This command prevents the Exchange Management Shell (EMS) from being truncated if the administrator makes a mistake during configuration.
Block access for all users except one network
To block access to EAC for all users except the respective network, e.g. B. in my case VLAN Management 192.168.171.0/24, run the cmdlet as follows:
New-ClientAccessRule -Name „Allow ECP only for VLAN MGMT” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 192.168.171.0/24 -Priority 2
Consequently, only VLAN management can access EAC. Users from other VLANs/subnets are not allowed to access EAC.
Review a list of client access rules
Run the following cmdlet to review a list of configured rules:
Get-ClientAccessRule
Results are returned where you can see details about each rule such as name or priority in the list.
Verify that the rule is working properly
To test the rule to verify that it works as expected, try logging into EAC from a different network than 192.168.171.0 in my case. If the rule is working properly, you should see something similar to:
You can also run the above cmdlet to test the rule Test-ClientAccessRule. This simulates the connection e.g. B. from the IP address 192.168.169.2 to EAC for the administrator user:
Of course, this is just one example of how you can use cmdlets to manage a variety of functionality offered by Client Access Rules. Now let’s look at how to block access to EAC using various Active Directory attributes.
Block access to EAC based on the user’s Active Directory attributes
[Important] At the time of writing this article, this method worked flawlessly. However, a recent test revealed that -UserRecipientFilter is no longer available in Exchange 2019. This Docs article seems to confirm this information. The New-ClientAccessRule cmdlet with this filter runs successfully and returns no errors. However, access is not blocked afterwards. Running this cmdlet in Exchange Online works without any issues.
Suppose your corporate security policy requires that only IT staff have access to the Exchange admin center. To make this case even more complex, let’s also assume that the IT department is located in different parts of the world and that there are different networks to consider (LAN, VLAN, etc.), which is really problematic, rules based on IP to write addresses).
For example, to meet the above requirements, you can create the client access rules based on the department Attribute in Active Directory. I created two new employees in AD who are members of the IT department and gave them organization management rights.
Before starting a new rule configuration, I remove the rule based on the IP subnet using the following cmdlet:
Remove-ClientAccessRule
Now I can create a new rule that checks the value of the Department AD attribute. If the value is different from “IT”, access is 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’s time to test the new rule. I will be using a newly created account by Jon Snow to access EAC (Jon is a member of the IT team). For this purpose I run this cmdlet:
If no results are returned, it means the user is not subject to client access rules. And that’s correct because I configured a blocking rule. Now let’s 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 the client access rule works correctly after I change the value of the Active Directory attribute by blocking access to ECP.
Here’s what it looks like from the browser (for Jon Snow when he’s in the “HR” department):
And here’s an example for another user, Tyrion Lannister, coming from the “IT” department. As you can see the user has access to ECP:
bottom line
These examples are just a small portion of what you can really get out of Client Access Rules functionality in Exchange 2019. The list of scenarios that you can cover with this feature is almost endless and will definitely help you meet the strict security requirements in your Exchange 2019 environment.
See also:
