Re: [ovirt-users] Can't perform search after setting up an Active Directory
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.