When assisting our customers in migrating to online services such as Office 365, deploying Active Directory Federation Services (AD FS) is often a topic of conversation as an option to maintain a single sign-on experience.

Deploying AD FS without a proper environment assessment and planning may have you in a bit of trouble. AD FS 3.0, the latest iteration of AD FS on Server 2012 R2, bring with it many benefits which include but are not limited to multi-factor authentication support, flexible controls based on network location, per application access policies, Extranet Lockout, mobile device registration, SNI support, and so on. I will center this post around support for Server Name Indication (SNI), an extension of the TLS protocol, by AD FS and its internet facing Web Application Proxy.

If AD FS 3.0 meets all of your business and technical requirements for a migration to online services, let me provide some useful information that may resolve some authentication issues you may run into.

Why do I want concentrate on SNI support?
SNI basically allows a server to present multiple certificates on the same IP address and port number, which equals multiple HTTPS websites on a single IP Address without being bound to the same certificate. Pretty cool stuff, however, even though AD FS supports SNI, many devices and applications out there do not.

What happens when clients do not support SNI?
Clients that do not support SNI will not be able to complete authentication when contacting the AD FS server. The reason is because the client is not sending the Server Name extension in the SSL Client Hello. A short description of a basic SSL/TLS handshake is provided in this article but I am posting a descriptive image to allow easy following.

ssl handshake

Without the Server Name extension in the header, AD FS is unable to identify which certificate to serve and the connection will be reset.

Here is a list of some client we have run into that do not currently support SNI

  • CX Series Polycom
  • HP 4120 IP Phone Series
  • Active Sync on Android
  • Older browsers such as Internet Explorer on Windows XP (IE 7 and 8)

How do I deploy AD FS 3.0 and work around clients that do not support SNI?

If you decide on continuing to support non-SNI clients, you may configure a fallback certificate on all of the Active Directory Federation servers (both internal federation servers and external facing proxy servers) to prevent the connection reset when no Server Name extension is provided by defaulting to the certificate binding to http.sys.

Configuring failback http.sys certificate:

  1. Open CMD prompt as an administrator
  2. Enter the following in the CMD prompt window:
  3. Netsh http show sslcert
  4. Copy application GUID and certificate hash of the federation service
  5. Enter the following in the CMD prompt window:
  6. netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid={applicationguid}

Note: If there is no other service on the AD FS servers responding to HTTP requests, using ipport=0.0.0.0:443 will work. If this is not the case, specifying the IP address receiving these requests will need to be specified. However, specifying an IP address is not recommended as this would just establish precedence and not configure a failback certificate.

References:

Microsoft Support article referencing workaround for non-SNI compatible devices: “We can’t sign you in” error when you use an Android device to sign in to Lync Mobile

More information on Non-SNI compatible devices, IP Specific Fallback binding and other considerations: How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2