AD FS Requirements for Windows Server
The following are the various requirements that you must conform to when deploying AD FS:
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're setting up a federation server or a proxy computer, as described in this section.
Federation server certificates
| Certificate type | Requirements, Support & Things to Know |
|---|---|
| Secure Sockets Layer (SSL) certificate: This is a standard SSL certificate that is used for securing communications between federation servers and clients. | - This certificate must be a publicly trusted* X509 v3 certificate. - All clients that access any AD FS endpoint must trust this certificate. It's strongly recommended to use certificates that are issued by a public (third-party) certification authority (CA). You can use a self-signed SSL certificate successfully on federation servers in a test lab environment. However, for a production environment, we recommend that you obtain the certificate from a public CA. - Supports any key size supported by Windows Server 2012 R2 for SSL certificates. - Doesn't support certificates that use CNG keys. - When used together with Workplace Join/Device Registration Service, the subject alternative name of the SSL certificate for the AD FS service must contain the value enterpriseregistration that is followed by the User Principal Name (UPN) suffix of your organization, for example, enterpriseregistration.contoso.com. - Wild card certificates are supported. When you create your AD FS farm, you'll be prompted to provide the service name for the AD FS service (for example, adfs.contoso.com. - It's strongly recommended to use the same SSL certificate for the Web Application Proxy. This is however required to be the same when supporting Windows Integrated Authentication endpoints through the Web Application Proxy and when Extended Protection Authentication is turned on (default setting). - The Subject name of this certificate is used to represent 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 CA-issued certificates that best represents the name of your company or organization to partners. The identity of the certificate must match the federation service name (for example, fs.contoso.com).The identity is either a subject alternative name extension of type dNSName or, if there are no subject alternative name entries, the subject name specified as a common name. Multiple subject alternative name entries can be present in the certificate, provided one of them matches the federation service name. - Important: it's strongly recommended to use the same SSL certificate across all nodes of your AD FS farm as well as all Web Application proxies in your AD FS farm. |
| Service communication certificate: This certificate enables WCF message security for securing communications between federation servers. | - By default, the SSL certificate is used as the service communications certificate. But you also have the option to configure another certificate as the service communication certificate. - Important: if you're using the SSL certificate as the service communication certificate, when the SSL certificate expires, make sure to configure the renewed SSL certificate as your service communication certificate. This doesn't happen automatically. - This certificate must be trusted by clients of AD FS that use WCF Message Security. - We recommend that you use a server authentication certificate that is issued by a public (third-party) certification authority (CA). - The service communication certificate can't be a certificate that uses CNG keys. - This certificate can be managed using the AD FS Management console. |
| Token-signing certificate: This is a standard X509 certificate that is used for securely signing all tokens that the federation server issues. | - By default, AD FS creates a self-signed certificate with 2048 bit keys. - CA issued certificates are also supported and can be changed using the AD FS Management snap-in - CA issued certificates must be stored & accessed through a CSP Crypto Provider. - The token signing certificate can't be a certificate that uses CNG keys. - AD FS doesn't require externally enrolled certificates for token signing. AD FS automatically renews these self-signed certificates before they expire, first configuring the new certificates as secondary certificates to allow for partners to consume them, then flipping to primary in a process called automatic certificate rollover.We recommend that you use the default, automatically generated certificates for token signing. If your organization has policies that require different certificates to be configured for token signing, you can specify the certificates at installation time using PowerShell (use the –SigningCertificateThumbprint parameter of the Install-AdfsFarm cmdlet). After installation, you can view and manage token signing certificates using the AD FS Management console or PowerShell cmdlets Set-AdfsCertificate and Get-AdfsCertificate. When externally enrolled certificates are used for token signing, AD FS doesn't perform automatic certificate renewal or rollover. This process must be performed by an administrator. To allow for certificate rollover when one certificate is close to expiring, a secondary token signing certificate can be configured in AD FS. By default, all token signing certificates are published in federation metadata, but only the primary token-signing certificate is used by AD FS to actually sign tokens. |
| Token-decryption/encryption certificate: This is a standard X509 certificate that is used to decrypt/encrypt any incoming tokens. It's also published in federation metadata. | - By default, AD FS creates a self-signed certificate with 2048 bit keys. - CA issued certificates are also supported and can be changed using the AD FS Management snap-in - CA issued certificates must be stored & accessed through a CSP Crypto Provider. - The token-decryption/encryption certificate can't be a certificate that uses CNG keys. - By default, AD FS generates and uses its own, internally generated and self-signed certificates for token decryption. AD FS doesn't require externally enrolled certificates for this purpose. In addition, AD FS automatically renews these self-signed certificates before they expire. We recommend that you use the default, automatically generated certificates for token decryption. If your organization has policies that require different certificates to be configured for token decryption, you can specify the certificates at installation time using PowerShell (use the –DecryptionCertificateThumbprint parameter of the Install-AdfsFarm cmdlet). After installation, you can view and manage token decryption certificates using the AD FS Management console or PowerShell cmdlets Set-AdfsCertificate and Get-AdfsCertificate. When externally enrolled certificates are used for token decryption, AD FS doesn't perform automatic certificate renewal. This process must be performed by an administrator. - The AD FS service account must have access to the token-signing certificate's private key in the personal store of the local computer. This is taken care of by Setup. You can also use the AD FS Management snap-in to ensure this access if you subsequently change the token-signing certificate. |
Caution
Certificates that are used for token-signing and token-decrypting/encrypting are critical to the stability of the Federation Service. Customers managing their own token-signing & token-decrypting/encrypting certificates should ensure that these certificates are backed up and are available independently during a recovery event.
Note
In AD FS you can change the Secure Hash Algorithm (SHA) level that is used for digital signatures to either SHA-1 or SHA-256 (more secure). AD FS doesn't support the use of certificates with other hash methods, such as MD5 (the default hash algorithm that is used with the Makecert.exe command-line tool). As a security best practice, we recommend that you use SHA-256 (which is set by default) for all signatures. SHA-1 is recommended for use only in scenarios in which you must interoperate with a product that doesn't support communications using SHA-256, such as a non-Microsoft product or legacy versions of AD FS.
Note
After you receive a certificate from a CA, make sure that all certificates are imported into the personal certificate store of the local computer. You can import certificates to the personal store with the Certificates MMC snap-in.
Hardware requirements
The following minimum and recommended hardware requirements apply to the AD FS federation servers in Windows Server 2012 R2:
| Hardware requirement | Minimum requirement | Recommended requirement |
|---|---|---|
| CPU speed | 1.4 GHz 64-bit processor | Quad-core, 2 GHz |
| RAM | 512 MB | 4 GB |
| Disk space | 32 GB | 100 GB |
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 can't be installed on the same computer.
AD DS requirements
Domain controller requirements
Domain controllers in all user domains and the domain to which the AD FS servers are joined must be running Windows Server 2008 or later.
Note
All support for environments with Windows Server 2003 domain controllers will end after the Extended Support End Date for Windows Server 2003. Customers are strongly recommended to upgrade their domain controllers as soon as possible. Visit this page for additional information on Microsoft Support Lifecycle. For issues discovered that are specific to Windows Server 2003 domain controller environments, fixes will be issued only for security issues and if a fix can be issued prior to the expiry of Extended Support for Windows Server 2003.
Note
AD FS requires a full writable Domain Controller to function as opposed to a Read-Only Domain Controller. If a planned topology includes a Read-Only Domain controller, the Read-Only domain controller can be used for authentication but LDAP claims processing will require a connection to the writable domain controller.
Domain functional-level requirements
All user account domains and the domain to which the AD FS servers are joined 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 doesn't 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've 100 or fewer relying party trusts.
Artifact resolution profile in SAML 2.0 isn't supported in the WID configuration database. Token Replay Detection isn't 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 doesn't exceed 30.
The following table provides a summary for using a WID farm. Use it to plan your implementation.
| 1-100 RP Trusts | More than 100 RP Trusts |
|---|---|
| 1-30 AD FS Nodes: WID supported | 1-30 AD FS Nodes: Not supported using WID - SQL Required |
| More than 30 AD FS Nodes: Not supported using WID - SQL Required | More than 30 AD FS Nodes: Not supported using WID - SQL Required |
SQL Server
For AD FS in Windows Server 2012 R2, you can use SQL Server 2008 and higher
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:
| Browsers | Platforms |
|---|---|
| IE 10.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| IE 11.0 | Windows7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Windows Web Authentication Broker | Windows 8.1 |
| Firefox [v21] | Windows 7, Windows 8.1 |
| Safari [v7] | iOS 6, Mac OS-X 10.7 |
| Chrome [v27] | Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7 |
Important
Known issue - Firefox: Workplace Join functionality that identifies the device using device certificate isn't functional on Windows platforms. Firefox doesn't currently support performing SSL client certificate authentication using certificates provisioned to the user certificate store on Windows clients.
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 isn't configured to allow these cookies, AD FS can't 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. `
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 isn't required on the firewall between the Web Application Proxy and the federation servers).
Note
Also make sure that port 49443 isn't used by any other services on the AD FS and Web Application Proxy server.
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 http://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.
Note
AD FS automatically creates an "Active Directory" attribute store, by default. Attribute store requirements depend on whether your organization is acting as the account partner (hosting the federated users) or the resource partner (hosting the federated application).
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's 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 isn't 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's 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:
| Algorithm | Key lengths | Protocols/Applications/Comments |
|---|---|---|
| TripleDES – Default 192 (Supported 192 – 256) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | Supported algorithm for Decrypting the security token. Encrypting the security token with this algorithm isn't supported. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Supported algorithm for Decrypting the security token. Encrypting the security token with this algorithm isn't supported. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Supported algorithm for Decrypting the security token. Encrypting the security token with this algorithm isn't supported. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Default. Supported algorithm for Encrypting the security token. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | All Key sizes supported by .NET 4.0+ | Supported algorithm for Encrypting the symmetric key that encrypts a security token. |
| AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Supported algorithm for Encrypting the symmetric key that encrypts the security token. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Supported algorithm for Encrypting the symmetric key that encrypts the security token. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Supported algorithm for Encrypting the symmetric key that encrypts the security token. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Supported algorithm for Encrypting the symmetric key that encrypts the security token. |
| RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1024 | Default. Supported algorithm for Encrypting the symmetric key that encrypts the security token. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | N/A | Used by AD FS Server in artifact SourceId generation: In this scenario, the STS uses SHA1 (per the recommendation in the SAML 2.0 standard) to create a short 160 bit value for the artifact sourceiD. Also used by the AD FS web agent (legacy component from WS2003 timeframe) to identify changes in a "last updated" time value so that it knows when to update information from the STS. |
| SHA1withRSA- | N/A | Used in cases when AD FS Server validates the signature of SAML AuthenticationRequest, sign the artifact resolution request or response, create token-signing certificate. In these cases, SHA256 is the default, and SHA1 is only used if the partner (relying party) can't support SHA256 and must use SHA1. |
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.)