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:

New-ClientAccessRule -Name "BlockOWAExternal" -AnyOfProtocols OutlookWebApp -ExceptAnyOfClientIPAddressesOrRanges 11.22.44.55-Action DenyAccess

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:

Error message when blocked by client access rules

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:

Test-ClientAccessRule -User gosho@sts.michev.info -AuthenticationType BasicAuthentication -Protocol OutlookWebApp -RemoteAddress 172.17.17.26 -RemotePort 443

Identity         Name             Action
--------         ----             ------
BlockOWAExternal BlockOWAExternal DenyAccess

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

11 thoughts on “Client Access Rules for Exchange Online

  1. Brandon says:

    No one is explicitly saying so, but as far as I can tell, the behavior of CARs is ‘default allow’. In other words, if a client matches none of the client access rules, then the client is presumed to be allowed access. However, it would be nice if Microsoft could be bothered to explicitly state this.

    Reply
  2. Nyear says:

    Hi

    By CA; do you mean “Azure Conditional Access”?

    If so; it has a HUUUUUGE flaw when it comes to blocking basic authentication. Truth of the matter is that legacy clients such as “outlook 2010” are NOT IP aware. So when you go ahead and use conditional access to do the job; you will also brick access for your internal outlook 2010/2013 clients.!!!!!

    Thank you

    Reply
  3. Nyer says:

    OK. Thanks

    I have discovered that I cannot block “basic authentication” from outside ONLY using Azure conditional access. When I try to do the same thing with client access rules that you mentioned above; I get a message that says “Chosen authentication type and protocol combination is invalid”.

    How can you use client access rules to block “basic authentication” externally ONLY?

    Reply
  4. NYer says:

    Hi

    There is no mention of “groups” on official documentation. But you did write that it is possible to block based on group membership. How???

    Reply
    1. Vasil Michev says:

      If you check the client rule properties, you will find the following:

      UserIsMemberOf : {}
      ExceptUserIsMemberOf : {}

      So it does seem to be supported, however we still don’t have access to the corresponding parameters when creating/modifying CARs.

      Reply
  5. No Need says:

    Exactly what I was looking for. Thanks for keeping this updated!

    Reply
    1. Vasil Michev says:

      It should. CARs act post-authentication, so they will take action after the token has been received from the AD FS server.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.