For Office 365 customers looking to keep their user authentication mechanism on-premises, whether for security requirements or otherwise, Active Directory Federation Services (AD FS) provides Single Sign-On (SSO) functionality, client access policy control, and web page sign in customization. This guide will provide a fool-proof walkthrough of how to install, configure, and deploy AD FS on Server 2012 R2 for use with Office 365.
Before we begin, let's take a moment and plan our AD FS farm topology. It is recommended practice to deploy AD FS with redundancy/high-availability, as well as a secondary Disaster Recovery site, if possible. Standard AD FS configurations opt for a 1:1 ratio of federation servers to proxy servers. For these reasons, the minimum recommended configuration of servers would be two federation servers and two proxy servers, with each fed/proxy pair hosted on separate physical servers. Below is an example of a high-level topology for a 2 & 2 farm:
Now on to the real fun.
- At least one verified "vanity" domain in your Office 365 tenant
- Active Directory synchronization
- SSL certificate from a trusted Certification Authority
- Internal/external DNS records pointing to your respective federation and proxy servers
- AD FS requirements
- Update server with all required patches
- Install the Microsoft Online Services Sign-In Assistant (SIA)
- Install the Windows Azure Active Directory (WAAD) module for PowerShell
- Enable Group Managed Service Accounts (optional but recommended)
From the Server Manager Dashboard, click 'Add roles and features'.
|2.||Review prerequisites and click Next.|
|3.||Select Role-based or feature-based installation and click Next.|
|4.||Verify the server you will be adding the role to and click Next.|
|5.||Check the box for Active Directory Federation Services and click Next.|
|6.||We don't need to install any features, so click Next.|
|7.||Review the AD FS info and requirements, then click Next.|
|8.||Leave the Restart the destination server automatically if required box unchecked, since AD FS will not require a restart. Verify that the AD FS role is shown, then click Install.|
|9.||Once installation has succeeded, click Configure the federation service on this server.|
|10.||In the AD FS Configuration Wizard, select Create the first federation server in a federation server farm, then click Next.|
|11.||Choose the domain admin account you intend to use to perform the configuration, then click Next.|
|12.||Click Import… to add the SSL certificate you will use for encrypted server authentication.
NOTE: If you have not yet obtained a certificate in the .pfx file format, cancel the configuration wizard and jump to Create a Certificate Request in IIS 8.5.
|13.||Select the certificate and then click Open.|
|14.||Enter the password you created if you previously exported the certificate, then click OK.|
|15.||Review the certificate and federation service names, then enter the display name that will be presented to users on the default AD FS sign in page. To see an example of how this will look, click here. When finished, click Next.
NOTE: Here I've gone with the naming scheme of sts.domain.com, where 'sts' stands for Security Token Service. Another popular option is fs.domain.com, where 'fs' stands for Federation Service.
|16.||Enter the dedicated service account that will be used for each federation server in the farm, then click Next. This account is necessary for the Kerberos authentication protocol to work and to allow pass-through authentication from the proxy server. Use this account only for the purposes of the federation server farm.
NOTE: If you plan to use an existing domain user account, make sure that the password is set to never expire. This action ensures that the service account's function is not interrupted as a result of domain password change requirements.
|17.||Select Create a database on this server using Windows Internal Database, then click Next.
NOTE: The Windows Internal Database (WID) allows a maximum of 10 AD FS servers for the farm (if you have 5 or fewer relying party trusts), and 5 AD FS server if you have more than 5 relying party trusts. If your organization is large and will require more than 10 servers, choose the SQL Server database option. For more information on the differences between WID and SQL, click here.
|18.||Review the configuration options selected, then click Next.|
|19.||Ensure that all pre-checks passed, then click Configure.|
|20.||Once configuration has completed, click Close to exit the wizard.|
To verify operation of the primary AD FS server, we can access the IDP Initiated Sign In page by going to https://sts.domain.com/adfs/ls/idpinitiatedsignon.htm
As you can see, the page will prompt you to sign in using Windows Integrated Authentication (WIA). This is the default sign in method assigned to internal AD FS servers in order to provide SSO functionality. You'll see an example of Forms-Based Authentication (FBA) on the proxy server later on.
- Update server with all required patches
- Import the SSL certificate into the Personal store using the Certificates MMC snap-in
- Credentials of a local administrator account on the internal federation servers
- Unfettered Internet access
At this point we can verify the proxy configuration by going to https://sts.domain.com/adfs/ls/idpinitiatedsignon.htm
Notice that the sign in page reflects Forms-Based Authentication, and provides fields for users' UPN and password.
It's now time to federate your domain environment with the Microsoft Office 365 Identity Platform. After this step is complete, all Office 365 authentication requests will redirect to on-premises AD FS.
To start, return to the primary federation server where the Azure AD PowerShell module is installed. You can optionally perform this process from your local workstation by running Set-MsolAdfscontext -Computer "NetBIOS Name of primary federation server".
1. Open the Windows Azure Active Directory Module for Windows PowerShell with elevated administrator permissions. (There should be a shortcut on the desktop)
2. Run the following command to store your Office 365 global admin credentials.
$cred = Get-Credential
3. Connect to Office 365
Connect-MsolService -Credential $cred
4. Establish the Relying Party Trust with Office 365 by converting the domain from Managed to Federated.
Convert-MsolDomainToFederated -DomainName treybyday.com
NOTE: If you plan to federate more than one top-level domain now or in the future, append the -SupportMultipleDomain parameter to the end of this command.
Here is an example of how the commands will look in PowerShell:
You can test authentication by going to https://login.microsoftonline.com and entering a User Principal Name (UPN) with the now-federated domain suffix, e.g. email@example.com. A useful shortcut for accessing Outlook Web App (OWA) which bypasses the Office 365 sign in page is https://outlook.com/treybyday.com.