New episode!
The Scoop on Loop: The Latest Innovations Directly From Microsoft!
Darrell Webster speaks to Rebecca Keys, a Program Manager from the Microsoft Loop team.
Turn Data Protection into an MRR Growth Engine
Security for your customers, revenue for your MSP practice. Access key insights on how to scale your practice with SkyKick’s new eGuide.
MSP eGuide to Package, Sell and Deliver M365 Security Services
Based on input from our top-performing MSPs, SkyKick prepared the MSP Guide to help you navigate the security landscape.

Active Directory Integration with Office 365: Installation

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.

Installing Active Directory Federation Services 2.0

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:

The name of the domain to be federated is configured and validated in Office 365. This will typically be an organization’s Internet domain name and the domain where email is received. For this example, the domain name is awssol.com.
An IP address that allows external communication with the internal server running AD FS 2.0. This IP must be configured on the firewall and allow TCP/IP port 443 (SSL) traffic.

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.

Logon to a Domain Controller using an account with administrative privileges.
Open Active Directory Users and Computers.
Navigate to a user, right-click and select Properties.
Click the Account tab; in the space next to the User Logon Name, verify the UPN suffix is correct. The UPN suffix will begin with @. Verify all users have the correct UPN configured.

However, much more automated (and convenient) method to verify user account UPN settings in Active Directory is through PowerShell.

Logon to a Domain Controller using an account with admin privileges.
Open an elevated PowerShell window (right-click PowerShell then click Run As Administrator).
Type Import-Module ActiveDirectory and press Enter
Once the AD cmdlets load type CD AD: and press Enter

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”

Type CD “OU= AWSUsers,DC=globomantics,DC=com” If all went well, the PowerShell prompt should now be PS AD:\OU= AWSUsers,DC=globomantics,DC=com>
Now use the Get-ADUser cmdlet to grab all user accounts then pipe the output to Format-List to display a nice pretty list of all their User Principle Names.
Type Get-ADUser -Filter * | Format-List UserPrincipalName

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.

Logon to a server hosting external DNS for the domain to be federated using an account with admin privileges. In this example the DNS Server is hosted on a Windows Server 2008 R2 server.
Open DNS Manager from Administrative Tools.
Expand Forward Lookup Zones, then right-click the domain name to be federated.
Click New Host (A or AAAA).
In the Name field enter sts.
For IP Address enter the externally accessible IP address assigned for Federation Services.

Click Add Host.
Click OK when prompted that the record was added successfully, then click Done.

Now things are heating up! It’s time to download and install Active Directory Federation Services 2.0 from the Microsoft Download Center.

Logon to the Windows Server 2008 R2 server where you’ll be installing AD FS 2.0 using an account with Domain Admin privileges.
Open the page to download Active Directory Federation Services 2.0.
Click Continue in the Quick Details section of the page. You’ll be prompted to register, but this is optional. For this example, select No and then click Continue.
This example uses Windows Server 2008 R2, so download the RTW\W2K8R2\amd64\AdfsSetup.exe file. When prompted click Save and select an easy-to-remember location to store the file.
When the download completes, open Windows Explorer, navigate to the folder where the file is stored, right-click the AdfsSetup.exe file, and click Run As Administrator.
The AD FS 2.0 Setup Wizard will start. Click Next.

Accept the terms of the license agreement by clicking the checkbox and click Next.

Select Federation server then click Next.

The list of required prerequisites which will be installed automatically is displayed. Click Next.

The wizard will work its magic.

A restart is required, so when prompted make sure the Restart now checkbox is selected and then click Finish.

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!