Forum Discussion

Pete_L_112517's avatar
Pete_L_112517
Icon for Nimbostratus rankNimbostratus
Jul 30, 2014

Kerberos & NTLMv2 via SSL VPN virtual server (mobile devices SSL VPN via APM)

Once again I'll start off here stating I'm quite green with F5. I can manage a lot of the basics, but this one I'm not sure on.

 

We are using F5 APM for Mobile Device and VPN on demand to internal web services (mainly Sharepoint). This connection is a single Virtual Server (mobile_ssl_vpn).

 

Currently, we only use Sharepoint servers with Kerberos SSO authentication and all works well. Now a requirement for a non IIS server (that can't have kerberos enabled) has come up to be available from mobile devices.

 

The way the vendor has set up our current SSO is:

 

  • an Access Profile for Kerberos Single Sign on. Inside this, a Kerberos SSO configuration is attached.
  • The Access Policy for this Access Profile is a straight allow pass through. No iRules attached either.
  • a Virtual Server (source and destination is 0.0.0.0/0) with the above access profile attached.
  • The kerberos and ntlm SSO configurations are configured and working for our domain (single Windows AD domain).

Essentially from what it looks like is that any traffic from any source to any destination the Kerberos SSO is applied (by a very roundabout method). The iOS devices have a user certificate and the F5 extracts the username and password and passes this to the server for a Kerberos challenge.

 

I can't work out how to apply a NTLM_v2 SSO policy to the mobile_ssl_vpn Virtual Server or traffic. I attempted to replicate the Kerberos configuration by create another 0.0.0.0/0 source and destination, but that obivously won't work.

 

My other thought here was to attach another access profile (with the NTLM config attached), which obviously can't be done.

 

I'd like to not have to keep giving the answer that internal services need to be configured with kerberos otherwise they can't be accessed.

 

  • Unfortunately no. NTLM authentication is a challenge/response protocol that requires knowledge of the user's password. Client certificate-based authentication does indeed impose some limitations, but consider the following additional possibilities:

     

    1. HTTP headers - your APM is a trusted proxy in front of the application (no traffic is passing to the application unless the client presents a certificate and that certificate is vetted). In some cases it's fairly simple to replace an application's typical user/pass authentication process with a header consumption function.

       

    2. Generalize user passwords - given that the users may never need their passwords for anything else, you could reset the passwords to some single, ridiculously long value, and let APM use that and the user's UPN to submit forms-based, Basic, NTLM, or other user/pass authentication. Admittedly this is a stretch, but I've had to do this for applications that simply do not support anything else but user/pass logon.

       

    3. SAML - if the application supports SAML 2.0, your APM IdP could request and validate the client certificate and send it a valid SAML assertion for logon.

       

  • You could be doing something different, but certificates rarely (if EVER) contain passwords. APM can extract any value from a certificate, but I'm willing to bet there's no password in those certs.

     

  • Is it safe to conclude that clients are authenticating with certificates? Certificates don't usually have passwords, so Kerberos SSO is a good choice for server side authentication. Server side NTLM, however, does require a password. If you're not providing that on the client side by any means, NTLM isn't going to be an option.