Jaa


Review the requirements for deploying AD FS

Applies To: Azure, Office 365, Power BI, Windows Intune

For a new AD FS deployment to create a relying party trust successfully with Azure AD, you must first make sure that your corporate network infrastructure is configured to support AD FS requirements for accounts, name resolution, and certificates. AD FS has the following types of requirements:

  • Software requirements

  • Certificate requirements

  • Network requirements

Software requirements

AD FS software must be installed on any computer that you are preparing for the federation server or federation server proxy role. You can install this software by either using the AD FS Setup Wizard or by performing a quiet installation using the adfssetup.exe /quiet parameter at a command line.

For a base installation platform, AD FS requires either the Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 operating system. AD FS has a separate installation package for the Windows Server 2008, Windows Server 2008 R2 operating system platforms (and it is commonly referred to as AD FS 2.0) or it can be installed by adding the Federation Service server role as part of the Windows Server 2012 or Windows Server 2012 R2 operating system.

If you are using AD FS 2.0 or AD FS in Windows Server 2012, you will deploy and configure federation server proxies as part of implementing your SSO solution.

If you are using AD FS in Windows Server 2012 R2, you will deploy Web Application Proxies in order to configure your AD FS deployment for extranet access. In Windows Server 2012 R2, a Web Application Proxy, a new role service of the Remote Access server role, is used to enable your AD FS for accessibility from outside of the corporate network. For more information, see Web Application Proxy Overview.

Prerequisites

During the AD FS installation process, the setup wizard attempts to automatically check for and, if necessary, install both prerequisite applications and dependent hotfixes. In most cases the setup wizard will install all of the prerequisite applications necessary for AD FS to operate and install.

However, there is one exception: when you are installing AD FS on the Windows Server 2008 platform (as a separate installation package known as AD FS 2.0). If this is the case in your deployment situation, you will first need to make sure that .NET 3.5 SP1 is installed on the servers running Windows Server 2008 before installing the AD FS 2.0 software, as it is a prerequisite of AD FS 2.0 and it will not automatically be installed by the AD FS 2.0 Setup Wizard on this platform. If .NET 3.5 SP1 is not installed, the AD FS 2.0 Setup Wizard will prevent installation of the AD FS 2.0 software.

Hotfixes

You must install AD FS 2.0 hotfixes after you have installed AD FS 2.0. For more information, see Description of Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0.

Virtualization

AD FS supports software virtualization of both the federation server and federation server proxy roles. To account for redundancy, we recommend that you store each AD FS virtual machine on separate, physical virtual servers.

For more information about setting up a virtual server environment using Microsoft virtualization technology, see the Hyper-V Getting Started Guide.

Certificate requirements

Certificates play the most critical role in securing communications between federation servers, Web Application Proxies, federation server proxies, the cloud service, and web clients. The requirements for certificates vary, depending on whether you are setting up a federation server,a Web Application Proxy, or federation server proxy computer, as described in the following tables.

Federation server certificates

Federation servers require the certificates in the following table.

Certificate type Description What you need to know before deploying

SSL certificate (also referred to as a Server Authentication Certificate) for AD FS in Windows Server 2012 R2

This is a standard Secure Sockets Layer (SSL) certificate that is used for securing communications between federation servers, clients, Web Application Proxy, and federation server proxy computers.

AD FS requires a certificate for SSL server authentication on each federation server in your federation server farm. The same certificate should be used on each federation server in a farm. You must have both the certificate and its private key available. For example, if you have the certificate and its private key in a .pfx file, you will be able import the file directly into the Active Directory Federation Services Configuration Wizard. This SSL certificate must contain the following:

  1. Subject name and subject alternative name must contain your federation service name, such as fs.contoso.com

  2. Subject alternative name must contain the value enterpriseregistration followed by the UPN suffix of your organization, such as, for example, enterpriseregistration.corp.contoso.com

SSL certificate (also referred to as a Server Authentication Certificate) for legacy versions of AD FS

This is a standard Secure Sockets Layercertificate that is used for securing communications between federation servers, clients, Web Application Proxy, and federation server proxy computers.

AD FS requires an SSL certificate when configuring federation server settings. By default, AD FS uses the SSL certificate configured for the Default Web Site in Internet Information Services (IIS).

The Subject name of this SSL certificate is used to determine the Federation Service name for each instance of AD FS that you deploy. For this reason, you may want to consider choosing a Subject name on any new certification authority (CA)-issued certificates that best represents the name of your company or organization to the cloud service and this name must be Internet-routable. For example, in the diagram provided earlier in this article (see “Phase 2”), the subject name of the certificate would be fs.fabrikam.com.

Important

AD FS requires this SSL certificate to be without a dotless (short-name) Subject name.

