Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In part 25 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we took a look at the existing mail flow and the mail flow options we have in an Exchange hybrid deployment.

Let’s get going…

Exchange Hybrid OAuth-based Authentication

So back in our previous article, where we enabled Exchange hybrid, we ended the article with the page shown in Figure 1.

Image
Figure 1: Exchange Hybrid Configuration OAuth configuration option

Those of you who have deployed pre-Exchange 2013 CU6 or Exchange 2010 based hybrids will not have seen this relatively new Exchange hybrid configuration page and may not even know what OAuth authentication is and how it relates to an Exchange hybrid configuration.

First a quick introduction to OAuth authentication. OAuth (Open Authentication) is an open authorization standard, that was born back in November 2006, so it is by no means a new standard. OAuth is used by most of the largest and popular service providers both in the consumer and enterprise space. More specifically service providers like Amazon, Facebook, LinkedIn, Google, Instagram, Foursquare, Twitter, DropBox and PayPal use OAuth and most of them have done so for many years. Yammer which was acquired by Microsoft also used OAuth based authentication and still does today.

As you can see OAuth is the authorization standard and it is therefore a natural move for Microsoft to being utilizing this standard for authorization going forward.

With the previous wave (known as wave 14) of Office 365, which had 2010 based versions of the workloads, when we configured an Exchange hybrid deployment between Exchange Online and an Exchange on-premises environment, we used DAuth, which was an authentication standard developed by Microsoft. Exchange 2010 and Exchange 2013 up to CU5 included will default to using DAuth based hybrid deployments as the authentication mechanism.

With Exchange 2013 SP1, Exchange 2013 introduced support for OAuth and at the time (as I blogged about here), documentation on how to enable OAuth manually was published on Microsoft TechNet.

With Exchange 2013 CU6 and later, we get the OAuth authentication option (Figure 1) when we have configured the Exchange hybrid deployment itself like we did back in part 25.

Although DAuth based authentication is still fully supported and required for pure Exchange and legacy Exchange coexistence scenarios (mixed Exchange 2013/2010 and Exchange 2013/2007 organizations), the OAuth authentication will replace the DAuth based Exchange federation trust configuration process at some time in the future. Said in another way, if you have mixed Exchange 2013/2010 and Exchange 2013/2007 organizations, you can skip configuring OAuth. However, if you plan on using the Exchange In-place and/or in-place eDiscovery features, you should configure OAuth using the manual steps outlined here.

Note:
Once OAuth has been configured the reliance on MFG is removed.

Alright, let’s continue with the configuration. To do so, click on the “Configure” button shown back in Figure 1. This HCW will think for a while and then you are prompted to install the Microsoft Office 365 Support Assistant 3.5 tool as shown in Figure 2.

Image
Figure 2: Installing the Microsoft Office 365 Support Assistant 3.5 tool

Depending on your Internet connection, it may take a minute or so to download the tool from the Azure Storage blob (Figure 3).

Image
Figure 3: Downloading the Microsoft Office 365 Support Assistant 3.5 tool

When downloaded, the OAuth authentication will be configured for our Exchange 2013 on-premises organization as well for our Exchange Online organization.

Image
Figure 4: OAuth authentication being configured

When the OAuth authentication configuration has completed, click “Done”.

Image
Figure 5: OAuth authentication configuration completed

When clicking done, we are (for some strange reason) taken to the “Support Overview” page in the Office 365 Portal and not back to the Exchange Admin Portal.

Image
Figure 6: Office 365 Portal Support Overview page

We have now finished the Exchange hybrid configuration.

Sidebar: Exchange Hybrids with multiple SMTP Domains

Back in wave 14 (Exchange 2010/2010 Online) if we had to configure an Exchange 2010 hybrid deployment in a scenario where our on-premises Exchange organization had multiple SMTP domains (address spaces) that we wanted to federate with Exchange Online, we needed to include all the SMTP domains in the SAN certificate that were used for the federation between the on-premises Exchange environment and Exchange Online. If we only included the “primary” SMTP domain, autodiscover would be in a broken state for external users that had a different primary SMTP address (i.e. “[email protected]”) than for the one included in the certificate (i.e. “clouduser.dk”).

In addition, we had to publish the autodiscover endpoint for each SMTP domain. This is because external users must have an SMTP address (i.e. “[email protected]”) that can be used to lookup autodiscover information (i.e. “autodiscover.office365lab.dk”).

Note:
The SRV based autodiscover redirect method is not supported for federation between an on-premises Exchange environment and Exchange Online. Also, in order to use a CNAME based autodiscover method, you would need to have all domain names present in a SAN certificate.

So at the end of the day, you had to do the following:

  • Include “autodiscover.contoso.com” for each SMTP domain in the SAN certificate
  • Publish ”autodiscover.contoso.com” for each used SMTP domain

There are organizations that use lots of SMTP domains (some are in the hundreds!) and as you can see for these types of organizations this isn’t really a feasible solution.

Now here is the good news! This all changed with Exchange 2013 CU1. With Exchange 2013 CU1, we were provided with the option of adding multiple domains to our Exchange federation/hybrid configuration and we can specify which of these domains should act as the “autodiscover” domain. By doing so we can eliminate the need for both adding “autodiscover.domain.com” for all SMTP domains to a SAN certificate as well as the need for publishing autodiscover for each of these.

Cool stuff eh?

To configure an SMTP domain as the autodiscover domain, you can use the following command:

Set-HybridConfiguration –Domains “domain1.com, domain2.com, domain3.com”, “autod:domain.com”

Below I’ve just two domains and specified one of them to be the autodiscover domain.

Image
Figure 7: Configuring an autodiscover domain

After having run the command, you can run “Get-HybridConfiguration | fl” to see the domains as well as which one is configured as the autodiscover domain.

Image
Figure 8: Autodiscover domain configured

Minor but extremely useful new feature in Exchange 2013 CU1. Oh and by the way, this feature has also been backported to Exchange 2010 SP3 RU1 in case you have to base a hybrid setup on Exchange 2010 hybrid servers.

Remember though that the Autodiscover domain feature is exclusive to Exchange hybrids. It does not apply to Exchange clients (Outlook). So for the clients you still need to use one of the existing approaches available. The available options are: You basically have three options. You can choose to include all the domains in the Exchange (SAN) certificate) and create an autodiscover DNS record for each domain in your public DNS. If you do so though, you wouldn’t really benefit from the autodiscover domain feature in the Exchange hybrid scenarios. Another approach is to use SRV based redirection as explained here. And finally, you could choose to use HTTP to HTTPS redirection to the primary autodiscover domain. Used within the organization.

This concludes part 26 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

If you would like to read the other parts in this article series please go to:

About The Author

Read Next

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top