With many businesses edging closer to a decision concerning Office 365 implementation, hybrid deployments often get lost in the conversation. Over the next few months, we'll cover exactly how to construct a hybrid Office 365 and Exchange 2010 deployment -- step by step. The first part of this multi-part series explains the starting point of the coexistence puzzle -- configuring single sign-on. In order to get single sign-on up and running...
however, you must first prepare your Active Directory forest for Active Directory Federation Services. Here's how.
Microsoft Office 365 single sign-on uses Active Directory Federation Service (ADFS) to let users access services in Office 365 using their existing Active Directory corporate credentials (i.e., username and password). The single sign-on setup for an Office 365 hybrid scenario requires ADFS 2.0, so make sure it's installed.
In this single sign-on series, we'll look at how to deploy a federation farm with two ADFS servers. These servers are load-balanced using Microsoft Network Load Balancing (NLB). You can deploy ADFS 2.0 using Windows Internal Database (WID) or a SQL Server database. I recommend using WID unless your SQL backend is clustered. When you set up an AD federation farm, the servers in the farm replicate the ADFS data configuration database across each server in that farm.
The first federation server in the farm is called the primary federation server. This server keeps a read/write copy of the configuration database stored in WID. All other servers added to the farm are referred to as secondary federation servers and only keep read-only copies of the federation database. You should install the ADFS role on existing domain controllers to minimize the number of servers required to help control virtual sprawl.
Note: Make sure that your forest functional level is Windows Server 2003 or higher.
In addition to the two ADFS servers, you must also deploy two federation server proxies. They will also be load-balanced with NLB. Federation server proxies are used to redirect client authentication requests that come from outside your corporate network to the federation server farm.
Because federation server proxies are Internet-facing, they should not be placed on domain controllers. Office 365 is a cloud-based product; therefore, users will authenticate from a wide range of Internet-based IP addresses that use your company’s corporate credentials. In a hybrid Office 365 deployment, these are passed through the federation proxy farm.
Figure 1 depicts the setup we'll create throughout this series.
Figure 1. Here's the architecture we'll create in this Office 365 hybrid setup series.
Make certain that:
- The federation servers farm is set up on Active Directory domain controllers
- The federation server proxies are set up in Workgroup mode.
- The perimeter network servers use their host file to contact the federation farm servers.
Note: In this series, all of my screenshots and examples are based on a lab environment. In a lab environment, the federation servers and federation server proxies share the same subnet. In a production environment, separate the federation proxy servers into their own subnet, which is isolated in the perimeter network.
Preparing Active Directory UPN suffixes
You must also configure certain settings within Active Directory to ensure it works properly with single sign-on. When preparing Active Directory for federation, it's important that the user principal name (UPN) suffix on all user accounts is configured correctly.
Figure 2. The .local namespace is not allowed when configuring Active Directory for single sign-on.
Many companies configure their internal Active Directory DNS namespaces to use internal non-routable namespaces, like Kbomb.local for example (Figure 2). This namespace is incompatible with ADFS. You can't use internal namespaces like .local, .lan or .internal.
Note: If you do use a non-routable UPN suffix, you will receive an error message.
If your domain relies on an internal, non-routable namespace, you can create a UPN suffix in Active Directory Domains and Trusts. To do so, follow these steps:
1. Open Active Directory Domains and Trusts, find the root and click Properties (Figure 3).
Figure 3. Select Properties after clicking Active Directory Domains and Trusts.
2. Add a UPN suffix that matches your public external (Internet-facing) DNS namespace. My external DNS namespace is kbomb.com.au (Figure 4).
Figure 4. Select an alternative UPN suffix.
3. Now configure your UPN suffixes on each user account via Active Directory Users and Computers.
But what if you have to configure the UPN suffix for thousands of users? Luckily there's a tool for that. Download ADModify.NET; it lets administrators make multiple Active Directory changes at once. ADModify.NET also lets administrators roll back changes at a later stage. Make certain to download the latest version.
Figure 5. You can now begin configuring UPN suffixes for Active Directory user accounts.
To perform the bulk UPN suffix change, follow these steps:
Note: If your internal Active Directory DNS namespace already matches your public DNS namespace, you do not need to perform these steps.
1. Launch ADModify.NET and select Modify Attributes (Figure 6).
Figure 6. Modify attributes using the ADModify.NET tool.
2. Select your Active Directory Domain partition from the Domain List, then select a domain controller from the Domain Controller List. Select Users (located next to Show Only) then click the green arrow to connect.
Select the domain root, which in my case is Kbomb. Next, click Add to List, then click OK to enumerate the entire domain (Figure 7).
Figure 7. You can now enumerate your entire domain.
3. After enumerating the domain, click Select All, then Next (Figure 8).
Figure 8. Continue the enumeration process.
4. Select the Account tab. Enter %'sAMAccountName'% in the Legacy Account field, then select your external DNS namespace from the list. Click OK (Figure 9).
Figure 9. Select your external DNS namespace.
Validating your on-premises Active Directory forest configuration
Now that you're familiar with ADFS and have configured your UPN suffixes, you must analyze your Exchange 2010 on-premises environment for the Office 365 hybrid deployment. Fortunately, Microsoft has a tool that does that as well. To begin, download the Microsoft Office 365 Deployment Readiness Tool.
Note: For an overview of the tool as well as system requirements, visit the Office 365 website.
After downloading the tool, open the Office365DeploymentReadinessTool.exe file with administrative rights (right-click Run as administrator) on a computer that is a member of your Active Directory domain. The tool will create the following folder on your system drive: C:\office365reskit.
Now, let the tool analyze your Exchange 2010 on-premises environment. This will take a while (Figure 10).
Figure 10. Allow the Microsoft Office 365 Deployment Readiness Tool to analyze your on-premises Exchange 2010 environment.
After the scan completes, scroll through the report and address any problems identified (Figure 11).
Figure 11. Address any problems the Microsoft Office 365 Readiness Tool identifies before moving forward with your hybrid deployment.
This concludes part one of this four-part series on configuring single sign-on with Office 365. In part two, we examine configuring a new federation farm on your domain controllers.
Dig deeper on Exchange Server Deployment and Migration Advice