AD FS Requirements

Applies To: Windows Server 2012 R2

The following are the various requirements that you must conform to when deploying AD FS:

• Certificate requirements

• Hardware requirements

• Software requirements

• AD DS requirements

• Configuration database requirements

• Browser requirements

• Extranet requirements

• Network requirements

• Attribute store requirements

• Application requirements

• Authentication requirements

• Workplace join requirements

• Cryptography requirements

• Permissions requirements

Certificate requirements

Certificates play the most critical role in securing communications between federation servers, Web Application Proxies, claims-aware applications, and Web clients. The requirements for certificates vary, depending on whether you are setting up a federation server or a proxy computer, as described in this section.

Federation server certificates

Hardware requirements

The following minimum and recommended hardware requirements apply to the AD FS federation servers in Windows Server 2012 R2:

Software requirements

The following AD FS requirements are for the server functionality that is built into the Windows Server® 2012 R2 operating system:

• For extranet access, you must deploy the Web Application Proxy role service - part of the Windows Server® 2012 R2 Remote Access server role. Prior versions of a federation server proxy are not supported with AD FS in Windows Server® 2012 R2.

• A federation server and the Web Application Proxy role service cannot be installed on the same computer.

AD DS requirements

Domain controller requirements

For AD FS to be supported, domain controllers in all user domains and in the domain that AD FS servers are joined to must be running Windows Server 2003 or later.

Domain functional-level requirements

All user account domains and the domain that the AD FS servers are joined to must be operating at the domain functional level of Windows Server 2003 or higher.

Most AD FS features do not require AD DS functional-level modifications to operate successfully. However, Windows Server 2008 domain functional level or higher is required for client certificate authentication to operate successfully if the certificate is explicitly mapped to a user's account in AD DS.

Schema requirements

• AD FS does not require schema changes or functional-level modifications to AD DS.

• To use Workplace Join functionality, the schema of the forest that AD FS servers are joined to must be set to Windows Server 2012 R2.

Service account requirements

• Any standard service account can be used as a service account for AD FS. Group Managed Service accounts are also supported. This requires at least one domain controller (it is recommended that you deploy two or more) that is running Windows Server 2012 or higher.

• For Kerberos authentication to function between domain-joined clients and AD FS, the ‘HOST/<adfs_service_name>’ must be registered as a SPN on the service account. By default, AD FS will configure this when creating a new AD FS farm if it has sufficient permissions to perform this operation.

• The AD FS service account must be trusted in every user domain that contains users authenticating to the AD FS service.

Domain Requirements

• All AD FS servers must be a joined to an AD DS domain.

• All AD FS servers within a farm must be deployed in a single domain.

• The domain that the AD FS servers are joined to must trust every user account domain that contains users authenticating to the AD FS service.

Multi Forest Requirements

• The domain that the AD FS servers are joined to must trust every user account domain or forest that contains users authenticating to the AD FS service.

• The AD FS service account must be trusted in every user domain that contains users authenticating to the AD FS service.

Configuration database requirements

The following are the requirements and restrictions that apply based on the type of configuration store:

WID

• A WID farm has a limit of 30 federation servers if you have 100 or fewer relying party trusts.

• Artifact resolution profile in SAML 2.0 is not supported in the WID configuration database. Token Replay Detection is not supported in the WID configuration database. This functionality is only used only in scenarios where AD FS is acting as the federation provider and consuming security tokens from external claims providers.

• Deploying AD FS servers in distinct data centers for failover or geographic load balancing is supported as long as the number of servers does not exceed 30.

The following table provides a summary for using a WID farm. Use it to plan your implementation.

SQL Server

For AD FS in Windows Server 2012 R2, you can use SQL Server 2008 and higher, including SQL Server 2012 and SQL Server 2014.

Browser requirements

When AD FS authentication is performed via a browser or browser control, your browser must comply to the following requirements:

• JavaScript must be enabled

• Cookies must be turned on

• Server Name Indication (SNI) must be supported

• For user certificate & device certificate authentication (workplace join functionality), the browser must support SSL client certificate authentication

