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.