Required: Because this certificate must be trusted by clients of AD FS and Microsoft cloud services, use an SSL certificate that is issued by a public (third-party) CA or by a CA that is subordinate to a publicly trusted root; for example, VeriSign or Thawte.

Token-signing certificate

This is a standard X.509 certificate that is used for securely signing all tokens that the federation server issues and that the cloud service will accept and validate.

The token-signing certificate must contain a private key, and it should chain to a trusted root in the Federation Service. By default, AD FS creates a self-signed certificate. However, depending on the needs of your organization, you can change this later to a CA-issued certificate by using the AD FS Management snap-in.

Recommendation: Use the self-signed token-signing certificate generated by AD FS. By doing so, AD FS will manage this certificate for you by default. For example, in case this certificate is expiring, AD FS will generate a new self-signed certificate to use ahead of time.

Warning

The token-signing certificate is critical to the stability of the Federation Service. In case it is changed, the cloud service needs to be notified about this change. Otherwise, the requests to the cloud service will fail. For more information about managing certificates across the AD FS federation server farm and the cloud service, see Update trust properties.

Proxy computer certificates

Federation server proxies require the certificate in the following table.

Certificate type Description What you need to know before deploying

SSL certificate

This is a standard SSL certificate that is used for securing communications between a federation server, federation server proxy or Web Application Proxy, and Internet client computers.

This is same server authentication certificate as the one used by the federation servers in the corporate network. This certificate must have the same subject name as the SSL certificate configured on the federation server in the corporate network.

If you are using AD FS in Windows Server 2008 or Windows Server 2012, you must install this certificate on the Default Web Site of the federation server proxy computer.

If you are using AD FS in Windows Server 2012 R2, you must import this certificate to the Personal Certificates store on the computer that will function as your Web Application Proxy.

Recommendation: Use the same server authentication certificate as is configured on the federation server that this federation server proxy or Web Application Proxy will connect to.

For more information about the certificates that federation servers and federation server proxies use, see AD FS 2.0 Design Guide or Windows Server 2012 AD FS Design Guide.

Network requirements

Configuring the following network services appropriately is critical for successful deployment of AD FS in your organization.

TCP/IP network connectivity

For AD FS to function, TCP/IP network connectivity must exist between the client, domain controllers, federation servers, and federation server proxies.

DNS

The primary network service that is critical to the operation of AD FS, other than Active Directory, is Domain Name System (DNS). When DNS is deployed, users can use friendly computer names that are easy to remember to connect to computers and other resources on IP networks.

The process of updating DNS to support AD FS consists of configuring the:

  • Internal DNS servers in the corporate network to resolve the cluster DNS name to the cluster IP address for the NLB cluster you configure on the corporate network NLB host. For example, resolving fs.fabrikam.com to 172.16.1.3.

  • Perimeter network DNS servers to resolve the cluster DNS name to the cluster IP address for the NLB cluster you configure on the perimeter NLB host. For example, resolving fs.fabrikam.com to 192.0.2.3.

NLB requirements

NLB is required to provide fault tolerance, high availability, and load-balancing across multiple nodes. It can be implemented with hardware, software, or a combination of both. You need to configure the DNS resource records based on your Federation Service name for the NLB cluster so that the fully qualified domain name (FQDN) of the cluster (also referred to as cluster DNS name in this article) will be resolved to its cluster IP address.

For general information about the NLB cluster IP address or cluster FQDN, see Specifying the Cluster Parameters.

Utilize Extended Protection for Authentication

If your computers have Extended Protection for Authentication, and you use Firefox, Chrome, or Safari, you may not be able to sign in to the cloud service using Integrated Windows authentication from within the corporate network. If this situation occurs, your users might receive logon prompts on a regular basis. This is due to the default configuration (on Windows 7 and patched client operating systems) for AD FS and Extended Protection for Authentication.

Until Firefox, Chrome, and Safari support Extended Protection for Authentication, the recommended option is for all clients accessing the cloud service to install and use Windows Internet Explorer 8. If you want to use single sign-on for the cloud service with Firefox, Chrome, or Safari, there are two other solutions to consider. However, there may be security concerns in taking either of these approaches. For more information, see Microsoft Security Advisory: Extended protection for authentication. The solutions include:

  • Uninstalling the Extended Protection for Authentication patches from your computer.

  • Changing the Extended Protection for Authentication setting on the AD FS server. For more information, see Configuring Advanced Options for AD FS 2.0.

  • Reconfiguring the authentication settings for the AD FS webpage on each federation server from Integrated Windows authentication to using Forms Based Authentication.

Next step

Now that you have reviewed the requirements for deploying AD FS, the next step is to Prepare your network infrastructure for federation servers.

See Also

Concepts

Checklist: Use AD FS to implement and manage single sign-on