The Single Sign-On (SSO) feature is really interesting for most companies because it allows to sign-on once to access to all applications. For instance, you access to your computer once in the morning when you arrive to your office and you no longer have to sign-on again to your applications that day. However, when there are lots of applications, each one different from the other, new applications and old applications, the SSO configuration can be really tough. I’m going to write about how to configure SSO via NTLM with F5 BIG-IP APM which is useful for Windows networks.

First of all, APM can perform three types of 401-based challenge authentication: Basic, NTLM, and Kerberos. I wrote about Basic and Kerberos authentication last week. Basic authentication requires always user’s intervention. However, Kerberos and NTLM can enable users to seamlessly authenticate to the APM virtual server and allow it to either securely proxy connection to the backend application, leveraging Kerberos Constrained Delegation as the SSO mechanism, or acting as SAML IDP and issuing assertions to the SAML Service Providers based upon user identity extracted during NTLM authentication or Kerberos ticket.

NTLM is no longer used by new applications because NTLM passwords are weak and they can be brute-forced very easily with modern hardware. As a result, new applications use Kerberos instead of NTLM. However, companies may have still old applications which use NTLM. Therefore, companies which want SSO for all applications will have to configure all kind of authentication methods such as forms, Kerberos, SAML or even NTLM. 

NTLM Authentication messages

Configuring SSO via NTLM with F5 BIG-IP APM is really easy. First, and foremost, we have to create an NTLM Machine Account object to join the APM to the domain and create an unique computer object in Active Directory. Secondly, we need to create a “NTLM Auth Configuration” using the machine account name created previously. 

NTLM Machine Account

Unlike the other APM client side authentication methods, there’s no GUI option to enable APM client side NTLM. Consequently, we have to apply the External Client Authentication (ECA) profile to the APM virtual server via de TM shell. In addition, we have to create an iRule to enable ECA. I would also point out here that client side NTLM authentication is a bit different from Kerberos in that ECA is generally going to issue a 401 Unauthorized NTLM challenge on every new request. If this proves to add too much overhead, the iRule will allow NTLM to be processed once at the beginning of the session. The APM session cookie is used thereafter to maintain the session.

iRule to enable client side NTLM

Finally, we have to add a SSO Credential Mapping assigment in the access policy, which should be after the NTLM Auth, and add a NTLM SSO configuration object on the access profile (SSO / Auth Domains tab).

Visual Policy Editor configuration

That’s it my friends! Drop me a line with the first thing you are thinking.