Share via

AD FS 2.0: Guidance for Selecting and Utilizing a Federation Service Name

  • Article

Prior to deploying AD FS 2.0, it is essential that a Federation Service Name is selected, and there are some important items to consider before selecting the Federation Service Name.

**Items for Consideration
**
1. The Federation Service Name must never equal any machine name in the Active Directory forest when you are deploying a AD FS 2.0 farm. This requirement is in place to allow Kerberos authentication to succeed for your Federation Service.

Example of a failing scenario
The Federation Service Name is ADFS.CONTOSO.COM and the host names of the two Federation Servers in your farm are: ADFS.CONTOSO.COM and ADFS2.CONTOSO.COM. Kerberos authentication will fail because your AD FS 2.0 service account needs to have the following servicePrincipalName (SPN) registered: HOST/ADFS.CONTOSO.COM. Since you already have a computer in Active Directory named ADFS.CONTOSO.COM, the HOST/ADFS.CONTOSO.COM SPN is already registered to this computer account, which means that registering this SPN to your AD FS 2.0 service account is not an option.

Example of a working scenario
The Federation Service Name is SSO.CONTOSO.COM and the host names of the two Federation Servers in your farm are: ADFS.CONTOSO.COM and ADFS2.CONTOSO.COM. Kerberos authentication can succeed since your AD FS 2.0 service account can have the SPN HOST/SSO.CONTOSO.COM registered to it since neither the AD FS 2.0 servers nor any other account in the Active Directory forest have this SPN registered.

2. The HOST/<Federation Service Name> SPN must be registered to the AD FS 2.0 service account. This requirement goes hand-in-hand with item 1 to allow Kerberos authentication to succeed. For information on registering this SPN, see:
AD FS 2.0: How to Configure the SPN (servicePrincipalName) for the Service Account

3. The subject of all SSL certificates in the farm, including all Federation Servers and Federation Server Proxies, must utilize the Federation Service Name. It is important to note that wildcard and Subject Alternative Name (SAN) certificates are supported.

Example of a failing scenario
The Federation Service Name is SSO.CONTOSO.COM and the subject of the SSL certificate on a Federation Server in the farm is ADFS.CONTOSO.COM. This SSL certificate does not make use of wildcard or SAN.

Example of a working scenario
The Federation Service Name is SSO.CONTOSO.COM and the subject of the SSL certificate on all Federation Servers and Federation Server Proxies is SSO.CONTOSO.COM.

Example 2 of a working scenario
The Federation Service Name is SSO.CONTOSO.COM and the subject of the SSL certificate on all Federation Servers and Federation Server Proxies is *.CONTOSO.COM. This shows the supported use of a wildcard subject.

Example 3 of a working scenario
The Federation Service Name is SSO.CONTOSO.COM and the subject of the SSL certificate on all Federation Servers and Federation Server Proxies is ADFS.CONTOSO.COM. This SSL certificate also has a SAN of DNS name = SSO.CONTOSO.COM. This shows the supported use of a SAN.

4. The subject of the Service Communications certificate must utilize the Federation Service Name. It is important to note that wildcard and Subject Alternative Name (SAN) certificates are supported. By default, AD FS 2.0 will utilize the same certificate for SSL and Service Communications. You have the option of replacing the Service Communiations certificate after intial configuration is complete, and, when replacing the Service Communications certificate, you must consider the subject and SAN requirements. The example scenarios for the Service Communications certificate are similar to the example scenarios from item 3.

5. The Federation Service Name must be registered as a host record in DNS. If the Federation Service is available externally on the internet, public DNS registration should occur to allow the Federation Service Name to resolve to the IP address of your Federation Server Proxy or Federation Server Proxy load balancer. Internally, the Federation Service Name should resolve to the IP address of the internal Federation Server or Federation Server load balancer.

6. The Federation Service Name must be set in the Federation Service Properties. The Federation Service Name is set automatically per the subject of the SSL certificate bound to the Default Web Site during execution of the GUI initial configuration wizard. Alternatively, if the command line version of the initial configuration utility is used (FSConfig.exe), you have the option of manually specifying the Federation Service Name. After initial configuration is complete, you also have the option of changing the Federation Service Name by modifying Federation Service Properties. This can be accomplished in the AD FS 2.0 MMC console or via the Set-AdfsProperties Powershell cmdlet. For more information regarding changing the Federation Service Name after initial configuration, see the More Information section of this article.

7. When directing clients, whether passive (typically browser clients) or active (rich clients), to the Federation Service, the host name the clients utilize must be the Federation Service Name.

Example of a failing scenario
The Federation Service Name is SSO.CONTOSO.COM. One of your Federation Servers is named ADFS.CONTOSO.COM. A SilverLight desktop client (active client) contacts the Federation Service at https://adfs.contoso.com/adfs/services/trust/mex to obtain metadata about the Federation Service. The active client fails because the SSL tunnel could not be created between client and server due to a subject (of the SSL certificate) and hostname (URL being used in the call) mismatch.

Example of a working scenario
The Federation Service Name is SSO.CONTOSO.COM. A browser client (passive client) browses to your claims-authentication-enabled SharePoint 2010 web site and is redirected to your Federation Service at https://sso.contoso.com/adfs/ls/?..... In this scenario, the Federation Service Name is being utilized consistently, and the request for a security token succeeds.

More Information
**
**If you find that you are not meeting all of the Federation Service Name requirements above, and you need to change your Federation Service Name, rest assured that you do not need to completely re-configure your Federation Service. See the following article for complete steps to change the Federation Service Name:
AD FS 2.0: How to Change the Federation Service Name

After reading this article, you may also find that you need to replace some certificates utilized by the Federation Service. For complete guidance on replacing AD FS 2.0 certificates, see the following article:
AD FS 2.0: How to Replace the SSL, Service Communications,Token-Signing, and Token-Decrypting Certificates

For a complete listing of AD FS 2.0 Content, see the AD FS 2.0 Content Map:
AD FS 2.0 Content Map