F5 BigIP APM (v.12) – SSO using AD & Kerberos – Quick How-To

Here is a quick “how-to” on main principles and practical configuration of Single Sign-On using F5 BigIP. There are quite a few good guides out there on Internet describing how to configure SSO using F5 ADCs in different scenarios. Somehow most of them are focused on the likes of Office 365 and access to public (usually cloud-based) resources from within a company. The cases of hosting of a number of applications with SSO across them are not that well documented by a reason. Relevant configuration guides do exist though.  I will try not to repeat them but instead highlight main principles of the approach and also specifics of the version 12 of BigIP firmware.

First of all – the scenario

Assume that we have two web applications exposed to Internet via F5 BigIP appliance. Both applications are hosted on Windows web servers which are members of Active Directory domain (they could well be running a Linux configured to authenticate in Windows via RADIUS, for instance – does not really matter). I used Windows Server 2012 but earlier versions 2008 and 2003 should work equally well.  All users of the application have user accounts in the AD but web visitors are external in relation to the organization hosting the application. In other words users’ computers do not belong to the domain in question. Thus we simulate a quite typical e-commerce scenario  where a company has a number  of applications exposed to Internet and all user accounts or these applications are maintained in the company’s Windows Active Directory.

We need to authenticate the client in AD using Kerberos. Web server #1 (for APP1) is configured to use only Kerberos and web server #2 is configured to use only NTLM.

The solution – main principles

As you must already be aware BigIP has a “full-proxy” architecture which basically means that you always have two connections – one on the client side and one on the server side. And when a client connects and you somehow authenticate that client, say, against AD using Kerberos, do not expect that the server, even being part of the same domain and configured to use Kerberos, will somehow magically authenticate your client. Magic does not work here, unfortunately. You will have to acquire the user credentials and somehow supply them to the back-end server.

When you look at the APM menu structure think about it this way – everything that is under AAA is for authentication on the client side:

and everything under SSO is for authentication on the server side:

So the idea is as follows:

The client tries to connect to one of the applications. If the BigIP does not see an authentication cookie for a particular FQDN or the whole domain it redirects the client to a logon page (generated by the APM itself). The logon page is the interface for a form based authentication in essence. It takes a user name and a password and then these credentials are used to authenticate the user against the AD. If the AD authentication is successful then an authentication cookie for the *.example.com domain is generated and sent back to the client. At the same time the BigIP supplies the same credentials to the relevant back-end server using appropriate authentication protocol (Kerberos or NTLM in our case).  The cookie and the credentials get stored in session tables. If the user tries to access the other application then his/her browser will supply the cookie, the cookie will get matched in a session table and relevant credentials will be used to establish connection on the server side transparently for the user.

Sounds simple and logical. Implementation is not that difficult either 🙂

Implementation

to follow shortly when I have a bit of free time in the evening for screen grabbing 🙂 …