Oh, I see it, we was blind all the time. The problem is in AD2 and AD3. AD1 and AD4 are fine. So yes the problem is on AD side but only for AD2 and AD3, that's why it worked for aaa-ldap-setup :) So actually this command shouldn't work for you: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD2.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' but this should: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD4.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
Nice catch ! I made tests on the 4 servers, with ldapsearch : OK : ldaps://AD1:636 Not working : ldaps://AD2:636 Not working : ldaps://AD3:636 OK : ldaps://AD4:636 So, half of AD don't like ldaps... Without using ldaps, it was working for the 3 first of them, but not AD3...(the search user was disabled on this one, I asked for it to be enabled, now ldapsearch works on this one, but only with ldap, not ldaps), so now : ldapsearch works using ldap:AD1,2,3,4, even when using LDAPTLS_PROTOCOL_MIN=3.2 In the SRV records when using dig _ldap._tcp.mydomain.com, there are 5 AD...One of them has been disabled but not removed from the SRV records. (but when using dig @AD1,2,3,4 _ldap_tcp.mydomain, I can see this 5th AD has been removed) Now the thing is : I don't have access to SRV records, I don't have access to AD configuration. For a strange reason it now works with "insecure", but not pool.default.ssl.enable or StartTLS.