> 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.
Until administrators will fix AD servers, in order to use SSL you can
temporarily use following setup:
pool.default.serverset.single.server = AD1
pool.default.dc-resolve.enable = false
pool.default.ssl.startTLS = true
But this is only temporary solution and you should switch back to
'srvrecord' until AD is fixed.