Creating Custom Address Lists with Exchange Online

Holy cow it has been a while since I made a post on here!  Things have been crazy.  Anywho, let’s talk address lists.  So typically when users ask for “folders” in the global address list (GAL), even with Exchange Online, the first thing my brain goes to is public folders (PF).  Now I got thinking, that’s kind of the old school way of doing things, and a particular customer of mine was really not into that idea.  Therefore I did some research came up with a solution using custom address lists!

So custom address lists are just like any of the other predefined address lists that you are used to seeing like the GAL, All Contacts, etc.  They show up as their own separate address list under All address lists, or under the Directory option if you’re using Outlook web app (OWA).  The cool thing is you can set filters on what show up in these address lists based on what’s in your GAL.  For example, if you want just contacts from the state of Arizona to show up in a custom address list you name Arizona Contacts you can totally make that happen.  Better yet, it’ll maintain itself!!!  Follow this link for more information, we’re going to move on to the good stuff.  Since there is no UI option to do this, it must be done using PowerShell as of the time of writing this.

Creating a Custom Address List in Exchange Online

To begin, you must login to Exchange Online and ensure that you have the admin role Address Lists assigned to you.  This admin role is not assigned by default, so you may want to make your own role group and with just the Address Lists role assigned to it and add your members.

Once you have the permissions all sorted out (they can take a while to apply, heads up), start by logging into Exchange Online with PowerShell.

Now that you’re connected, creating a custom address list is a simple one liner.  We’ll run with the contacts from Arizona example I mentioned in the intro.  See the reference material links at the end of this post for more information on how you can filter.

You would think you were done right?  WRONG!  Custom address lists have what I would consider a bug, and Microsoft considers acceptable behavior.  YOu have to follow the steps in this article for the address list to start functioning correctly.

From what I can make of this, there is some sort of modified attribute for each object on the backend that we don’t see and the address lists need that to be more recent than the creation date of the address list.  That is just a guess, don’t hold me to it!

With that you are all done.  Moving forward as you add contacts from Arizona, they will automatically be added to your address list.  Pretty cool!


Reference Material:

Manage Address ListsNew-AddressListSet-AddressListFilterable Properties, Get-Recipient

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