Several key browsers and platforms have undergone validation for rendering and functionality the details of which are listed below. Browsers and devices that not covered in this table are still supported if they meet the requirements listed above:

Cookies

AD FS creates session-based and persistent cookies that must be stored on client computers to provide sign-in, sign-out, single sign-on (SSO), and other functionality. Therefore, the client browser must be configured to accept cookies. Cookies that are used for authentication are always Secure Hypertext Transfer Protocol (HTTPS) session cookies that are written for the originating server. If the client browser is not configured to allow these cookies, AD FS cannot function correctly. Persistent cookies are used to preserve user selection of the claims provider. You can disable them by using a configuration setting in the configuration file for the AD FS sign-in pages. Support for TLS/SSL is required for security reasons.

Extranet requirements

To provide extranet access to the AD FS service, you must deploy the Web Application Proxy role service as the extranet facing role that proxies authentication requests in a secure manner to the AD FS service. This provides isolation of the AD FS service endpoints as well as isolation of all security keys (such as token signing certificates) from requests that originate from the internet. In addition, features such as Soft Extranet Account Lockout require the use of the Web Application Proxy. For more information about Web Application Proxy, see Web Application Proxy.

If you want to use a third-party proxy for extranet access, this third-party proxy must support the protocol defined in https://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5bMS-ADFSPIP%5d.pdf.

Network requirements

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

Configuring Corporate Firewall

Both the firewall located between the Web Application Proxy and the federation server farm and the firewall between the clients and the Web Application Proxy must have TCP port 443 enabled inbound.

In addition, if client user certificate authentication (clientTLS authentication using X509 user certificates) is required, AD FS in Windows Server 2012 R2 requires that TCP port 49443 be enabled inbound on the firewall between the clients and the Web Application Proxy. This is not required on the firewall between the Web Application Proxy and the federation servers).

Configuring DNS

• For intranet access, all clients accessing AD FS service within the internal corporate network (intranet) must be able to resolve the AD FS service name (name provided by the SSL certificate) to the load balancer for the AD FS servers or the AD FS server.

• For extranet access, all clients accessing AD FS service from outside the corporate network (extranet/internet) must be able to resolve the AD FS service name (name provided by the SSL certificate) to the load balancer for the Web Application Proxy servers or the Web Application Proxy server.

• For extranet access to function properly, each Web Application Proxy server in the DMZ must be able to resolve AD FS service name (name provided by the SSL certificate) to the load balancer for the AD FS servers or the AD FS server. This can be achieved using an alternate DNS server in the DMZ network or by changing local server resolution using HOSTS file.

• For Windows Integrated authentication to work inside the network and outside the network for a subset of endpoints exposed through the Web Application Proxy, you must use an A record (not CNAME) to point to the load balancers.

For information on configuring corporate DNS for the federation service and Device Registration Service, see Configure Corporate DNS for the Federation Service and DRS.

For information on configuring corporate DNS for Web Application proxies, see the “Configure DNS” section in Step 1: Configure the Web Application Proxy Infrastructure.

For information about how to configure a cluster IP address or cluster FQDN using NLB, see Specifying the Cluster Parameters at https://go.microsoft.com/fwlink/?LinkId=75282.

Attribute store requirements

AD FS requires at least one attribute store to be used for authenticating users and extracting security claims for those users. For a list of attribute stores that AD FS supports, see The Role of Attribute Stores.

LDAP Attribute Stores

When you work with other Lightweight Directory Access Protocol (LDAP)-based attribute stores, you must connect to an LDAP server that supports Windows Integrated authentication. The LDAP connection string must also be written in the format of an LDAP URL, as described in RFC 2255.

It is also required that the service account for the AD FS service has the right to retrieve user information in the LDAP attribute store.

SQL Server Attribute Stores

For AD FS in Windows Server 2012 R2 to operate successfully, computers that host the SQL Server attribute store must be running either Microsoft SQL Server 2008 or higher. When you work with SQL-based attribute stores, you also must configure a connection string.

Custom Attribute Stores

You can develop custom attribute stores to enable advanced scenarios.

