SSL Hardening for Web Application Proxy Servers

The Web Application Proxy (WAP) Servers act as an SSL termination instance towards the Internet. External connections that try to access the Active Directory Federation Services (ADFS) farm or internal applications that are published via the Web Application Proxy will terminate their SSL connections at the Web Application Proxy. Unfortunately, the Windows 2012R2 server default settings allow a lot of SSL Cipher Suites that are publically known as weak or “outdated” like SSLv3, DES encryption and key length below 128bit. The preferred Server Ciphers of a freshly installed and updated Windows 2012R2 server are SSLv3    168 bits        DES-CBC3-SHA TLSv1    256 bits        AES256-SHA Therefore from a network security standpoint it is mandatory to harden the SSL settings on the Web Application Servers BEFORE opening the WAP server in the DMZ for incoming Internet connections. The best option to harden the SSL settings on a standalone Windows Server 2012R2 is to modify the Local Group Policy: From a commandline run: “gpedit.msc”. In the computer section navigate to “Administrative Templates – Network – SSL Configuration Settings”  Edit the “SSL Cipher Suite Order”:

The listed Cipher suites can be exported and adjusted to the actual security requirements by deleting the unwanted Ciphers from the list. As a minimum all combinations that contain SSL2, SSL3, DES, 3DES, MD5 elements are deleted as well as all combination with a cipher length below 128bit.

Information

The list needs to be sorted in a way that the preferred SSL ciphers are on top.

Afterwards create a string of the values from list and separate each cipher by “,” without any blank. Don’t leave a “,” at the end of the string. The input box in the GPO menu has a limited size. Make sure that your string fits into this limit. If not, delete further ciphers which are not widely used.

Warning!

It looks like simply activating the new local GPO by running “gpupdate /force” is not sufficient. Please reboot the WAP servers one-by-one after setting the SSL cipher policy

However, before we open the firewall, an internal test should be executed to validate the SSL hardening. You can run the sslscan tool (you can download from here sslscan) from another computer in the DMZ or the WAP server itself. DNS resolving of the federation or application name must resolve to the external Load Balancer or interface of the WAP server. Example for SSL Server Ciphers before SSL Hardening (left side) and after SSL Hardening (right side):

When the Web Application Proxy server has been connected to the Internet finally, a second check can be achieved by using one of the proven Internet based SSL scan tools, e.g. https://www.ssllabs.com/ssltest/ .

You can find a string of the recommended SSL ciphers for importing into local GPO here.

Active Directory Federation Services 3.x Technology Basics

Active Directory Federation Services (AD FS) provides Web single-sign-on to authenticate a user to related external hosted Web applications. AD FS performs this by securely sharing digital identity and entitlement rights or claims across security and enterprise boundaries.

AD FS supports distributed authentication and authorization over the Internet to provide access to resources that are offered by trusted partners.

Another aspect of ADFS technology can be found in providing external access from Internet connections to internal resources. In that case the ADFS server can provide an additional layer of security by offering various pre-authentication methods, while the second part of the ADFS technology, the Web Application Proxy server (WAP) acts as a Reverse Proxy by terminating the incoming SSL connections.

In version 3.0 of the ADFS technology, the WAP server cannot be run without ADFS server in the backend, which stores the configuration of the WAP servers. The WAP servers themselves are “stateless” and therefore easy to scale up behind a Layer 4 Load Balancer.

ADFS Server Farms

The Active Directory Federation Services technology can be scaled out by deploying multiple ADFS servers in a farm model. The servers share the same configuration information which is stored in a database on each server (Windows Internal Database (WID) model) or in a central SQL store. In most of the implementations, the WID model is used.
For using the WID model, the configuration can only be modified on the Primary ADFS server and is then replicated to all other ADFS servers of the same farm.
To find the Primary Server use the command “get-adfssyncproperties” on one of the ADFS servers:

Web Application Proxy server

The Web Application Proxy Server is typically the Internet facing component of the Active Directory Federation Services technology. Located in the DMZ, the Web Application Proxy (WAP) servers act as reverse proxy server and terminate the incoming SSL connects from the Internet to the published applications.
Web Application Proxy servers are N to 1 connected to a specific ADFS server (farm). Multiple WAP servers can be easily configured for Layer 4 Loadbalancing.
Since WAP servers are “stateless”, they do not store any persistent configuration information, but load the information from the Primary ADFS server. Therefore a WAP server cannot exist without underlying ADFS server and needs to be installed after the ADFS farm has been deployed.

When acting as reverse proxy for client access using IWA (Integrated Windows Authentication) or when serving non claims aware application access based on Kerberos, the WAP servers must be able to perform Kerberos Constrained Delegation. The WAP server presents a Kerberos token on behalf of the accessing client or user, which in consequence requires the WAP server to be a member of an Active Directory domain. Unfortunately the domain membership of the WAP server means to open a lot more ports from the DMZ to the internal network, which is a disadvantage from network security perspective.

For that reason, applications that do not require Kerberos Constrained Delegation should always be published on non domain based WAP servers, where the exception is to publish applications on domain based WAP servers.

Example for ADFS Farm structure: