When configuring Office 365 for Single Sign On, Active Directory Federated Services 2.0 (AD FS) is the component that’s used to allow Office 365 to authenticate user accounts against your local Active Directory.

In this article, we’ll walk through the installation and configuration of a Highly-Available AD FS environment, then the subsequent publishing via Microsoft Threat Management Gateway 2010 (TMG). In particular we’ll look at how to configure TMG publishing so that pre-authentication and single forms-based login is achieved in an Hybrid configuration, which you’ll see in action in my article Enabling Silent OWA Redirection for Office 365 Hybrid.

Before we begin

First of all, let’s make sure we’ve got the following pre-requisites sorted, in particular:

• The federated domain you are using registered in Office 365. If you have a primary domain used for mail, but use a subdomain for Active Directory User Principal Names, consider registering the root domain in Office 365 (e.g. contoso.com) only, then we’ll add the sub-domain (eg. ad.contoso.com) later on during this process.
• User Principal Names set for all users who’ll use the service using a valid domain name that can be registered in Office 365. If you’re using something like contoso.local for UPNs, then you’ll want to sort this first. The Office 365 Deployment Readiness Tool is invaluable when investigating what you need to fix or update.
• Threat Management Gateway 2010 server/array already in place using pre-authentication. We’re not going to concentrate on the installation and configuration of TMG in this article.
• AD FS 2.0 installation and update files – available here and here
• For our deployment, 2 Windows Servers (preferably 2008 R2) joined to our Active Directory. We’ll be using the Windows Internal Database option for the AD FS 2.0 farm which is suitable for all but the very largest deployments.
• A name to call the AD FS farm. I usually recommend sts.contoso.com. The Federation Service in AD FS is the STS, and when it comes to service names I prefer a description of what the purpose is rather than the product name (e.g. mail.contoso.com rather than exchange.contoso.com, www.contoso.com rather than IIS.contoso.com.. you get the picture)
• SSL Certificate available to install on the server. This should be the same certificate used on the TMG server, and if your TMG fronts other services using the same IP, then it should be named correctly on the certificate. I’ve used either:
  • A Subject Alternative Name (SAN) certificate, containing my sts.contoso.com domain alongside my others for services like exchange (e.g. mail.contoso.com, autodiscover.contoso.com)
  • A wildcard certificate for the domain (e.g. *.contoso.com)
• A service account to use for AD FS. This doesn’t need any special privileges in Active Directory and is used by all AD FS servers within the farm to communicate. For our example, it’s called svc_adfs.
• An internal IP address to use for Windows Network Load Balancing on the AD FS servers.
• Either by-pass of proxy authentication or a direct connection to the MSOL services on port 443. If you’re using a proxy, configure the correct settings and test them in Internet Export, then use the netsh winhttp import proxy source=ie from an elevated command prompt to import them.
• And as always, a test environment to try this out in first is ideal. If you’ve got the resources to setup a test environment, you can use an Office 365 trial with a sub-domain of your primary domain, and then later on register your root/primary domain with your “proper” Office 365 tenant without issues.

Installing the pre-requisites

Before we install and configure AD FS 2.0 itself, we’ll install the following on each of the two servers.

• The .Net Framework 3.5 feature of Windows Server 2008 R2
• Microsoft Online Services Sign-In Assistant
• Microsoft Online Services Module for PowerShell

The module for PowerShell will be used to manage the AD FS trust between the local Active Directory, and Office 365.

After installation, you’ll find the shortcut to the Online Services Module for PowerShell on the desktop:

To test we can successfully connect to the Office 365 service, launch it and type Connect-MSOLService:

You’ should be prompted for your Office 365 administrator credentials, If you can’t connect – it’s time to check outgoing port restrictions or proxy configuration settings.

Once connected, type Get-MSOLUser to ensure you can retrieve users from the service:

AD FS Installation

On each of the AD FS servers destined to become members of the farm, install the following updates:

• Active Directory Federated Services 2.0 core install
• ADFS 2.0 Update Rollup 1 or higher (As of writing, Rollup 2 is available)

First install AD FS 2.0 by launching AdfsSetup.exe:

During the installation process, choose the Federation Server role:

The install should then continue, installing the Web Server and Windows Identity Foundation roles and features. Once complete, uncheck the tick box to launch the AD FS 2.0 management snap-in – we don’t need it yet:

Finally to finish install of AD FS, install the update rollup:

Importing the SSL Certificate

Before we configure AD FS, we’ll ensure the correct certificate is in place on both servers so that during configuration we’re able to select it when prompted. As we’ve got IIS installed, we’ll import the certificate using the IIS Management Console.

Launch the IIS Management Console and click on the server node itself, then double-click on Server Certificates:

Then choose the Import option circled in green to import the certificate:

Configuring the first AD FS server in the farm

Now we’ve got the servers themselves ready with pre-requisites, certificates and of course AD FS itself, it’s time to get on with the business of configuring AD FS. The first server in the AD FS farm will be the Master, and there’s a little more to configure on the first node.

