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:
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
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.
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
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?
CARs are not targeted for such scenarios, CA policy should do the trick however (configure trusted IPs, then use the location condition). If you are looking for pure Exchange solution, authentication policies are what we currently have (but you cannot use them to block just external access): https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online
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???
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.
Exactly what I was looking for. Thanks for keeping this updated!
If you have ADFS enabled would this still work?
It should. CARs act post-authentication, so they will take action after the token has been received from the AD FS server.
Cool! What is OWA?
outlook web access