Client Access Rules for Exchange Online

The wait is over – one of the most requested features has finally hit my tenant. Namely, Client Access Rules, or the functionality that allows us to control access to Exchange Online based on location, protocol and authentication type.

Sadly I still don’t have CARs across all my tenants, but it’s enough to give the feature a quick test. Let’s go.

First of all, managing of Client Access Rules is all done via PowerShell. This in turn means you need to be very careful not to block PowerShell access, or you will be forced to place an awkward support call I would strongly advise you to review the documentation before creating any Client Access Rule!

Assuming you’ve familiarized yourself with the process, you can fire up a connection to Exchange Online PowerShell and create your first CAR. The example I used was to block access to OWA externally – something that was not possible until now, even in federated scenarios, unless you were willing to sacrifice some other functionalities, or to use Azure AD Conditional access. Here’s how the rule looks like:

Once you have created the rule, you will have to wait for a while for it to take effect. Both the documentation and the actual PowerShell cmdlet will warn you about this, however in my case the rule started working almost immediately. Here’s how the experience looked like for any external attempt to open OWA:

The message shown above can use some improvements, but it should give the user and admin enough information to understand what the cause is. Now, because I’ve only blocked external access to OWA (in other words I used an exception in the CAR above), I can work with it just fine when I’m using an “internal” device.

The Test-ClientAccessRule cmdlet can be used to verify that the rule you created works as expected. Here’s an example:

Another important thing to note is that while multiple rules can exist in the tenant, rule processing stops once a match occurs. That means that you need to carefully manage the rule priority in order to make sure the set of rules you have created will have the desired effect, and the Test-ClientAccessRule cmdlet proves invaluable here. Make sure to set the allow rules with higher priority and also add exceptions as necessary!

Other examples of things you can do with Client Access Rules include:

• Blocking access to protocols such as IMAP or POP
• Blocking access based on the IP address of the client
• Blocking access based on authentication type – yes, you can block Basic auth!
• Blocking access based on group membership
• Blocking access based on recipient filter – for example all users in the HR department
• Adding Exceptions for all the above (except the filter one)

For additional examples, refer to the cmdlet help here: https://technet.microsoft.com/EN-US/library/f397cd16-dcd7-4929-8c9f-35415ca6b009(EXCHG.160).aspx

UPDATE: 02/02/2018
Not all protocols and authentication types can currently be blocked. The documentation has been updated to reflect on this, consult the table here: https://technet.microsoft.com/en-us/library/mt842508(v=exchg.150).aspx