{"id":875,"date":"2015-04-23T11:36:40","date_gmt":"2015-04-23T09:36:40","guid":{"rendered":"https:\/\/www.vioreliftode.com\/?p=875"},"modified":"2016-04-14T13:38:34","modified_gmt":"2016-04-14T11:38:34","slug":"adfs-3-0-wap-sni-and-network-load-balancing","status":"publish","type":"post","link":"https:\/\/www.vioreliftode.com\/index.php\/adfs-3-0-wap-sni-and-network-load-balancing\/","title":{"rendered":"ADFS 3.0, WAP, SNI and Network Load Balancing"},"content":{"rendered":"

So you decide to build an ADFS 3.0 farm using Windows Server 2012 R2. You configure the farm properly and the ADFS checks performed directly on the ADFS servers are working fine.<\/p>\n

 <\/p>\n

The next step is to load balance the traffic between the two ADFS nodes. To achieve this functionality you will use a NLB solution. Let’s assume you will use IIS + ARR<\/a>.
\nPlease note this scenario is valid also for other NLB solutions. I mention here IIS + ARR for the simple fact IIS + ARR are Microsoft solutions and a lot of companies are leveraging first the Microsoft solution (before looking into alternatives).<\/em><\/p>\n

 <\/p>\n

After you properly configure the IIS + ARR to load balance the traffic between the two ADFS servers, you try to verify the connection usually by connecting at https:\/\/[yourSTSfqdn]<\/em>\/adfs\/ls\/idpinitiatedsignon.htm<\/strong>, but you receive a HTTP 502.<\/p>\n

502 – Web server received an invalid response while acting as a gateway or proxy server.<\/span><\/p>\n

There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.<\/span><\/p>\n

The page will be available soon.<\/span><\/p>\n

\u00a0\"ADFS_3.0_WAP_SNI_and_Network_Load_Balancing_01\"<\/a><\/p>\n

 <\/p>\n

What\u2019s the reason?<\/strong>
\nADFS 3.0<\/span> (part of Windows Server 2012 R2) is by default<\/span> setup (by the ADFS Configuration Wizard) to require Server Name Indication<\/span>.
\nWeb Application Proxy<\/span> (part of Windows Server 2012 R2, replacement of ADFS proxy) is also by default<\/span> setup (by the Web Application Proxy Configuration Wizard) to require Server Name Indication<\/span>.<\/p>\n

 <\/p>\n

Like the WebDav client does not support Server Name Indication (SNI)<\/a> situation, ARR is non-SNI capable.
\nThe majority of articles I read about SNI are mentioning a list of SNI compatible web browsers. Yes, the web browsers probably represent 99% of the HTTP clients, but the rest of the HTTP based clients are applications which can also be non-SNI capable.<\/em>
\n To make sure I am not misunderstood: SNI is not evil. In fact I like it and I am using as much as possible. \u000bFrom Wikipedia:\u00a0\u201cServer Name Indication (SNI) is an extension to the TLS protocol that indicates to what hostname the client is attempting to connect at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP\/1.1 virtual hosting for HTTPS.”<\/em><\/p>\n

 <\/p>\n

What does ARR extension mainly does, is to receive your (client) HTTP request and route it based on specific load balancing algorithm to a specific server (part of a farm configuration). The server replies back to NLB (IIS + ARR) the HTTP response and after that the NLB sends the HTTP response back to the client. So, at some point ARR is behaving as a HTTP client.<\/p>\n

 <\/p>\n

What\u2019s the problem?
\n<\/strong>\u000bThe problem in this case is: ARR is non-SNI capable, which means the request sent by the NLB (IIS+ARR) node to the ADFS\/WAP servers does not contains “server_name” extension as part of the SSL\/TLS handshake.<\/p>\n

 <\/p>\n

Example of a successful ADFS request sent by a SNI capable client.<\/span>
\n\"ADFS_3.0_WAP_SNI_and_Network_Load_Balancing_02\"<\/a><\/p>\n

 <\/p>\n

Example of an unsuccessful ADFS request sent by ARR (non-SNI capable).<\/span>
\n\"ADFS_3.0_WAP_SNI_and_Network_Load_Balancing_03\"<\/a>
\nas result, without the Server Name extension in the header, ADFS is unable to identify which certificate to serve and the connection will be reset by server.
\n\"ADFS_3.0_WAP_SNI_and_Network_Load_Balancing_04\"<\/a><\/p>\n

 <\/p>\n

Well, as mentioned earlier, ADFS 3.0 and WAP are by default setup to listen and respond to HTTPS connections where “server_name” extension is present as part of the SSL\/TLS handshake.\u000bIt’s the same reason why the non-SNI web browsers don’t work with by default ADFS 3.0 and WAP configurations.<\/p>\n

 <\/p>\n

 <\/p>\n

Solution<\/strong>
\nThe solution is to make ADFS 3.0 and WAP to respond also to the HTTPS requests sent by non-SNI capable clients. Basically we need to configure an http.sys fallback certificate and is 100% supported by Microsoft (it’s just not part of the default configuration – and somehow I agree with this decision).
\nSo, on all ADFS and WAP nodes load balanced using IIS+ARR is necessary to configure an http.sys fallback certificate. Basically these servers will bind the ADFS\/WAP listeners to HTTPS and will use one certificate to encrypt all the traffic performed through TCP 443. From best practices point of view this configuration is totally fine (because for servers like ADFS and WAP is not recommended to install and configure other roles who need to be bound to HTTPS).
\nA full description can be found here -> http:\/\/blogs.technet.com\/b\/applicationproxyblog\/archive\/2014\/06\/19\/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx<\/a>.<\/p>\n

 <\/p>\n

 <\/p>\n

How to configure an http.sys fallback certificate?
\n<\/strong>make sure you replace XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with the thumbprint certificate used to secure the AFDS communications (from command line execute “netsh http show sslcert”, or check the certificate)
\n\"ADFS_3.0_WAP_SNI_and_Network_Load_Balancing_05\"<\/a>
\n<\/em><\/p>\n

 <\/p>\n

On all ADFS 3.0 servers execute the following command<\/span><\/p>\n

\r\nnetsh http add sslcert ipport=0.0.0.0:443 certhash=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX appid={5d89a20c-beab-4389-9447-324788eb944a}\r\n<\/pre>\n
 <\/p>\n
On all WAP servers execute the following command<\/span><\/p>\n
\r\nnetsh http add sslcert ipport=0.0.0.0:443 certhash=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX appid={f955c070-e044-456c-ac00-e9e4275b3f04}\r\n<\/pre>\n
 <\/p>\n
Once the change is performed the connections performed by non-SNI clients will be accepted by ADFS \/ WAP servers (in this case ARR will be able to establish TLS communications with ADFS\/WAS => so an IIS+ARR based NLB can be used to load balance the ADFS traffic).
\n\"ADFS_3.0_WAP_SNI_and_Network_Load_Balancing_06\"<\/a><\/p>\n
 <\/p>\n
How can I find out if my ADFS\/WAS server accepts only SNI requests?
\n<\/strong>When the ADFS\/WAS server doesn’t have a fallback certificate configured, the following registry key is empty: HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\HTTP\\Parameters\\SslBindingInfo<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
So you decide to build an ADFS 3.0 farm using Windows Server 2012 R2. You configure the farm properly and the ADFS checks performed directly on the ADFS servers are working fine.   The next step is to load balance the traffic between the two ADFS nodes. To achieve this functionality you will use a … Continue reading ADFS 3.0, WAP, SNI and Network Load Balancing<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[32,75,74],"tags":[77,78,80,76,79],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p4NfDd-e7","_links":{"self":[{"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/posts\/875"}],"collection":[{"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/comments?post=875"}],"version-history":[{"count":0,"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/posts\/875\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/media?parent=875"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/categories?post=875"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vioreliftode.com\/index.php\/wp-json\/wp\/v2\/tags?post=875"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}