• The policy language that is built into AD FS can reference custom attribute stores so that any of the following scenarios can be enhanced:

  • Creating claims for a locally authenticated user

  • Supplementing claims for an externally authenticated user

  • Authorizing a user to obtain a token

  • Authorizing a service to obtain a token on behavior of a user

  • Issuing additional data in security tokens issued by AD FS to relying parties.

• All custom attribute stores must be built on top of .NET 4.0 or higher.

When you work with a custom attribute store, you might also have to configure a connection string. In that case, you can enter a custom code of your choice that enables a connection to your custom attribute store. The connection string in this situation is a set of name/value pairs that are interpreted as implemented by the developer of the custom attribute store.For more information about developing and using custom attribute stores, see Attribute Store Overview.

Application requirements

AD FS supports claims-aware applications that use the following protocols:

• WS-Federation

• WS-Trust

• SAML 2.0 protocol using IDPLite, SPLite & eGov1.5 profiles.

• OAuth 2.0 Authorization Grant Profile

AD FS also supports authentication and authorization for any non-claims-aware applications that are supported by the Web Application Proxy.

Authentication requirements

AD DS Authentication (Primary Authentication)

For intranet access, the following standard authentication mechanisms for AD DS are supported:

• Windows Integrated Authentication using Negotiate for Kerberos & NTLM

• Forms Authentication using username/passwords

• Certificate Authentication using certificates mapped to user accounts in AD DS

For extranet access, the following authentication mechanisms are supported:

• Forms Authentication using username/passwords

• Certificate Authentication using certificates that are mapped to user accounts in AD DS

• Windows Integrated Authentication using Negotiate (NTLM only) for WS-Trust endpoints that accept Windows Integrated Authentication.

For Certificate Authentication:

• Extends to smartcards that can be pin protected.

• The GUI for the user to enter their pin is not provided by AD FS and is required to be part of the client operating system that is displayed when using client TLS.

• The reader and cryptographic service provider (CSP) for the smart card must work on the computer where the browser is located.

• The smart card certificate must chain up to a trusted root on all the AD FS servers and Web Application Proxy servers.

• The certificate must map to the user account in AD DS by either of the following methods:

  • The certificate subject name corresponds to the LDAP distinguished name of a user account in AD DS.

  • The certificate subject altname extension has the user principal name (UPN) of a user account in AD DS.

For seamless Windows Integrated Authentication using Kerberos in the intranet,

• It is required for the service name to be part of the Trusted Sites or the Local Intranet sites.

• In addition, the HOST/<adfs_service_name> SPN must be set on the service account that the AD FS farm runs on.

Multi-Factor Authentication

AD FS supports additional authentication (beyond primary authentication supported by AD DS) using a provider model whereby vendors/customers can build their own multi-factor authentication adapter that an administrator can register and use during login.

Every MFA adapter must be built on top of .NET 4.5.

For more information on MFA, see Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

Device Authentication

AD FS supports device authentication using certificates provisioned by the Device Registration Service during the act of an end user workplace joining their device.

Workplace join requirements

End users can workplace join their devices to an organization using AD FS. This is supported by the Device Registration Service in AD FS. As a result, end users get the additional benefit of SSO across the applications supported by AD FS. In addition, administrators can manage risk by restricting access to applications only to devices that have been workplace joined to the organization. Below are the following requirements to enable this scenario.

• AD FS supports workplace join for Windows 8.1 and iOS 5+ devices

• To use Workplace Join functionality, the schema of the forest that AD FS servers are joined to must be Windows Server 2012 R2.

• The subject alternative name of the SSL certificate for AD FS service must contain the value enterpriseregistration that is followed by the User Principal Name (UPN) suffix of your organization, for example, enterpriseregistration.corp.contoso.com.

Cryptography requirements

The following table provides additional cryptography support information on the AD FS token signing, token encryption/decryption functionality:

Permissions requirements

The administrator that performs the installation and the initial configuration of AD FS must have domain administrator permissions in the local domain (in other words, the domain to which the federation server is joined to.)

See Also

AD FS Design Guide in Windows Server 2012 R2