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.