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

Add SSO Support for Chrome Browser with ADFS 3

By default, ADFS 3 (Windows Server 2012R2) only supports the seamless Single Sign-on (SSO) that we all expect with Internet Explorer browsers.  Chrome can be enabled though by following these steps:

1.  Login to your on-premises ADFS server and launch PowerShell as administrator.

2.  Run the following command to see the current set of supported browsers:

If you have the default configuration, it will return the following:

3.  Run the following command to add Chrome support to the list:

4.  Confirm your change running the same get command from step 2.  You should have the following output:

5.  Restart the ADFS service to apply changes:

All done!

Create Exchange Online IP Blacklist

You may have gotten the hint over the last few posts that I had some brute force issues from a particular set of IPs (a couple /24’s to be exact).  Well after much heartache I found the solution.  Thinking about it now this is probably a pretty common on-prem Exchange configuration option, but alas I have very little Exchange experience so I’m always just figuring it out as I go.

Start by connecting to Exchange Online:

The cmdlet that we will be working with is the Set-OrganizationConfig cmdlet.  As you can see by going to the Microsoft doc linked, there is a whole lot that you can configure for your tenant with this single cmdlet.  For this particular post though, I just needed to make a blacklist to stop the brute force attempts.  To do so I configured the IPListBlocked option:

If you do not currently have any IPListBlocked, you will not need the “add=” portion, but it doesn’t hurt.  All it does is tell it to append to the current array.  Give it about four hours as the warning you’ll see describes and then you should start seeing the desired result.  As always, review the Microsoft docs for syntax and whatnot before.

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.

Sources:
Connect to Exchange Online

Client Access Rules Information

Client Access Rules Procedures

New-ClientAccessRule Microsoft Doc

Enabling Extranet Lockout in AD FS 3.0

Brute force attacks can be quite the nuisance for users, especially if they manage to start hitting your AD FS portal with authentication attempts.  The Extranet Lockout feature can help alleviate these pains by preventing the users local AD account from being locked out, but it is by no means a complete solution.  Please see this post from TechNet for reference on initial setup, and this post also from TechNet for reference on logging/troubleshooting.  Without further ado, let’s dig in.

So what does the Extranet Lockout feature actually do?  Well, it is quite simple really.  Every time AD FS receives an authentication request it will check that AD users badPwdCount attribute before trying to actually authenticate the users against AD.  If that value is greater than or equal to the threshold you set it will no longer allow any authentication requests through AD FS for that user for X amount of time,which naturally you configure, preventing it from locking out the AD account.  Now just to be clear, this provides zero value if you set the thresholds to higher values than your domain policies.  Seems like common sense I know, but you should see some of the comments on these blog sites.

So let’s get into enabling the feature.  This is not very involved, just note that this must be done on the AD FS server, not the WAP.  Before we get into the PowerShell, let’s define the three settings that we are going to concern ourselves with:

  1. ExtranetLockoutEnabled: Enables or Disables the Extranet Lockout feature.  Pretty straightforward.
  2. ExtranetLockoutThreshold: Defines the maximum number of bad password attempts allowed before lockout takes effect.  Remember, it will be looking at the badPwdCount attribute on the AD user account for this so you will want this to be lower than your domain lockout threshold.
  3. ExtranetObservationWindow: Defines the amount of time AD FS will not attempt to authenticate against AD.  Again, everything works off of AD badPwdCount attribute so you want this to be longer than your domain password attempt count reset threshold.

So now that we know what the settings we are configuring do, let’s configure it!

Great now we have it configured!  Now we have to know how to navigate our way through the logs should it become a persistent issue that we need to troubleshoot.  By default a lot of the logging is not going to be configured yet which brings us to our next section of this post, setting up all of the logging so you can troubleshoot with your new and shiny feature!

First thing we need to do is tell AD FS to log success and failure events to the event log.  You do this by opening up AD FS Management on your AD FS server and opening Federation Service Properties.  Select the Events tab and check the Success audits and Failure audits options.  You don’t need success audits, but I think they’re nice to have.

Next we need to configure the AD FS server to audit properties generated by applications.  You do this with GPO (local or domain, dealers choice), as seen below.

We’re all set for logging now!  But what did that time and effort buy you?  Well really it comes in three forms of Event IDs in the security log of the AD FS server: 403, 411, and 516.

  • Event ID 403: This is most useful for figuring out the User Agent that is making the request.  The User Agent is the application being used so think of things like Chrome, Mozilla, a native phone app, etc.  This will also give you the Client IP, but if you have this behind a WAP as is Microsoft’s recommendation you will only see your WAP’s IP.
  • Event ID 411: These are your failed token validation attempts, aka your failed authentication attempts.  These logs provide the actual Client’s IP which is quite useful when trying to source the device.
  • Event ID 516: These are your Extranet Lockout events, your bread and butter.  This tells you the Bad Password Count AD FS saw, the Last Bad Password Attempt, and the actual Client IP like 411 does.

Now I’ll be frank, Event ID 516 is the one you’ll be looking at the most so I’ll put a screenshot of that one below.

