>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. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users