monitor for adfs server (GTM)

I can't cURL from my mac either (browser works), and it appears to be failing on the initiation of SSL, long before an HTTP user-agent can come into play. I have to assume your server is requiring some TLS extension that cURL isn't sending. Time to test with openssl...

Good ole Qualsys ssl Labs shows that the server-ciphers (in preferred order) are 0xc028, 0xc027, 0xc014, 0xc013, 0x9f, & 0x9e.

Every one of these is unknown by the f5s. How lucky am I?

Okay, so finally figured it out. 😉

To start, the ciphers 0xc028, 0xc027, 0xc014, 0xc013, 0x9f, and 0x9e all equate to:

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

respectively, and are all definitely supported by the BIG-IP. The definitions for these ciphers can be found here:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

You can verify the tmm native ciphers from your BIG-IP command line:

tmm --clientciphers NATIVE

and for openssl:

openssl ciphers |sed 's/:/\'$'\n/g'

In any case, the issue isn't one of cipher support, though your ADFS server is pretty darn restrictive in that regard. The issue is that the server requires SNI (server name indication) - a TLS extension that embeds the target hostname in the ClientHello message. It doesn't look like the built-in HTTPS monitor supports SNI, so you'd need to use an external scripted monitor. cURL would be an obvious choice here:

curl -k https://adfs.open-techs.com/adfs/ls/idpinitiatedsignon.aspx

But (this version of) curl will only send the SNI value if you use the hostname as the URL, versus the IP and port that you'd typically use in a server pool. So I had to drop back to openssl s_client. Here's an external monitor script that should do the job:

!/bin/bash

pidfile="/var/run/$MONITOR_NAME.$1..$2.pid"

if [ -f $pidfile ]
    then
    kill -9 -`cat $pidfile` > /dev/null 2>&1
fi

echo "$$" > $pidfile

node_ip=`echo $1 |sed 's/::ffff://'`
node_port=$2

getscript () {
    echo 'GET /adfs/ls/idpinitiatedsignon.aspx HTTP/1.1'
    echo 'Host: adfs.open-techs.com'
    echo ''
    while sleep 0; do
        echo 'quit\n'
    done
}

docurl () {
    IFS=$'\n'
    arr=($(getscript | openssl s_client -connect ${node_ip}:${node_port} -cipher 'ECDHE-RSA-AES256-SHA' -servername 'adfs.open-techs.com' 2>/dev/nul |grep -E '200 OK'))
    unset IFS
}

docurl

echo ${arr[0]}

if [ -n "${arr[0]}" ]
then
     Remove the pidfile before the script echoes anything to stdout and is killed by bigd
    rm -f $pidfile
    echo "up"
fi

 Remove the pidfile before the script ends
rm -f $pidfile

Notice in the openssl script I'm forcing a cipher string (ECDHE-RSA-AES256-SHA), sending the SNI with the -servername option, and then grepping for '200 OK' which then gets dumped into the array variable ${arr[0]}. If '200 OK' doesn't appear in the response, then the script sends nothing back to the monitor, otherwise it sends "up". You can obviously change what you're looking for in that grep statement.

You rock Kevin - Thank you! I've never had to use an external monitor, so I have some learning to do, but I'm confident that your script will work.

The adfs servers were created using the standard "role" which I guess is some sort of Microsoft template. Anyway, since it seems that adfs is not going away anytime soon, could you maybe suggest that f5 incorporate SNI into built-in HTTPS monitors?

Finally learned how to create an external monitor, using your script. Yes - it works! Thanks.