I would like to talk about 516 a little more in depth.  You will notice that all of these errors will have a Activity ID which can be matched to each other.  This will allow you to match them up to aggregate the different information you get from each Event ID.  I bring this up because you will, and I meant to use the word will, come across events where the Activity ID is going to be 00000000-0000-0000-0000-000000000000 as you see above.  After much heartache to figure this out, this means that the request came from a legacy application such as a native phone email application or Thunderbird.  With these you will get TWO IP addresses.  One of these will be a Microsoft IP address and the other will be the IP address where the request came from.  This is significant because the request is actually coming from the Microsoft IP address as Exchange Online processes the credentials and forwards them on to your AD FS server.  I’m sure you’re already seeing how this makes blocking the requests difficult, as you can’t control Microsoft’s perimeter network.  I’ll leave dealing with that for another post.

Error signing into authentication app when activating Office 2016

When users were trying to authenticate through Office 2016 to activate the product, they were receiving the following error message upon being redirected to their AD FS login page while on the internal network.

An error occurred

An error occurred. Contact your administrator for more information.

Error details
Activity ID: 00000000-0000-0000-c32d-00800000005e
Relying party: Microsoft Office 365 Identity Platform
Error time: <Date> <Time>
Cookie: enabled
User agent string: Mozilla/5.0 (Windows NT 6.3;WOW64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/38.0.2125.111 Safari/537.36

I did some Googling and came across this Microsoft Support article which details the following steps.  Note that this pertains to Server 2012 R2 for me.

  1. Login to your AD FS server and open AD FS Management
  2. Select Authentication Policies
  3. Select Edit in the Primary Authentication -> Global Settings section
  4. Check Forms Authentication in the Intranet section and select OK or Apply

Export Licensed Office 365 Users Using PowerShell AzureAD 2.0 Module

I figured it was time to bite the bullet and start converting all of my scripts from using the MSOnline V1 module to the new and shiny AzureAD 2.0 module.  Since I was finding few to no posts on pulling licensed users using the new module out there on the interwebs, I figured I’d share my findings.  You can get the AzureAd module quite easily from the PowerShell gallery by using the command:

Once you have that, you are ready to rock and roll.  The following script will connect to multiple AzureAD tenants, snag all AzureAD users, determine if they have a license assigned to them, and if they do export their UPN to a custom PowerShell object with the property name of Email Address.  I only did this because this is for marketing, and that’s what they wanted (they didn’t want to have to edit the export file at all).  But that’s enough explanation, let’s get to the good stuff.

 

Loosely based off of some of the examples found in this blog post.

Exchange Online Missing Mandatory Parameters: ArchiveGuid

I’ve been working with hybrid Office 365 environments for quite some time now and liked to think that I had come across most of the weird errors, but of course just when you think that there has to be another random msExch attribute to come along and muck things up.  I came across just such a case today, presenting itself with the following error in Office 365:

Exchange: Cannot process command because of one or more missing mandatory parameters: ArchiveGuid.

I did a little digging and came across this blog post that found the msExchRemoteReceipeintType attribute to be the culprit.  I cleared the value, kicked off a full dirsync and wha-lah!  Problem solved.

Export Licensed User Properties from Multiple Azure AD Tenants

This is a pretty easy one, but it is quite useful.  Usually when I have a need to do this I just need to export FirstName, LastName, and UPN but the properties are really plug and play.  Look up the different properties on the Get-MsolUser Microsoft Doc found here.  This may go without saying, but you could always just run this as a one liner after connecting to your tenant if you don’t have a need for exporting multiple tenants.  I use this mostly for internal stuff, so I want all the users that we manage.  Without further ado:

 

Adding Additional Azure AD Domain to AD FS with Azure AD Connect

As time continues to drag on, companies may add domains that they wish to federate with the same tenant.  This such situation happens quite frequently in my business, so I figure it makes good content for a post.  This is going to be a pretty short and quick one, so I am going to assume that your new domain is already added to the O365 tenant and as a UPN suffix in AD.

As you can likely tell by now, I do a lot of work with hybrid environments using Azure AD Connect.  That being said, we’ll start today by opening Azure AD Connect and selecting the “Add an additional Azure AD domain” from the options presented.

The rest is pretty simple.  Throw in your O365 Global Admin creds, then your Domain Admin creds, and select the domain you wish to add.  It’ll take a second and wha-lah you are 50% done.

Now open up your AD FS Management console on your AD FS server.  Expand Trust Relationships, select Relying Party Trusts, right click Microsoft Office 365 Identity Platform, and select Edit Claim Rules.

Under Issuance Transform Rules, select Issue issuerid when it is not a computer account and select the Edit Rule option.

In the Custom rule section you will see something similar to the following:

Find your domain section, and simply follow the convention to add an additional domain (domain3 in the following example):

Click your way out and you are all set!  Do note that if you do not add the domain to the rule as described above, users will receive an error similar to:

AADSTS50107: Requested federation realm object ‘user@domain.com’ does not exist.