How to block external access to Exchange admin center in Exchange 2019 via Client Access Rules?

[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 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.
  • Ranges of IP addresses, e.g. –
  • 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. (the last option seems to be reserved for Exchange Online, for the moment). 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, 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, run the cmdlet like this:

New-ClientAccessRule -Name „Allow ECP only for VLAN MGMT” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges -Priority 2

Block access for all users with an exception

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:


Check a list of Client Access Rules
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, If the rule works correctly, you should see something similar to:

Check if the rule works properly

To test the rule, you can also run abovementioned cmdlet Test-ClientAccessRule. This will simulate the connection e.g. from IP address to EAC for the Administrator user:

Check if the rule works properly

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

[Important] At the time of writing this article, this method worked flawlessly. However, when recently testing it, it turned out 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 doesn’t return errors. However, access isn’t blocked afterwards. Running this cmdlet in Exchange Online works without any issues.

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.

Department attribute in AD

Before I start a new rule configuration, I remove the rule based on the IP subnet by using the following cmdlet:


Remove client access rule
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

New client access rule
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:

Test client access rule.

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”.

AD properties of a user.

To check the results of the rule, I use the same cmdlet as for the example above:

Test the results of client access rule.

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):

A notification about blocked access to EAC.

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:

Access to EAC

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.

See also:

CodeTwo Products

12 thoughts on “How to block external access to Exchange admin center in Exchange 2019 via Client Access Rules?

  1. Thank you for the information. I would like to know can we check the list of the blocked IP address when it comes to access Exchange.

    • The cmdlet:
      Get-ClientAccessRule | FL Name,Action,AnyOfClientIPAddressesOrRanges,ExceptAnyOfAuthenticationTypes
      Should return all relevant information.

    • Hi,
      After testing, it seems that Exchange 2019 does accept the -UserRecipientFilter but such a rule doesn’t really work. I’m sorry for the mixup, I’ll edit the article as soon as I’m able.

  2. Hi, can this the parameter “UserRecipientFilter ” be used in Exchange 2019? From here(, i find that this parameter only be used in Exchange Online.

    • I’m positive I’ve tested it before and it worked in Exchange 2019, as well. I’ve just checked it in a test Exchange 2019 environment and PowerShell does accept the UserRecipientFilter attribute with a proper value. I’ll let you know if it actually works as expected after the Client Access rule kicks in (the first Client Access rule takes up to 24 hours to start working).

  3. Hi, does this also work for Outlook Anywhere? We have Exchange 2013 now but if this can also control Outlook Anywhere, this would be a compelling upgrade.

    We deploy active sync to mobile devices using MDM. What we don’t want is an end user with their personal device configuring outlook to download corporate data to an unmanaged system. It’s easy to do and even if activesync and owa are disabled for the account, Outlook anywhere and autodiscover makes it all too easy to setup any outlook to any company email account, provided you know the username and password.

    • Hi Kjstech,
      Yes, Client Access Rules support Outlook Anywhere. The complete list of protocols it can handle is as follows:
      • ExchangeAdminCenter
      • ExchangeWebServices
      • IMAP4
      • OfflineAddressBook
      • OutlookAnywhere (includes MAPI over HTTP)
      • OutlookWebApp (Outlook on the web)
      • POP3
      • PowerShellWebServices
      • RemotePowerShell
      • REST
      So for the rule to apply to Outlook Anywhere, you would simply need to add -AnyOfProtocols OutlookAnywhere not specifying the AnyofProtocols attribute would also make the rule apply to Outlook Anywhere (and all the other protocols listed).

  4. thanks for the excellent story,

    I have a question, is it possible to use more than one access rule to have more specific control?
    For example, I want access to be restricted to my organization’s IP only but I need IT staff to have external access. I created this two rules but apparently didn´t work

    New-ClientAccessRule -Name “Acesso Departamento” -Action AllowAccess -AnyOfProtocols ExchangeAdminCenter -UserRecipientFilter {Department -eq “IT”} -Priority 2
    New-ClientAccessRule -Name “Acesso IP” -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges -Priority 3

    • Hi Diego,
      It is one of the most basic setups and it should work without problems. One of the first pieces of information shared on the subject of Client Access Rules by Microsoft is that you should start with setting up a safety rule not to lock your admins out. How does this setup work? Anyone can access PowerShell regardless of IP, IT can only connect from a set of IPs?
      Another thing to keep in mind is that Client Access Rules need some time to propagate through your tenant.

    • Unfortunately, Client Access Rules have been introduced in Exchange 2019, so the steps from this article will not work for the previous Exchange Server releases.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>