Client unable to bind to LDAPs through LTM virtual for LDAPS

Hi Kevin,

Today we found the issue and wanted to share it on this thread. The issue appears to be a problem with Microsoft AD. Microsoft AD is not behaving correctly when the client requests a TLS1.2 connection, and the AD LDAP certificate is signed with RSA-SHA256.

If the certificate is signed with RSA-SHA1, no problem with TLS1.2.

Although this is appears to be an AD problem, the solution we implemented was to disable TLS1.2 from the protocol list on the server SSL profile. "!TLS1_2"

Now F5 negotiates over TLS1.1 and everything works.

The reason it was working when we did not decrypt at the F5 was because the client application was negotiating using TLS1.1 all along while the F5 was using TLS1.2 when we enabled the serverssl profile.

On a previous post I mentioned one of the scenario with re-encryption was working when plain text on the client side but after today we think we might of got lost in the dozen test cases we had gone through.

Thanks allot for engaging.

Pat

You need to assign a cert/key to your SSL server side profile. Otherwise, the LTM won't re-encrypt the connection toward your LDAP server. You can use the one loaded on your LDAP server and it should work like a champ.

SSL profiles strip off the SSL. By having a cert/key applied to your client SSL profile, but not your server SSL profile essentially means you are terminating the SSL on the LTM and running native LDAP between LTM and your server.

So just to be clear:

1. You're using a 3rd party tool and pointing LDAPS calls at a port 636 VIP that pools to port 636 servers?

    

2. You have client and server SSL profiles on the VIP (terminating and re-encrypting) and that fails?

    

Interesting. So does your LDAP configuration require something special to exist in the SSL? Normally LDAP is pretty flexible about the SSL layer. That said, there is a difference between LDAP and LDAPS besides the SSL layer. I'm assuming that if you point the client directly at the server and make an LDAPS call, it works. And if you disable both the client and server SSL profiles on the VIP (SSL pass through), then that too works with LDAPS. The reason why I make the distinction is because the following are not equivalent:

ldapsearch -H ldaps://server

ldapsearch -H ldap://server:636

Ldapsearch is a command line tool you can use on the BIG-IP to test LDAP, and even though the requests are using the same port, the former will work while the latter will not.

I've been working with Warren on this issue.

The fail occurs during the SSL Handshake. When we perform a TCP dump, we see the following.

Client Hello Server Hello Cipher suites negotiated Change cipher spec Change cipher spec

Than the F5 closes the connection (RST,ACK) and ltm logs show "SSL Handshake Failed". The client never gets to the point of attempting to bind to the directory.

We have reproduced this from various clients. The client SSL profile is currently set to the default with a cert/key. The certificate contains the vip FQDN in the CN= field and SubjectAltName. Virtual Server is of type "standard". Pretty basic really.

The Directories are Microsoft ADS.

Thanks

Just to clarify then, does it work if you point directly at the AD, and if you disable client and server SSL profiles on the VIP?

Here are the scenarios.

client => plain text => F5 => plain text => ADS:389 !WORKS!

client => plain text => F5 => SSL re-encrypt => ADS:636 !WORKS!

client => SSL PASS THROUGH => F5 => SSL PASS THROUGH => ADS:636 !WORKS!

client => SSL Client SSL Profile => F5 => SSL re-encrypt => ADS:636 !FAILS!

client => SSL Client SSL Profile => F5 => plain text => ADS:389 !FAILS!

As soon as we enable the Client-side SSL profile it fails with the SSL handshake failure.

Thanks

Here are the scenarios.

client => plain text => F5 => plain text => ADS:389 !WORKS!

client => plain text => F5 => SSL re-encrypt => ADS:636 !WORKS!

client => SSL PASS THROUGH => F5 => SSL PASS THROUGH => ADS:636 !WORKS!

client => SSL Client SSL Profile => F5 => SSL re-encrypt => ADS:636 !FAILS!

client => SSL Client SSL Profile => F5 => plain text => ADS:389 !FAILS!

As soon as we enable the Client-side SSL profile it fails with the SSL handshake failure.

Thanks

So is there now just one scenario where it's failing? If it's any consolation, I was able to get all of the above scenarios to work with the basic clientssl and serverssl profiles, Win2k8R2, and the "LDAP Admin" tool (http://ldapadmin.org). I would say at this point, if it's failing in a specific SSL handshake that you open up an SSLDUMP capture and see if that tells you why SSL may be failing.

This is my fully functional secureLDAP virtual configuration.

Steps I followed: 1) Requested certificate i.e. SecureLDAP.domain.com from our internal PKI team 2) Uploaded the cert ; thereafter created CLIENTSIDE ssl profile i.e. CLIENTSSL-secureldap 3) Identified Virtual Server IP i.e. 10.1.1.2; Created DNS record matching matching name in the cert 4) Started out by creating NODES of all AD servers 5) Created a Pool with NODES created in previous step 6) Created a virtual Server with IP : 10.1.1.2 Port 636 7) VS type - Standard ; Protocol : TCP ; Rest all default 8) Applied CLIENTSSL-secureLDAP under SSL PROFILE (Client) section 9) SSL PRofile (SERVER) : left empty 10) Source Address Translation : AutoMap 11) Under resources - assigned the POOL of AD servers created earlier.

Therafter downloaded, installed and launched Softerra LDAP Browser (FREE EDITION) Created a new profile with new LDAP name; defined the Bind username with password (IMP Step) First attempted to connection SSL connection check ; connection got refused Second time - attempted with SSL checkbox checked and connection got succeeded.

ltm virtual VS-int-secureLDAP { description "Internal SecureLDAP lookup against AD servers" destination 10.1.1.2:ldaps ip-protocol tcp mask 255.255.255.255 pool POOL-OF-MY-Active-Directory-Servers profiles { CLIENTSSL-secureldap { context clientside } tcp-lan-optimized { } } source 0.0.0.0/0 source-address-translation { type automap } vs-index 130 }