Can you believe it? It’s true, it’s true!  There’s a part 5.  What can I say? Times change; people change; software changes.  Active Directory Federation Services, (ADFS) is no exception.  While the BIG-IP with SAML 2.0 can alleviate the need for and ADFS infrastructure in many use cases, there are still organizations that need/want to continue utilizing ADFS.  Fortunately, regardless of which way you go, F5 can help.  So, in the spirit of free will, collaboration, and serving the greater good, (too much?), let’s talk about load balancing ADFS 3.0 with the BIG-IP.

As you may, or may not, recall the previous posts around BIG-IP and ADFS revolved around load balancing ADFS 2.0 and ADFS Proxy, replacing the ADFS Proxy with Access Policy Manager, and replacing the entire ADFS infrastructure with APM and SAML.  The good news is that these posts are still relevant with regards to ADFS 3.0 and the ADFS proxy replacement, (WAP); well for the most part anyway.


While there are numerous differences between ADFS 3.0 and previous versions, the most significant change with respect to providing HA and scalability for the ADFS 3.0 infrastructure is its use of Server Name Indication, (SNI).  To Successfully integrate a load balancing solution, ( including full reverse proxy), into the ADFS environment the device must support SNI.  The load balancing device must be able to present the server name to the backend host as part of the initial Client Hello.  Fortunately, the BIG-IP, (ver. 11.1.0 and later) supports this TLS protocol extension.

The rest of this post will provide guidance on enabling SNI support for ADFS 3.0 integration.  For overall guidance refer to parts one thru three of this series as well as the recently published ADFS 2.0 Deployment Guide.


SNI and the Server Profile

The BIG-IP provides a virtual server, (listener), that receives client SSL connections and subsequently intelligently passes traffic into a pool of ADFS/WAP servers.  Depending upon the organization’s infrastructure and security requirements, the BIG-IP can simply receive encrypted client connections and pass them through to the backend ADFS farm, (aka SSL tunneling).  However, the preferred method, (SSL bridging), receives encrypted clients connections; terminates and decrypts the traffic.  The traffic is then re-encrypted and sent to the backend application servers.  This method adds an additional layer of security since external traffic never directly connects to the internal domain-joined machines as well affording the ability to perform additional deep packet inspection.

SSL bridging back to the ADFS farm requires associating a server SSL profile to the virtual server.  Enabling SNI is simply a matter of specifying the server name on the associated server SSL profile, (see below).

1. Navigate to the appropriate profile;


2. Select ‘Advanced’ configuration and enter the FQDN of the backend ADFS service hostname.  The hostname will now be provided during the TLS negotiation. In the example below, the server name is ‘’, (refer to the highlighted field).  Like I said, simple!



Health Monitoring and SNI

Effectively monitoring the backend ADFS/WAP farm members is a little trickier but very doable.  Since the built-in HTTP monitors do not provide the server name as part of the TLS negotiation, using them will result in the being backend servers being incorrectly marked as down, (not good).

You could simply use a non-HTTP monitor, (ICMP being the most common), but that doesn’t provide a reasonable guarantee that the actual ADFS service is functioning.  Better than that, what we can do is create an external custom SNI enabled monitor that validates the service metadata and associate it to the pool.  It’s as easy as 1,2,3,… 4,5,6.

1. Copy the below script into notepad and save file with a .sh extension.

# These argument
# This script expects the following Name/Value pairs:
s supplied automatically for all external monitors:
# $1 = IP (nnn.nnn.nnn.nnn notation)
# $2 = port (decimal, host byte order)
# SNI  = the host name of the SNI-enabled site
# URI  = the URI to request
# RECV = the expected response
# Remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format)
NODE=`echo ${1} | sed 's/::ffff://'`
if [[ $NODE =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then
    # node is v4
    # node is v6
PIDFILE="/var/run/`basename ${0}`.sni_monitor_${SNI}_${PORT}_${NODE}"
# kill of the last instance of this monitor if hung and log current pid
if [ -f $PIDFILE ]
   echo "EAV exceeded runtime needed to kill ${SNI}:${PORT}:${NODE}" | logger -p local0.error
   kill -9 `cat $PIDFILE` > /dev/null 2>&1
# echo "$$" > $PIDFILE
curl-apd -k -v --resolve $SNI:$PORT:$NODE https://$SNI$URI 2>&1 > /dev/null | grep -i "${RECV}" 
rm -f $PIDFILE
if [ $STATUS -eq 0 ]
    echo "UP"

2. Upload the previously created file into the BIG-IP via the web interface. Navigate to ‘System’ –> ‘External Monitor Program List’ –> ‘Import’;


3. Browse to and select the file. Provide a name for the file and select ‘Import’;


4. Create a new external monitor utilizing the associate external file. Navigate to ‘Local Traffic’ –> ‘+’ sign;


5. Provide a name and select ‘External’ for the type. Select the previously created external program. The script provided requires three, (3) variables entered as name/value pairs. The variables are listed below. Select ‘Finished’;


RECV HTTP/1.1 200
URI /FederationMetadata/2007-06/FederationMetadata.xml


6. Associate the newly created monitor to the ADFS pool and/or the WAP pool. Select ‘Local Traffic’ –> ‘Pools’ –> ‘Pool List’.  Move the monitor into the active pane and select ‘Update’.


Additional Links:

Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”

Big-IP and ADFS Part 2 – “APM–An Alternative to the ADFS Proxy”

Big-IP and ADFS Part 3 – “ADFS, APM, and the Office 365 Thick Clients”

Big-IP and ADFS Part 4 – “What about Single Sign-Out?”

BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki

Active Directory Federation Services 3.0 Overview