Resources For IT Professionals
Post an article
Wikis - Page Details
  • First published by (Microsoft)
  • When: 11 Aug 2011 7:40 AM
  • Last revision by (5Microsoft Partne)
  • When: 3 Apr 2013 6:18 AM
  • Revisions: 3
  • Comments: 3
Options
RSSSubscribe to Article (RSS)
Can You Improve This Article?
Positively! Click Sign In to add the tip, solution, correction or comment that will help other users.

Report inappropriate content using these instructions.
Wiki  >  TechNet Articles  >  AD FS 2.0: Guidance for Selecting and Utilizing a Federation Service Name

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

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


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


, , , , , , , , , , , , [Edit tags]
Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • 3 Apr 2013 6:18 AM

    Matth CH edited Revision 1. Comment: Correct item number.

Page 1 of 1 (1 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Posted by
    on 11 Nov 2011 4:38 PM

    Regarding the very first point. i want some clarification.

    We have an NLB environment set with following properties:

    NLB Cluster Name:                 psnlb.domain.corp.xxx.com

    machine 1 in the cluster              a1.domain.corp.xxx.com

    machine 2 in the cluster              a2.domain.corp.xxx.com

    we have manually entered a dns record for psnlb.domain.corp.xxx.com to a static IP for resolution and nlb environment works fine

    Now, we have AD FS deployment in the above environment

    Since, we need to deploy AD FS as a Farm, we use Fsconfig.exe to createSQLFarm and JoinSQLFarm to add the federation servers

    so, on machine 1 (a1.domain.corp.xxx.com) and machine 2(a2.domain.corp.xxx.com) respectively Fsconfig.exe /CreateSQLFarm ..../FederationServiceName=psnlb.domain.corp.microsoft.com

    Fsconfig.exe /JoinSQLFarm ....../FederationServiceName=psnlb.domain.corp.microsoft.com

    Is this correct? i know we have to give Federation Service Name exactly as the DNS Name fo the Cluster....but i want to confirm it with you

  • Posted by
    on 16 Dec 2011 11:09 AM

    Correct, the Federation Service Name must equal the DNS name of the load balance. Take a network trace from a client and watch the Kerberos service ticket request (assuming this is an internal client capable of Kerberos authentication to the internal Federation Service).

  • Posted by
    on 3 Apr 2013 6:18 AM

    Matth CH edited Revision 1. Comment: Correct item number.

Page 1 of 1 (3 items)