First of all, launch the AD FS 2.0 Management Snap-In from Administrative Tools on the first server:

Then from the management snap-in, click the link AD FS 2.0 Federation Server Configuration Wizard

After the setup wizard launches, choose Create a new Federation Service, then choose New Federation Server Farm:

Then, when prompted to choose a name for the Federation Service, select the correct certificate and enter the name chosen earlier on in pre-requisites. For SAN certificates, you can pick the name from the drop down list and for a wildcard certificate, you’ll have to enter the name yourself:

Next, enter the service account you’ll be using for the AD FS farm:

The configuration process should then begin, installing additional components as necessary and configuring the federation service.

Once complete, your AD FS Management Console should look similar to shown below:

Finally, we’ll perform a couple of tests to ensure things are ticking along smoothly.  First, navigate to https://localhost/FederationMetadata/2007-06/FederationMetadata.xml and check a valid XML-based response is shown:

Then, open up the Windows Event Viewer and navigate to Applications and Services Logs > AD FS 2.0 > Admin:

Then check for event ID 100 which should show the Federation Service started successfully:

Configuring the second (and subsequent) AD FS servers in the farm

On the second server (and subsequent ones after that), launch the AD FS 2.0 Management snap-in, and then click to launch the AD FS 2.0 Federation Server Configuration Wizard just like we did on the first server.

This time, we’ll choose the option Add a federation server to an existing Federation Service:

Enter the service credentials when prompted, then follow the wizard through the process to automatically configure the second server:

After configuration, you’ll be informed that the server is now a member server within the AD FS farm:

