
On 05/26/2016 03:35 PM, Alexis HAUSER wrote:
So it means that aaa-ldap then tries to do following: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -H ldaps://mydomain.com:389 -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' Which won't work, because you do ldaps on 389 port. (I guess it don't work, unless you changed default AD configuration) What you need to do is to specify a port for ldaps service. It's ussually done as I said before.
Yes that's true, it would work only with 636, not 389.
Yes, I understood that, and I said before, when I set "pool.default.serverset.srvrecord.service = ldaps", the parameter "vars.dns" is ignored by ovirt... When I use "vars.dns = dns://ad_server.mydomain.com", restart ovirt-engine, attempt to login and then check the logs, I see in the logs it is still trying to use "_ldaps._tcp.university.mydomain.com" instead... It really totally ignore the vars.dns parameter !
If I understand correctly, you misunderstood meaning of 'vars.dns' variable. This variables says what DNS server(s) should be used to send DNS queries, instead of the default one from /etc/resolv.conf. So if you specify: vars.dns = dns://ad_server.mydomain.com then aaa-ldap do following: $ dig @ad_server.mydomain.com _ldap._tcp.'pool.default.serverset.srvrecord.domain' SRV if you remove 'vars.dns' varibale then aaa-ldap does following: $ dig _ldap._tcp.'pool.default.serverset.srvrecord.domain' SRV so default DNS servers are used.
Now if use only "vars.dns = dns://ad_server.mydomain.com", and disable (comment) "pool.default.serverset.srvrecord.service = ldaps", in the logs, I see the right DNS used (ad_server.mydomain.com), but as you said, on the wrong port.
If I specify the port with "vars.dns = dns://ad_server.mydomain.com:636", I still see in the log it's trying to use port 389. Which mean the port number is totally ignore in "vars.dns" parameter.
To get more info how the DNSSRVRecordServerSet works you can read this: https://docs.ldap.com/ldap-sdk/docs/javadoc/com/unboundid/ldap/sdk/DNSSRVRec...
Interesting, but here _ldap_tcp is not used. And I'm not a java delopper, I won't know how to do with these classes etc...
It seems to confirm what I said : this DNS entry doesn't seem to exist.
Yes, and it should, or you need to change _ldap._tcp.university.mydomain.com SRV record to point on 636, or configure 389 port to accept ldaps. That's just my guess.
So does it mean there is no way to specify to ovirt config files that I want to use another DNS on 636 port ?
In config files no. The correct approach is configure DNS properly. Because SRV record provides you port on which that service operates. So I would suggest you either create new SRV record named 'ldaps' with port 636(in your AD DNS), or use startTLS with port 389.
Configurations looks OK, so you hit some bug, can you please opent a bz for it? Thanks.
Ok, no problem, I'll do that.