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

[Ondra Machacek]

On 05/30/2016 03:11 PM, Alexis HAUSER wrote:
>> This is output of installation script
>> 'ovirt-engine-extension-aaa-ldap-setup', which is written in python, but
>> aaa-ldap extension in Java. So the strange thing is that you can connect
>> via
>> startTLS in python script, but later you can't connect with aaa-ldap
>> Java extension.
>> Can you please also share output of this command:
>>  $ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log
>> aaa login-user --profile=AD2 --user-name=mysearchuser
>> --password=pass:password
>> Hopefully it tell more. Thanks.
>
>
> Yes, Here it is :
>
> https://bpaste.net/show/4530b8075e1d
>
> I don't see much more than these SSL errors. What about you ?
>
>
> By the way, I've never found out what password should be used for the automatically generated .jks files from the ovirt-engine-extension-aaa-ldap-setup.
> That's why I use a generated .jks file (with keytool command). Anyway, I don't think there could be any problem with that, as I can use this cert for ldapsearch, I was just wondering what that default password of that automatically generated file could...
>

Default password is 'changeit' (without quotes).

Hmm, can you please try use the .jks file generated by aaa-ldap-setup 
tool? Just to be sure.

Anyway, the strange thing is that aaa-ldap-setup tool passes, but 
extension don't work later.
My guess is that it could be unsupported TLS version.

Can you please try running:

  LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H 
ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 
'mypaswd' -b 'CN=users,DC=something,DC=com'

and

   LDAPTLS_PROTOCOL_MIN=3.2 LDAPTLS_CACERT=/somewhere/myca.pem -Z -H 
ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 
'mypaswd' -b 'CN=users,DC=something,DC=com'

Does both commands succed?

If the later one don't work then probably your AD don't accept TLSv1.
You can change it byt this configuration options:

  pool.default.ssl.startTLSProtocol=TLSv1

to secure:

  pool.default.ssl.startTLSProtocol=TLSv1.2

or:

   pool.default.ssl.startTLSProtocol=SSLv3

But, you should use TLSv1.2.

If none of this is true, then I would try to enable insecure connection:

  pool.default.ssl.insecure = true

If it will work, then the problem is most probably with certificate.
If it won't work, then the problem is most probably with startTLS 
configuration on AD side.