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 !
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.
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 ?
Configurations looks OK, so you hit some bug, can you please opent a
bz
for it? Thanks.
Ok, no problem, I'll do that.