Deploy AD FS on Windows Server 2012 R2 with Office 365
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.
Contents
2. Install and configure the primary federation server
3. Install and configure the federation proxy server
4. Establish the Relying Party Trust
1. Requirements
- 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
2. Install and configure the primary federation server
Prerequisites
- 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)
1. | 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.
3. Install and configure the federation proxy server
Prerequisites
- 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.
4. Establish the Relying Party Trust
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.comNOTE: 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. trey@treybyday.com. A useful shortcut for accessing Outlook Web App (OWA) which bypasses the Office 365 sign in page is https://outlook.com/treybyday.com.
5. Supplemental
Create a Certificate Request in IIS 8.5
6. Resources
Verify and manage single sign-on with AD FS
Methods to attain SSO behavior
Customizing the AD FS Sign-in Pages
Customizing the AD FS URL using SmartLinks
Configuring Client Access Policies
HowTo: Install the Windows Azure Active Directory Sync Tool
Deployment Scenarios for Office 365 single sign-on and Windows Azure
Microsoft Remote Connectivity Analyzer
patches
Comments
- Anonymous
January 01, 2003
Very nice. Thanks. - Anonymous
January 01, 2003
@Jim Mulvey: Yes, only needed for the cert. - Anonymous
January 01, 2003
@Simon Earl, The screenshot I'll admit is a little misleading. All that's required is the presence of a local administrator account on the internal federation servers. This can be the same as the service account, or a separate account. For consistency I would suggest simply adding the service account as a local admin on each federation server so that you're establishing the trust with the proxies using the same account for each server in the farm. And make sure Interactive Logon is enabled for the account, otherwise it won't work. - Anonymous
April 08, 2014
Thats a nice blog with a lot of information on it. I like it very much - Anonymous
May 02, 2014
Very well written! Clear and concise instructions and resources. The graphics are relevant and broken down step by step. This will prove to be an excellent resource for those deploying ADFS on Windows Server 2012 with O365. Thanks! - Anonymous
July 21, 2014
Disseminating this to spread the wisdom! This is an excellent resource, thanks so much! - Anonymous
July 25, 2014
Very well done. This will be huge for helping customers - Anonymous
August 25, 2014
The comment has been removed - Anonymous
September 04, 2014
Is the only purpose of installing IIS to get the certificate request? - Anonymous
November 09, 2014
Very thorough; well done. Thanks... - Anonymous
March 22, 2015
I'm still confused as to why you need a Local Administrator account....how is PROXY1Administrator going to authenticate to Proxy2 ?
Otherwise...thanks for the info.... - Anonymous
October 26, 2015
The comment has been removed - Anonymous
October 26, 2015
Ahmad, you need to use Office 365 global admin credentials for Convert-MsolDomainToFederated - Anonymous
October 04, 2016
Very interesting and nice article which helped me lot in ADFS configuration can please provide me the step by step installation & configuration for ADFS SmartLink"Customizing the AD FS URL using SmartLinks"Email id: gnnaik@outlook.comThank You