To test, follow the same steps as we performed on the first server to check the XML metadata is shown correctly (https://localhost/FederationMetadata/2007-06/FederationMetadata.xml ) and look for Event ID 100 in the AD FS Admin event log.

Configuring Network Load Balancing (NLB)

The Windows Network Load Balancing feature of Windows will be used to allow us to provide the highly available aspect of the AD FS service, providing a single IP address that our TMG infrastructure will connect to.

Before we can configure NLB, ensure you install the Network Load Balancing Feature from Server Manager.

Then on the first node launch Network Load Balancing Manager and right-click on the root node, choosing New Cluster:

Enter the hostname of the first node, then choose Connect, then Next:

In the Host Parameters for the new cluster, enter the NLB cluster IP address:

Then, choose the mode of operation for the NLB cluster:

After completing the wizard, the first node should show correctly, and you can right-click the cluster node and choose Add Host to Cluster:

After adding in the second node, both nodes should show correctly:

To test your NLB configuration make sure you can successfully reach the NLB IP address both from remote hosts within the same subnet, and from other hosts in different subnets and sites, if required.

Configuring the Federation Trust between the AD FS farm and Office 365

Now that we’ve got a working AD FS infrastructure in place, it’s time to configure the relationship between AD FS and Office 365 itself.

To begin, launch the Microsoft Online Services Module for PowerShell that we tested earlier, on the first AD FS server. Use Connect-MSOLService to connect to the Office 365 tenant:

Before we continue you’ll remember in the pre-requisites, I noted that if you’ve got a primary domain (such as contoso.com) but use a sub-domain for your User Principal Names or AD domain, then we should register the primary domain first in Office 365.

We’ll also convert that domain first to federated, then add the sub-domain (e.g. ad.contoso.com) as a federated domain afterwards. That will make it a fair bit easier if you decide, at a later date to start using your primary domain as part of User Principal Names at a later date.

So, we’ll convert our primary domain to a federated domain, configuring Office 365 and AD FS in the process, using the command:

Convert-MSOLDomainToFederated –DomainName <domainname>

Then, if we’ve a sub-domain we need to add for the user principal name, add the sub-domain using the following command:

New-MSOLFederatedDomain –DomainName <sub.domainname>

You can then verify the list of domain names registered, paying attention to the Authentication column, to check they indeed show as Federated:

Configuring Extended Protection for Authentication in preparation for TMG

In preparation for using Threat Management Gateway 2010 to publish AD FS, we’ll disable Extended Protection for Authentication.

To perform this procedure, launch an elevated PowerShell prompt, then run the following commands:

Add-PsSnapIn Microsoft.Adfs.Powershell
Set-ADFSProperties -ExtendedProtectionTokenCheck:None

Then, restart the AD FS Services on each host and run an iisreset on both hosts.

Configuring rules in Threat Management Gateway 2010

There’s a couple of ways to publish AD FS with TMG – the first of which is simple pass-through where typically you would setup forms-based authentication, or avoid TMG altogether and use the AD FS proxy servers.

The second way, which I’m going to show you how to configure here, is to use TMG pre-authentication, using a domain-joined TMG which then uses NTLM authentication to authenticate to the AD FS servers.

The benefit of doing it this way really comes into it’s own in Hybrid deployments, where you will have users continue to sign-in to Outlook Web App at the existing OWA URL. By using the Single-Sign-In features of TMG, we can then ensure that the user only needs to sign-in once for OWA whether it’s on-premise or in the cloud, and existing experience customizing TMG login forms can be re-used.

Whilst I’m not going to run through the basic configuration of TMG itself, the assumptions are as follows:

• We’re currently using a domain-joined TMG to publish Exchange, with a configured and working listener.
• The certificate we’re using for AD FS is suitable to be used on the existing listener – e.g. it’s a SAN cert with the Exchange names and the AD FS domains, or a Wildcard cert.

Before we add the AD FS specific rules, we’ll check that the listener is configured correctly. First, let’s check that SSO is enabled by double-clicking the Listener:

Then verifying on the SSO tab that Single Sign-On is enabled for the domain we’re using for both Exchange and ADFS:

Then we’ll check the correct certificate is selected:

Once the listener is configured, we’re ready to create the two rules we need for both interactive clients (where the client authenticates directly after a redirect, like OWA users) and the rich client (where Office 365 authenticates against ADFS internally, like ActiveSync, Outlook, IMAP and SMTP clients):

AD FS – Interactive Client

Public name	sts.contoso.com
Paths	/adfs/*
Publishing To	NLB of the AD FS server farm
Authentication Delegation	NTLM
Users allowed Access	All Authenticated Users
Application Settings	Use Exchange forms (optional) Log Off URL &wa=wsignout1.0
Link Translation	Disabled
HTTP Policies	Untick Verify Normalization Untick Block High Bit Characters

AD FS – Rich Client

Public name	sts.contoso.com
Paths	/adfs/services/trust/2005/usernamemixed/* /adfs/services/trust/mex/*
Publishing To	NLB of the AD FS server farm
Authentication Delegation	No Delegation but client may authenticate directly
Users allowed Access	All Users
Link Translation	Disabled
HTTP Policies	Untick Verify Normalization Untick Block High Bit Characters

To create each rule, use New > Web Site Publishing Rule

Follow the Web Site publishing wizard for each rule entering information as shown in the lists above. The wizard won’t allow you to enter all details, so after creating the rule, view the rule Properties after creation to ensure the settings are correct, in particular, the Public Name:

Link Translation Settings:

Paths:

Authentication Delegation:

Users:

When checking these values, a point of note is the Paths, Authentication Delegation and Users will be different for either rule.

Finally for each rule, check the HTTP policies by right-clicking the rule and choosing Configure HTTP:

Then make sure under URL Protection, verify normalization and Block high bit characters is unchecked:

Testing the ADFS/TMG configuration

Once this is in place, before we continue to configure DirSync and Exchange Server 2010, we’ll want to test that at a basic level everything works as planned.

First, let’s test the Rich Client rules, using the Remote Connectivity Analyser. At the RCA website, select the Office 365 tab, and choose Microsoft Single Sign-On, then choose Next

We’ll then enter a test account details – note that this doesn’t need to exist as a Microsoft Online Services ID – in fact as DirSync isn’t configured we don’t expect it to:

All things well, you should see the test complete successfully with warnings:

In particular, we’ll expect to (at this point until DirSync is configured and working) get this warning, which we can safely ignore:

After this point, we’ll be happy to see that the Rich Clients – like Outlook and ActiveSync will work fine.

Moving onto the Interactive Client, we’ll test this out by navigating to portal.microsoftonline.com and attempting the standard login process, which should prompt us to login at TMG:

The resulting page should be a TMG login dialogue, which we’ll then attempt to login at:

As there’s no account for this user in Office 365, what we’ll expect to see is after logging in against TMG, we’ll be redirected back to the login page for Office 365:

That’s not what we’ll want to see after we’ve installed and configured DirSync, but for now this is fine. We’re just testing the rule at this point, and we know ADFS should be working from the Remote Connectivity Test we performed in the previous step.

Conclusion

The next steps after configuring your AD FS and TMG vary from organization to organization, and the Exchange Deployment Assistant can help you pick the right way forward.

Typically, for this kind of deployment you’ll be looking at configuring DirSync next (which I’ll cover for completeness in a future article) then moving on to running the Hybrid Deployment Wizard in Exchange Server 2010 to join up your on-premises organization with Exchange Online – this is where an AD FS 2 deployment set up this way may be very useful, as the login experience for users you move to Exchange Online can be near-identical to the on-premise login process.

Thanks to my pal Michel de Rooij for pointing me in the direction of this article, which helped me a little along the way when looking at how to implement this, along with the following articles that are useful when investigating the specifics of what needs to be configured in TMG and AD FS 2:

• How to publish AD FS 2.0 endpoints on to the internet using Microsoft ISA or TMG – Directory Integration Services – Office 365 – Microsoft Office 365 Community
• A federated user is repeatedly prompted for credentials when they connect to the AD FS 2.0 service endpoint during Office 365 sign-in
• C7 Solutions Blog: Publishing ADFS Through ISA or TMG Server

Hope you find this useful,

Steve