Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online) (Part 3)

by [Published on 11 June 2013 / Last Updated on 11 June 2013]

In this article we will begin deploying the Active Directory Federation Service (ADFS) servers that is required for identity federation with the new Office 365.

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

Introduction

In part 2 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, I provided you with an overview of the on-premises lab environment used for this article series. In addition, we went through the sign-up process for a tenant in the new Office 365 as well as looked at the new Office 365 portal. Finally, we added our on-premises domain to Office 365.

In this part 3, we will continue where we left off in part 2. That is, we will begin deploying the Active Directory Federation Service (ADFS) servers that are required for identity federation with the new Office 365. More specifically, we will deploy and configure two ADFS servers. In order to achieve high availability, the ADFS servers will be configured in an ADFS farm and load balanced using Windows Network Load Balancing (WNLB).

Important:
Before you start deploying and configuring the servers required to achieve rich coexistence between the Exchange on-premise and Exchange Online, you should run the Microsoft Office 365 Deployment Readiness Tool in the respective Active Directory forest. The tool will provide an analysis of the environment in preparation for the actual Office 365 enterprise deployment and it’s important you fix any issues caught by the tool prior to deploying the rich coexistence servers. You can download the tool here.

A Brief Explanation of Office 365 Identity Federation

By using the WS-Federation (WS-Fed) and WS-Trust protocols, Active Directory Federation Services (ADFS) 2.0 provides claims-based single sign-on (aka identity federation) for the services in the Office 365 service offering. The benefits of using identity federation is to provide the users in the enterprise with a single sign-on (SSO) experience no matter if they are located on an external network or on the internal corporate network.

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

Although ADFS can be deployed using stand-alone federation servers, the identity federation service usually consists of two or more ADFS Proxy servers placed in the perimeter network and two or more ADFS servers located on the internal corporate network. The internal ADFS servers are configured in a so called federation server farm, which then again is load balanced using some form of load balancing solution. The ADFS Proxy servers are not configured in a federation server farm per se, but incoming sessions hitting these servers are simply load balanced using WNLB or an external load balancer.

Image
Figure 1: Conceptual diagram of the identity federation authentication flow

The reason why it is recommended to deploy at least two ADFS Proxy and ADFS servers is in order to achieve redundancy. This is critical since an unavailable ADFS infrastructure means users will not be able to access any used services in the new Office 365.

By default, the ADFS configuration is stored in a Windows Internal Database (WID) both when it comes to ADFS Proxy and ADFS servers. If you need more than five federation servers in a farm or need to spread them over multiple locations, it’s possible to store the ADFS configuration in a SQL database, but generally such a configuration should be avoided because of costs as well as complexity.

It is also worth noting that the ADFS Proxy servers can be eliminated in certain scenarios where a TMG array or an UAG farm is located in the perimeter network. Finally, bear in mind that identity federation requires directory synchronization (DirSync) from the on-premise Active Directory forest to the Office 365 tenant, so that a shadow user is created for each on-premise user in the Office 365 tenant.

I will not go much more into the details of identity federation in this article, as the authentication experience will be covered later on in this article series.

Configuring Windows Load Balancing on the ADFS Servers

When configuring rich coexistence between an Exchange on-premise environment and the new Office 365, it’s crucial identity federation works all the time. As already mentioned, if the identity federation service becomes unavailable, it means that the Active Directory users within the enterprise cannot authenticate against an Office 365 service such as Exchange Online. Since the user cannot authenticate he cannot access an Office 365 service, as he does not know the password set for the Office 365 user object itself. Because of this, it’s highly recommended to load balance all ADFS servers as well as ADFS Proxy servers using Windows Network Load Balancing (WNLB), a virtual load balancing appliance or a hardware load balancer solution. Since ADFS does not require layer 7 based session affinity, WNLB is fully supported.

Before we configure ADFS on the two ADFS servers, we’ll configure them in a WNLB. To do so, first install the ”Network Load Balancing” component. This can be done by opening the “Server Manager” and under “Manage”” in the top right corner, selecting ”Add Roles and Features” as shown in Figure 2. On the ”Before you begin” page, click “Next” then select “Role-based or Feature-based installation” and click “Next” again.

Image
Figure 2: Adding the NLB Role

On the “Server Selection” Page, click “Next”.

Image
Figure 3: Server Selection page

Click “Next” on the “Server Roles” page and on the “Features” page, tick “Network Load Balancing” and click “Next” again.

