Freigeben über

Deploy AD FS on Windows Server 2012 R2 with Office 365

  • Artikel

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

1. Requirements

2. Install and configure the primary federation server

3. Install and configure the federation proxy server

4. Establish the Relying Party Trust

5. Supplemental

6. Resources

1. Requirements

2. Install and configure the primary federation server

Prerequisites

  1. Update server with all required patches
  2. Install the Microsoft Online Services Sign-In Assistant (SIA)
  3. Install the Windows Azure Active Directory (WAAD) module for PowerShell
  4. 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

  1. Update server with all required patches
  2. Import the SSL certificate into the Personal store using the Certificates MMC snap-in
  3. Credentials of a local administrator account on the internal federation servers
  4. Unfettered Internet access
1. On the AD FS proxy server, start the 'Add Roles and Features Wizard' as we did before. At the Server Roles step, check the Remote Access box, then skip straight to the Role Services step. 
 
2. Check Web Application Proxy box, then click Next.
 
3. Review the list of roles and features to be added, then click Install.
 
4. Wait for the installation to complete, then click Open the Web Application Proxy Wizard.
 
5. At the Welcome step, click Next.
 
6. Enter the federation service name. For the user name and password, enter the credentials of a local administrator account on the internal federation servers.
 
7. Select the SSL certificate that we used on the federation server, then click Next.
 
8. Review the PowerShell command that will be run to configure the Web Application Proxy, then click Configure.
 
9. Click Close. The Remote Access Management Console will automatically open.
 
10. In the Remote Access Management Console, click Publish.
 
11. At the Welcome step, click Next.
 
12. Select Pass-through, then click Next.
 
13. Designate a publishing name for the web application, then enter the external URL that will be used to access the AD FS proxy server from the Internet. Next, choose the SSL certificate that we've been using all along, then enter the internal URL that will be used to access the AD FS federation servers. Note that both URL's should be identical and use the standard web address notation (example: https://sts.treybyday.com). When finished, click Next.
 
14. Here you can optionally copy the PowerShell command if you are planning to automate deployment in a large farm. Verify the publishing settings, then click Publish.
 
15. Your AD FS proxy server is now published and ready to accept external authentication requests.

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

1. First we need to install the IIS server role. In the Add Roles and Features Wizard, skip to the Server Roles step and check the box for Web Server (IIS) . 
 
2. Review the required features that will accompany the IIS role and make sure the box to Include management tools (if applicable)  remains checked. We will need the IIS Management Console to complete the certificate request. Click Add features.
 
3. Verify that the Web Server (IIS) role is now checked, then skip to the Confirmation step.
 
4. Review the roles and features to be added, then click Install. Once installation has completed, exit the wizard and return to Server Manager.
  
5. From Server Manager, click on Tools and select Internet Information Services (IIS) Manager. If this is your first time launching IIS, you'll notice a Web Platform Components prompt. Click No to exit and optionally check the box to not show the message again.
 
6. Double-click Server Certificates.
 
7. Click Create Certificate Request... from the right-hand Actions menu.
  
8. Enter the required information for the certificate, making sure to provide the intended SSL URL value for the Common name. Click Next when ready.
 
9. Choose Microsoft RSA SChannel Cryptographic Provider, and set the Bit length to a minimum of 2048 (recommended), then click Next.
 
10. Click on the ellipsis to create the certificate request file.
  
11. Choose an appropriate filename for the .txt file, then click Open.
 
12.

Make note of the filename and location of the certificate request, then click Finish.

You will now need to provide this certificate request file to your DNS provider. Once accepted, they will issue you a .cer file to be used to complete the request in IIS.
 
13. After being issued the SSL certificate, return to IIS and click Complete Certificate Request... from the right-hand Actions menu.
 
14. Click on the ellipsis to browse for the certificate you downloaded.
 
15. Select the certificate and click Open.
 
16. Enter the friendly name for the certificate. This will be value shown in the URL that points to your on-premises AD FS servers. E.g. https://sts.treybyday.com/adfs/ls

Choose Personal certificate store and click OK.
 
17. Your SSL certificate is now available for import in the AD FS Configuration Wizard. You can export the certificate to a .pfx file for use on each additional federation server & proxy.

 

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

Client Access Policy Builder

Multi-Factor Access Control

AlternateLoginID Feature

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