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

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

Introduction

In part 13 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 talked about how to populate the lab environment with test users and then mailbox enable the test users. Moreover, we created public folders. Lastly, we talked about how you can fill the mailboxes and public folders with test data.

In this part 14, we will continue where we left off in part 13. More specifically, we will move on to talk about the identity models that are available when setting up an Exchange hybrid between an on-premises Exchange organization and Exchange Online. In addition, we will cover the state of nation, when it comes to directory synchronization.

Let’s get going…

Identity Models – The Past and Now

When it comes to the identity models available for users that authenticates to Azure Active Directory in order to access one or more Office 365 services, they have been extended significantly since the first appearance of the new Office 365 back in February, 2013.

Back then, we had cloud identities and federated identities. Cloud identities were simply users created directly in the cloud meaning authentication was happening directly against Azure Active Directory. Federated identities was users that kept authenticating against the on-premises Active Directory in order to access one or more services in Office 365. This was accomplished with the help of AD FS and AD FS Proxy (2.0 at that time) servers and a Directory Synchronization (DirSync) servers or for complex scenarios by using FIM 2010 for the synchronization from on-premises Active Directory Forests to an Office 365 tenant (Azure Active Directory). By using AD FS servers or more specifically WS-Federation (WS-Fed) and WS-Trust protocols, Active Directory Federation Services (ADFS) 2.0 provided claims-based single sign-on (aka identity federation) for the services in the Office 365 service offering. The benefits of using identity federation was to provide the users in the enterprise with a single sign-on (SSO) experience no matter if they were located on an external network or on the internal corporate network.

Note:
Basically, ADFS is a Security Token Service (STS) that is capable of issuing, validating and exchanging security tokens on behalf of the users in the enterprise.

Today, we can still choose between cloud identities and federated identities, but a third model has entered the arena. It’s kind of a mix between the two. That is, we synchronize the user objects from the on-premises Active Directory, but we authenticate directly against Azure Active Directory in order to access a service in Office 365. The interesting thing is you always use the same password as the one associated with your on-premises AD user. The way this works is by synchronizing the password hash (not the password itself) from the on-premises user object to the object in Azure Active Directory. This model has been supported since DirSync version (6385.0012) that was released back in May 2013. Although this third identity model provides users with a single sign-on (or same sign-on as I tend to call it) experience, it’s important to note that the users will always have to provide their password the first time they access an Office 365 service, when they turn on the computer in the morning as this model doesn’t use the credentials that has been used to log on to the client in use. This is also true for domain-joined clients.

In addition to the third identity model, the federated identity model of course supports the latest AD FS version (3.0), which brings a suite of new features, all of which you can find listed here. Another cool thing about AD FS 3.0 is new WAP role that replaces the old AD FS Proxy server role as we know it. As some of you probably are aware, the WAP role doesn’t necessarily need to be dedicated to Azure Active Directory authentication, but can also be used to publish on-premises applications and services accessed over the HTTPS protocol.

Finally, the Azure Active Directory has been extended with what are known as premium Azure Active Directory features, which among other things offer self-service group Management, advanced group reports and alerts, multi-factor authentication, Enterprise SLA of 99.9%, password reset with write-back to on-premises and Azure Active Directory bi-directional synchronization.

Later on in this article series, we will take a closer look at some of the premium features.

State of Directory Synchronization

So until September 16th 2014 (read what happened at that date in a moment), you had two options from Microsoft at your disposal, when it comes configuring directory synchronization from your on-premises Active Directory forest or forests to you multi-tenant tenant in Microsoft Azure. For the majority of scenarios the Azure Active Directory Synchronization tool was sufficient. So unless you had a complex scenario involving synchronizations from multiple on-premises Active Directory forests, this was the tool to use. If you had a need to synchronize from multiple forests to your multi-tenant tenant, you needed to use Forefront Identity Manager 2010 R2 (FIM 2010 R2) and then install and configure the Azure Active Directory connector for FIM 2010 R2 as required. This is true for multi-forest scenarios with a single Exchange forest and multiple account forests and scenarios with multiple Exchange forests.

So this is the situation as it was until September 16th 2014. That date changed things. You see, over the last year or so, the Active Directory team has been busy developing some new and heavily improved tools to replace the tools we have available today.

First, we have the Azure Active Directory Connect Beta tool, which is going to replace the Azure Active Directory Synchronization tool. The AAD Connect wizard beta provides a guided experience for integrating a single Active Directory forest with Windows Azure Active Directory.

Image

Figure 1: The new Microsoft Azure Active Directory Connect tool currently running in beta

Then we have the Active Directory Sync Services (AADSync) tool, which is the new sync engine that was released September 16th, 2014. The idea behind this tool was to make multi-forest and non-AD on-boarding to AAD (Azure Active Directory) and Office 365 easier and more predictive than it currently is today with FIM 2010 R2. On top of that the AADSync tool supports AAD Premium features (such as password-write back) and is a step-up from DirSync for more advanced configurations.

Image
Figure 2: The new Microsoft Azure Active Directory Sync services tool currently running in beta

As you should know by now, a lot of stuff is happening in the directory synchronization tools arena. In this article series, we will use the new Active Directory Sync Services (AADSync) tool to synchronize objects from our single “on-premises” Active Directory to the Azure Active Directory tenant.

This concludes part 14 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:

1 thought on “Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)”

Leave a Comment

Your email address will not be published.

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

Scroll to Top