Image
Figure 4: Ticking Network Load Balancing on the features page

On the “Confirmation” page, click “Install”.

Image
Figure 5: Confirmation page

When the component has been installed, click ”Close” to exit the wizard.

Image
Figure 6: NLB component installed

Now launch, in the Server Manager, click ”Tools” and select ”Network Load Balancing Manager” in the drop-down menu.

Image
Figure 7: Launching the Network Load Balancing Manager

In the NLB Manager, select ”Cluster” in the menu and then click ”New”.

Image
Figure 8: NLB Manager

Image
Figure 9: Opening the New NLB Cluster creation wizard

In ”New Cluster: Connect” type the server name of the ADFS server you currently are logged on to then click ”Connect”.

Select the interface name listed and click ”Next”.

Note:
In this article series I’ll configure the Windows NLB in unicast mode which is the reason why I only have one interface connected to the server.

Image
Figure 10: Specifying the name of the first node and the associated interface

On the ”New Cluster: Host Parameters” page, leave the defaults as is and click ”Next”.

Image
Figure 11: Host Parameters page

On the ”New Cluster: Cluster IP Addresses” page, click ”Add”.

Image
Figure 12: Adding a virtual IP address to the NLB cluster

Now enter the IP addresses (virtual IP address) that should accept incoming sessions for the Windows NLB cluster.

When done, click ”OK” and ”Next”.

Image
Figure 13: Specifying the virtual IP address

Image
Figure 14: Virtual IP address

On the ”New Cluster: Cluster Parameters” page, enter the FQDN for the Windows NLB in the ”Full Internet Name” text field and then select the cluster operation mode.

In this article series, we use ”sts.clouduser.dk” as the FQDN and will run the Windows NLB in unicast mode.

Click ”Next”.

Image
Figure 15: Specifying the full internet name and cluster operation mode

On the ”New Cluster: Port Rules” page, leave the defaults so the NLB cluster listens on all ports.

Click ”Finish”.

Image
Figure 16: Port rules

The NLB cluster has now been configured although only with a single node.

Image
Figure 17:
NLB cluster created

In order to add the other ADFS server as a node, right-click on the cluster name and then select ”Add Host To Cluster” in the context menu.

Image
Figure 18: Adding another node to the NLB cluster

On the ”Add Host to Cluster: Connect” page, enter the server name of the other ADFS server and then click ”Connect”. Select the listed interface and click ”Next”.

Image
Figure 19: Specifying the name and interface of the other node

Leave the defaults and click ”Next”.

Image
Figure 20: Host Parameters

Click ”Finish”.

Image
Figure 21: Port rules

After a little while, the other node has been added to the NLB cluster.

Image
Figure 22: NLB cluster now includes two nodes

Okay so although we now have an NLB cluster set with ”sts.clouduser.dk” associated with the specified virtual IP address, there’s no way traffic that hits ”sts.clouduser.dk” can be directed to the NLB cluster since the FQDN doesn’t exist in DNS.

So let’s open the DNS Manager on a domain controller in the Active Directory forest and add a new host record (A-record).

Image
Figure 23:
Creating a DNS record in AD DNS

Name it ”sts” and then enter the VIP address that was set when the NLB cluster was created.

Image
Figure 24: Naming the record and specifying the VIP of the NLB cluster

Important:
In this article series all servers including the ADFS servers are based on virtual machines in a Hyper-V environment. This means that we need to enable spoofing of MAC addresses on the interface for servers participating as nodes in an NLB cluster running in unicast mode. To do so, shut down each node and then open the property page for each respective virtual machine. On the property page, select the virtual network adapter, then check ”Enable spoofing of MAC addresses”.

Image
Figure 25: Enabling spoofing of MAC addresses

Now start each cluster node and then verifiy you can ping ”sts.clouduser.dk” or whatever FQDN you use in your environment.

Image
Figure 26:
Ping the FQDN associated with the NLB Cluster

This concludes part 3 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to the new Office 365 (Exchange Online).

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

The Author — Henrik Walther

Henrik Walther avatar

Henrik Walther is a respected writer with special focus on Microsoft Exchange and Office 365/BPOS (Exchange Online) solutions within the unified communications area. Prior to joining Microsoft, he was an eight year Exchange MVP and back in 2006 he took the Microsoft Certified Master: Exchange certification.

Latest Contributions

Featured Links