Configuring Exchange Online Client Access Rules

Client Access Rules give you a lot of control over who can access Exchange Online from where.  Microsoft gives a pretty good definition so I’ll just throw that at you because I’m lazy:

Client Access Rules help you control access to your Exchange Online organization based on client properties or client access requests. Client Access Rules are like mail flow rules (also known as transport rules) for client connections to your Exchange Online organization. You can prevent clients from connecting to Exchange Online based on their IP address, authentication type, and user property values, and the protocol, application, service, or resource that they’re using to connect.

The most common use case I have seen for this is restricting access to just the corporate/company networks.  While this is cool, you can also use these rules to not allow specific networks as well should have the need, as well as a bunch of other situations.  Use your imagination, these things are pretty cool.

One thing to note is that these do not help with brute force attacks.  The user first authenticates and then Exchange Online will evaluate the Client Access Rules like an ACL, going down the priority list and stopping when it finds a match.  Anyhow, to get them set up we need to start by connecting to Exchange Online.  Open up an administrative PowerShell session and run the following:

Great, now we’re connected to Exchange Online with PowerShell.  First things first, we need to make sure we can always do that.  You will find this plastered all over the Microsoft documentation and any other guides on the interwebs, make your Priority 1 Client Access Rule preserve your access to Exchange Online with PowerShell.  Do this with the follow line:

Just do it.  You don’t wanna be the guy who has to call Microsoft because you locked yourself out of your Exchange Online tenant.

Now you have a lot of options with where you go from here.  Most examples are going to show you how to deny everything accept for X network, I will show you the opposite.  The following will create a rule that will allow any network except for X networks (replace 10 networks with public ranges, or drop the CIDR notation and do particular IP):

You can test this with the following:

And you can modify by:

Like I said earlier, play with the options/settings and use your imagination.  This configuration option isn’t for every org, but it does have a surprising amount of use cases.

In my next post I’ll describe how to handle brute force attacks from malicious IP ranges hitting your AD FS portal.

Connect to Exchange Online

Client Access Rules Information

Client Access Rules Procedures

New-ClientAccessRule Microsoft Doc