I have setup my F5 LTM 11.4.0 to have a virtual server that is receiving LDAP requests over 636. I have a profile setup with a cert/key for the client communication and a server profile setup with no cert/key (as I will use the cert being served up by the AD resource). I made 2 virtuals technically as I did one manually and the other through the iApp .. both failed. The client application attempts to connect and get a "unable to connect". Installed 2 third party tools and get the same type of error messages. When I setup the F5 LTM to have no cert/key on the client and whistle the transaction through - it works. Even when I use 636 on the server side, it works (appears to rule out the AD cert). However, once I put the client cert/key back in - it fails. So everything points to either a cert issue or an F5 configuration issue. I'm not sure how to troubleshoot it as the certificate really does look valid. (Correct SAN, Key Usage, SHA1 algorithm, etc.) Even the tcpdump analysis simply states: SYN/ SYN,ACK/ ACK/ cert exchange/ change cipher spec x3/ ACK/ RST,ACK - Why the hell did it send a reset packet? Any advice on how to troubleshoot this?

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: You're using a 3rd party tool and pointing LDAPS calls at a port 636 VIP that pools to port 636 servers? 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

Client unable to bind to LDAPs through LTM virtual for LDAPS

F5User-LB_25540
Nimbostratus
Mar 21, 2016
Bug in F5 When configuring LDAPS (Secure LDAP). Please Fix F5 to accept hostname for Secure LDAP server pool connections.

Why it is an issue with F5's... Microsoft by default creates a cert that uses FQHN on domain controllers. By default in order to connect via LDAPS to Microsoft domain controller you must connect using FQHN, NOT IP. Big F5 only accepts IPs for LDAP which makes secure LDAPS fail to Microsoft Domain Controllers.

Work Around: Add an additional certificate on the Domain controller with IP as subject alternative name?
- Amresh008
  Nimbostratus
  Feb 12, 2019
  @ F5User-LB, please update the BUG ID for this and as per my understanding, let's say that the ssl certificate has been issued on the name of xyz.com, with it's IP being 1.2.3.4, you suggest that another certificate be issued for 1.2.3.4 as the name ?
- F5User-LB_25540
  Nimbostratus
  Feb 12, 2019
  Active Directory Domain controllers use an internal active directory certificate authority. So xyz.local not xyz.com. The domain controller will be named DC01.xyz.local with a private or public IP of 1.2.3.4. Every server joined to Active directory automatically gets an internal certificate. My opinion, most admins are not going to do a public certificate for Active directory. Doesn't make sense and adds an un-needed level of complexity. The Certificate has Subject alternative name has DC01.xyz.local and no IP address specified. So to do LDAPS, the F5 needs to trust the active directory certificate authority AND accept a hostname of DC01.xyz.local instead of IP address to connect to the domain controller in order to secure LDAP (LDAPS). Because it is connecting with IP address and not hostname, Microsoft decides the connection is insecure and refuses the connection. This is the way I understand it to work after trying to connect with DNS and IP using LDAP testing tools and diving into the errors. You would need to contact Microsoft to get further information. P.S, it has been 2 years, I gave up and found an alternate method to authenticate that worked. Hope this helps you, but I'm not willing to spend more time on it.
Antish_293579
Nimbostratus
Jun 14, 2017
Hi Guys..can you pls help me with config that i have to do on LDAP VS on F5 to set up all of this...i am failing again & again in that. My client is Webserver connecting to AD via F5 & AD servers are in F5 pool.
Shawn_Conway
Cirrus
Feb 28, 2019
Did you ever get an answer on this? I was able to use the iapp (to Microsoft AD) and get it working (for browsing anyway) with client side certificate and server side certificate and without any. But, get some failures from an application trying to change passwords or move users to other OU's. Just started troubleshooting.

Forum Discussion

Client unable to bind to LDAPs through LTM virtual for LDAPS

Recent Discussions

Background Tasks

APM with EntraID as idP / request signed

Should config via cli rather than gui?

APM Modern Customization - modify Header in user-common.js and form in user-logon.js

Which process is consuming higher CPU

Related Content

LDAPS account interception through Virtual Server - Is it possible

Pass client cert based on POST data

F5 Client filtering based on cisco switch port info

VIP Client Logging "Not RFC1918"

Block Active-Sync on Virtual Server

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS