In 2010, Microsoft CEO Steve Ballmer famously staked out the company’s cloud position years ago when he stated “for the cloud we’re all in.” To this end Microsoft continues to grow their cloud offerings with products such as Windows Server 2012, SQL Azure, and Office 365. And as time goes on, more organizations are integrating these solutions into their IT strategy. Because of the sheer amount of functionality provided, Office 365 has become one of Microsoft’s hottest cloud products.
There is, however, still the challenge of implementing it. Few, if any, organizations with existing Active Directory (AD) infrastructures will dump everything and move entirely to the cloud overnight. The reality is that organizations need a solution that integrates their existing Active Directory infrastructure with Office 365, allowing them to leverage Office 365 features such as Exchange Online while still managing their AD users, groups, etc., in-house. Don’t fret! Microsoft has provided the tools required to do exactly that.
This is a three-part series. In this first article I’ll walk you through downloading and installing Active Directory Federation Services 2.0. In part two, we’ll complete federation and get everything ready for Single Sign-On. And in part three, I’ll show you how to activate local Active Directory synchronization with Office 365.
Beyond just managing users locally, enterprises want users to have a seamless experience. Key to this is providing a system that allows the user to authenticate once against the local AD and then have that authentication carry over to their Office 365 services. This is known as Single Sign-on (SSO), and it is an important part of most local Active Directory-to-Office 365 integrations.
The first step in integrating local Active Directory with hosted Office 365 services is to install and configure Active Directory Federation Services 2.0. Federating directories simply means connecting them so that they can share and trust information from one another. This creates the ability for a user to authenticate against the local AD and have Office 365 honor that authentication. The remainder of this article will focus on getting AD FS 2.0 up and running.
Implementing AD FS 2.0 correctly requires heeding Alexander Graham Bell’s advice: “Before anything else, preparation is the key to success.” Prepare by collecting and verifying the following information:
Now let’s get to work! We’ll begin by verifying that the Active Directory users all have a User Principal Name (UPN) that matches the domain to be federated. In typical scenarios, an easy rule of thumb is to use the email address for the UPN. There are two methods verify the user account UPN settings. The first is through the GUI.
However, much more automated (and convenient) method to verify user account UPN settings in Active Directory is through PowerShell.
For the next step you need the Distinguished Name of the container holding the user accounts. For this example, the accounts are in the globomantics.com domain and housed in the AWSUsers Organizational Unit. Therefore the DN is as follows: “OU=AWSUsers,DC=awssol,DC=com”
Now that all user account UPN’s are confirmed correct, the next step is to create a Security Token Service (STS) DNS record for Active Directory Federation Services.
Now things are heating up! It’s time to download and install Active Directory Federation Services 2.0 from the Microsoft Download Center.
Great! The first steps necessary to achieve single sign-on and integrate local Active Directory accounts with Office 365 cloud-based services are complete. The next article in this series will focus on configuring AD FS 2.0 and getting it all dialed in. Keep an eye out and in the meantime be sure to check out some of the other great articles in the Petri Online Knowledgebase!