Site icon Franky's Web

Exchange 2019: Client Access Rules

Frank Zöchling

One of the new Exchange 2019 features are the "Client Access Rules". Client Access Rules can be used to restrict access to Exchange Server based on certain criteria. One use case would be, for example, to allow access to the EAC only from a management network.

Unfortunately, the Client Access Rules are not yet fully implemented in the Exchange 2019 RTM version, currently only RemotePowerShell and ExchangeAdminCenter can be managed with Client Access Rules. POP3, IMAP, ActiveSync, OWA etc. cannot yet be restricted with Client Access Rules. I hope that with the next CUs for Exchange 2019, the Client Access Rules will be expanded so that other protocols can also be managed and access can be controlled more granularly.

Overview of commands

The Client Access Rules cannot be managed via EAC, but only via PowerShell. There are 5 CMDLets for managing the Client Access Rules:

As already mentioned, only RemotePowerShell and ExchangeAdminCenter can currently be managed with Client Access Rules. Attempts to manage other protocols or interfaces fail with Exchange 2019 RTM:

A detailed description of the commands can be found here:

However, not all of the settings described in the articles are available in Exchange 2019 RTM.

How Client Access Rules work

Client Access Rules work in a similar way to Exchange Transport Rules or Firewall Rules. The rule with the highest priority (lowest number) is applied first; once a matching rule has been applied, no further rules are processed.

The priority therefore specifies the order in which the rules are processed; the priority always starts with 1, followed by all other rules (2, 3, 4, etc.). It is not possible to create a rule with priority 1 and a rule with priority 5. In this case, the second rule is automatically assigned priority 2. The situation is similar if a rule is deleted. If the rule with priority 1 is deleted, the remaining rules move up, so the rule with priority 2 becomes priority 1.

Client Access Rules only know two actions: AllowAccess (Allow) or DenyAccess (Deny). The AllowAccess action will not be used often, because all actions that are not denied by rule are allowed by default. As rules cannot be based on each other (deny subnet X, but allow IP on subnet X), AllowAccess is usually only used in the Prio 1 rule (see note).

A few important points:

  1. The Exchange Management Shell uses RemotePowerShell for the connection. So you have to be careful not to lock yourself out here.
  2. For speed reasons, Client Access Rules use a cache. It can therefore take up to 24 hours for the first rule created to take effect. Changes to existing rules or the addition of further rules can take up to one hour.
  3. Middle-tier applications such as "Outlook for iOS and Android" do not connect directly from the end device (Android smartphone, iPhone) to the Exchange server, but use middleware. Access from the client to Exchange therefore goes through another application. This also applies to various web application firewalls (WAF) that work in proxy mode. If the IP address of the proxy/WAF/middleware is blocked with a rule, many users may no longer be able to access Exchange. However, this does not apply to "Microsoft Apps" such as "Outlook for iOS and Android", where middleware is also used, but this is excluded from the Client Access Rules and therefore cannot be blocked (at least not with Client Access Rules, this is possible with Active Sync rules).

Examples of client access rules

Unfortunately, there are not many examples of client access rules at this point, as there are simply not many options at the moment. Client access rules are currently only useful for blocking admin connections from the Internet or other problematic networks (possibly guest WLAN or production networks).

The following rule blocks access to RemotePowerShell and ExchangeAdminCenter for all networks except 192.168.200.0/24:

New-ClientAccessRule -Name "Block EAC and RPS" -AnyOfProtocols ExchangeAdminCenter, RemotePowerShell -Action DenyAccess -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24

The following rule blocks RemotePowerShell and ExchangeAdminCenter only for the network 192.168.200.0/24, but allows all other networks:

New-ClientAccessRule -Name "Block EAC and RPS" -AnyOfProtocols ExchangeAdminCenter, RemotePowerShell -Action DenyAccess -AnyOfClientIPAddressesOrRanges 192.168.200.0/24

The following command changes the networks of an existing rule:

Get-ClientAccessRule "Block EAC and RPS" | Set-ClientAccessRule -AnyOfClientIPAddressesOrRanges 192.168.100.0/24, 192.168.200.0/24

The following command displays all rules including all details:

Get-ClientAccessRule | fl *

Existing rules can be tested with the following command, which simulates a connection of the Administrator user from the IP 192.168.100.10 to the ExchangeAdminCenter:

Test-ClientAccessRule -User administrator@frankysweblab.de -AuthenticationType Basic -RemotePort 443 -Protocol ExchangeAdminCenter -RemoteAddress 192.168.100.10

The following command deletes all rules:

Get-ClientAccessRule | Remove-ClientAccessRule

As soon as the client access rules are fully implemented, I will revise this article and add more examples.

Notes

When creating the rules, you must bear in mind that the first applicable rule is always processed, but no further rules are applied thereafter. Here is an example with two rules, the first prohibits access to EAC for the subnet 192.168.200.0/24, the second rule allows access to EAC from the IP 192.168.200.16:

The test using the CMDLet "Test-ClientAccessRule" now returns both rules as a result for access from the IP 192.168.200.16:

However, only the rule with priority 1 applies here, even if the rule with priority 2 is more specific:

So you have to be careful which rules are arranged how, otherwise you can lock yourself out quite quickly. The priority 1 rule should therefore not be a "DenyAccess" rule, but an "AllowAccess" rule that always allows access from a management network or admin PC.

In this example, you can change the order of the rules so that the PC with the IP 192.168.200.16 always has access to EAC:

Of course, access via RemotePowerShell would be much more important here, as the rules cannot be edited via EAC in the event of an error, but only via RemotePowerShell.

Disaster... Help...!!!

Now it can happen that a small slip-up occurs when creating or changing client access rules. In the Exchange RTM version, it is currently only possible to restrict access to EAC and RemotePowerShell, so as an admin you are at most locking yourself out. Users are not directly affected, so keep calm for now.

So if you have locked yourself out: No problemThe rules are saved in the Active Directory and can also be changed or deleted there.

The ADSI editor can be used to edit rules directly in the AD. The rules are saved in the configuration partition of the AD:

If you now change the IP in the value for "msExchTransportRuleXml", the rule is also changed here directly. The client access rule is saved here in XML format. I have simply changed the IP from 192.168.200.16 to 192.168.200.17, which also has a direct effect on the client access rule:

If you have got completely bogged down, you can also delete all the rules by simply removing the entries:

The Exchange Shell directly reports the current result, the rules are deleted:

Here, however, the cache must be taken into account again. As already mentioned, it can take up to an hour before access is possible again (alternatively, restart the Exchange server).

Exit mobile version