[ovirt-users] Can't perform search after setting up an Active Directory

Ondra Machacek omachace at redhat.com
Tue May 31 12:19:59 UTC 2016


On 05/31/2016 12:03 PM, Alexis HAUSER wrote:
>> 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.



More information about the Users mailing list