Geek of All Trades: Office 365 SSO: A Simplified Installation Guide
Installing, configuring and activating single sign-on within Office 365 is a lengthy but worthwhile process.
Greg Shields
Office 365 could be your best friend. You can offload a vast array of complex administration responsibilities. Sign a single monthly contract, and much of the pain of managing Exchange, SharePoint and Lync automatically becomes somebody else’s job.
Many Office 365 fans get stymied, however, when they want to implement its single sign-on (SSO) capability. You could download the Microsoft Online Services Sign-In Assistant (MOS SIA) to streamline authentication for client apps, but it isn’t true SSO. It merely combines the two passwords each user needs: one for Active Directory and another for Office 365.
Consolidating those two passwords into one requires implementing Active Directory Federation Services (ADFS), which can seem abnormally complex. Take a peek at the Microsoft online documentation for doing so, and you can quickly get mired in its details. In this case, Microsoft has provided almost too much information. As a result, Office 365 SSO with ADFS might seem like more trouble than it’s worth—but it isn’t.
If you’re among the ranks of the confused when it comes to enabling Office 365 SSO, consider this your simplified installation guide. It won’t address every situation, but it’s a start for low-complexity, small to midsize business (SMB) environments.
Step 1. Prepare Your Active Directory Domain
Office 365 SSO requires an Internet-resolvable domain name to use as the suffix in each user’s username. Don’t worry, though, if your Active Directory domain name doesn’t meet this requirement. Most of them don’t. You can make things work by giving users an alternate User Principal Name (UPN) that matches any public domain name you own.
Let’s assume your public domain name is contoso.com, but your inside-the-firewall Active Directory domain is contoso.local. You can’t resolve contoso.local via Internet servers, therefore you won’t be able to with Office 365 DNS servers. That said, you can use federation to set each user’s UPN to a publicly resolvable domain name and let them log in as username@contoso.com.
While each user’s UPN might look like an e-mail address, it has nothing to do with SMTP or Session Initiation Protocol. This change merely maps your users’ Active Directory accounts with an external address that Office 365 can understand.
Launch Active Directory Domains and Trusts and view the Properties of its top-level node. In the box titled Alternative UPN suffixes, enter your publicly resolvable domain name and click Add. Then launch Active Directory Users and Computers and view the Properties of a user account. Under its Account tab, you can now set the User logon name to that publicly resolvable domain name. Do this for each Office 365-enabled user. They’ll be using this as their Office 365 username in a minute.
Step 2. Prepare Your Server and Install ADFS
You can install ADFS on a domain controller or another server. You’ll first need to configure a few prerequisites. The following steps assume you’re installing to Windows Server 2008 R2.
Using Server Manager, install the IIS role and the Microsoft .NET Framework 3.5.1. Then purchase and install a server-authentication certificate from a public certificate authority. Make sure you match the certificate’s subject name with the Fully Qualified Domain Name of the server. Launch IIS Manager and import that certificate to the default Web site.
Next, download ADFS 2.0. Accept the installation defaults, selecting Federation server when prompted. The installer should automatically install any required hotfixes, although you might need to install ADFS 2.0 Update Rollup 2.
After installing and patching ADFS, launch ADFS 2.0 Management from Administrative Tools. On the Overview page, start the ADFS Federation Server Configuration Wizard. Create a new Federation Service in a Stand-Alone deployment, and verify the SSL certificate it’s using matches the one you’ve imported into the IIS default Web site. The wizard will also prompt for a service account. Supply it with an Active Directory account whose password is set to never expire.
When the wizard concludes, you’ll see a message noting that the Required configuration is incomplete and you need to add a trusted relying party. You’ll do this in a minute, so you can safely ignore this message.
Test your installation by navigating to https://<serverFQDN>/FederationMetadata/2007-06/FederationMetadata.xml in your Web browser. Click through any certificate errors you see. You’re verifying that IIS is successfully serving up XML content.
Step 3. Add Your UPN Domain to Office 365
The earlier example used a publicly resolvable domain name of contoso.com with an internal Active Directory domain of contoso.local. Yours can be anything. The Active Directory name doesn’t need to align with the external domain you use for e-mail addresses, although doing so makes things easier for users to remember.
If the publicly resolvable domain name you choose isn’t already linked to Office 365, do so via the Microsoft Online Services Portal. Click Domains in the Admin console and then select Add a domain. The wizard will prompt you for the domain name, and then give you one of two options for authenticating ownership. You’ll need to add either a TXT or MX record to the publicly accessible DNS server hosting the domain.
It can take anywhere from 15 minutes to 72 hours for the update to fully propagate, so it might take a while before you can complete the validation process. Validation affirms to Office 365 that you own the domain name your clients will later use to authenticate. You don’t need to have any servers within this domain for federation to function. All you need to complete this step is the domain itself that you can resolve from the Internet.
Step 4. Connect ADFS with Office 365
The next step is to let Office 365 know you intend to federate user authentication. This process entrusts your internal Active Directory domain with authenticating users, while letting Office 365 merely trust your domain’s authentication response. That’s the magic of federation—no passwords are ever transferred between ADFS and Office 365.
Connecting these two requires invoking a few Windows PowerShell commands. These in turn require installing the Microsoft Online Services Module and creating a connection to Office 365. The steps to accomplish this are detailed in an earlier column, “Manage Office 365 with Windows PowerShell.” With that connection established, run these two Windows PowerShell commands. The first creates a context that connects you to ADFS. The second converts the domain from standard authentication to SSO:
Set-MsolAdfscontext -Computer <AD FS server FQDN>
Convert-MsolDomainToFederated -DomainName <domain name>
As a function of its activities, your ADFS server will automatically and regularly generate, use and later expire self-signed token-signing certificates. Office 365 needs to know when those certificates change. Synchronize their activities by downloading the Microsoft Office 365 Federation Metadata Update Automation Installation Tool. This tool arrives as a Windows PowerShell script you’ll execute on your ADFS server. Run the script and provide its requested Active Directory and Office 365 administrative credentials to install synchronization.
Step 5. Synchronize Active Directory User Account Information to Office 365
While federation eliminates the need to send passwords between Active Directory and Office 365, it still requires synchronizing the user accounts of each. You can perform this synchronization manually, adding Office 365 users that match each Active Directory user account.
You can also automate the process with the Microsoft Directory Synchronization Tool. This tool automatically replicates certain Active Directory user account information—including phone numbers, addresses and data usually found in an Exchange Global Address List—to Office 365 accounts. Unlike ADFS, though, you can’t install the Directory Synchronization Tool on a DC, nor can you install it to your ADFS server.
You must first activate synchronization with an entirely separate tool: the Microsoft Office 365 Deployment Readiness Tool. Launch this tool and navigate to Admin | Users | Active Directory synchronization. On the Set up and manage Active Directory synchronization page, click Activate under Activate Active Directory synchronization.
Next, you’ll install and configure the Directory Synchronization Tool. Choose Start Configuration Wizard now after the installation completes. You’ll be asked to supply Microsoft Online Services credentials and Active Directory credentials for a user account with Enterprise Admin privileges. Choose to synchronize directories now in the wizard’s final page to begin synchronization.
Directory synchronization happens by default every three hours, although you can force a synchronization by rerunning the wizard, entering credentials and again selecting Synchronize directories now in the wizard’s final page. The tool also delivers a Windows PowerShell cmdlet, Start-OnlineCoexistenceSync, to accomplish the same function.
Step 6. Adjust Internet Explorer Settings
Office 365 provides services across a range of interfaces, both Web- and rich-client-based. One lesser-known trick you can use to further streamline the SSO experience is to add the ADFS server’s Federation Service URL (typically https://<AD FS server fqdn>) to the Internet Explorer Local intranet zone on each client machine. Group Policy is useful in provisioning this setting to multiple machines at once.
Step 7. Enable Users, Validate Synchronization and Verify Federation
Without additional configuration, the Directory Synchronization Tool will replicate all user account information to Office 365. You need to assign Office 365 licenses to user accounts if they’re to use its services. This extra step is good, because it gives you the power to assign usage licenses as appropriate.
You’ll also want to validate directory synchronization and test the SSO experience. To validate synchronization, just log on to the Microsoft Online Services Portal and peek through a few user accounts to see if their information has been updated. Verifying federation is even easier. Microsoft has set up a Web site that can automatically verify whether or not federation is correctly configured, and can provide suggestions when problems occur.
Sometimes authentication problems aren’t easy to track down, particularly when you’re working across disparate systems. If you’re completely stuck, Microsoft has written an excellent troubleshooting guide that can help you out with a range of problem situations.
Office 365 SSO, the Simplified Way
Even these instructions for implementing Office 365 SSO are a bit wordy. The process isn’t trivial, but neither is it as complicated as Microsoft documentation suggests. Having said that, the company’s documentation is comprehensive where this guide isn’t.
ADFS supports additional functionality not mentioned here. There are features like SSO for Internet-based clients. You can support these by implementing an ADFS proxy in your network perimeter. You can also cluster multiple ADFS servers together if high availability is a design goal. There are various other customizations also possible to synchronize users and streamline the user experience. Check out all the details on these and other Office 365 SSO architectures.
.jpg "Greg Shields")
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.