I tried to plug ovirt using my company AD. But I have a problem, the DNS srv records are not well managed and I can't use them so I changed pool.default.serverset.type from srvrecord to failover.

But it was not enough, it was still using those invalid records. It was used by pool.default.dc-resolve.default.serverset.type too. I found that after digging in the source. I wonder why it should be specified twice. Why pool.default.dc-resolve.default.serverset and pool.default.serverset are different ?

I also need to specify search.ad-resolve-upn.search-request.baseDN because it didn't found it any more. I wonder if it's related. My aaa property file: include = <ad.properties> vars.domain = MYDOME vars.user = A_DN vars.password = the_password vars.forest = my_forest pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password} pool.default.serverset.type = failover pool.default.serverset.failover.1.server = server1 pool.default.serverset.failover.2.server = server2 pool.default.ssl.startTLS = true pool.default.ssl.truststore.file = trust.jks pool.default.ssl.truststore.password = pool.default.ssl.startTLSProtocol = TLSv1.2 pool.default.connection-options.connectTimeoutMillis = 500 pool.default.dc-resolve.enable = true pool.default.dc-resolve.default.serverset.type = failover pool.default.dc-resolve.serverset.failover.1.server = server1 pool.default.dc-resolve.serverset.failover.2.server = server2 search.ad-resolve-upn.search-request.baseDN = BASE_DN _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

> Le 19 avr. 2016 à 17:35, Ondra Machacek <omachace(a)redhat.com&gt; a écrit : > > On 04/19/2016 04:37 PM, Fabrice Bacchella wrote: >> I tried to plug ovirt using my company AD. >> >> But I have a problem, the DNS srv records are not well managed and I can't use them so I changed pool.default.serverset.type from srvrecord to failover. > > With AD you should use srvrecord, unless you have somehow miscofigured AD. > Can you please elaborate more what does it mean 'DNS srv records are not well managed'? The command dig +short _ldap._tcp.dsone.3ds.com any | wc -l return 122 lines. Out of that, I can only use less than 10, all other generates timeout. I don't know if it's firewall or forgotten DC that generate that. There is no way I can use srvrecord. This domain is totally out of my reach, I have to take it as is.

> > Can you please send engine log or if you are on 3.6, then use this command to test and provide log: > $ ovirt-engine-extensions-tool --log-level=FINEST --log-file=ad-search.log aaa search --entity-name=userX --extension-name=ad-authz I kill it after 1h of execution, and a 1.6MB log file, when I have pool.default.serverset.type = srvrecord pool.default.serverset.srvrecord.domain = ${global:vars.domain} With pool.default.serverset.type = failover and pool.default.connection-options.connectTimeoutMillis = 500, I got: time ovirt-engine-extensions-tool bla real 1m29.264s user 0m6.837s sys 0m0.291s and a 278KB log file. And with my setup (pool.default.serverset.type and pool.default.dc-resolve.default.serverset.type set to failover, pool.default.connection-options.connectTimeoutMillis = 500), I got real 0m5.084s user 0m6.343s sys 0m0.164s and a 199KB log file. With pool.default.dc-resolve.enable = false, the results is the same than with failover for every one.

> > Btw: Do you use mutli domain AD setup? Or only single domain? I think it's a single domain, but I'm not a Microsoft expert at all.

> Le 20 avr. 2016 à 10:16, Ondra Machacek <omachace(a)redhat.com&gt; a écrit : > > On 04/19/2016 07:46 PM, Fabrice Bacchella wrote: >> >>> Le 19 avr. 2016 à 17:35, Ondra Machacek <omachace(a)redhat.com&gt; a écrit : >>> >>> On 04/19/2016 04:37 PM, Fabrice Bacchella wrote: >>>> I tried to plug ovirt using my company AD. >>>> >>>> But I have a problem, the DNS srv records are not well managed and I can't use them so I changed pool.default.serverset.type from srvrecord to failover. >>> >>> With AD you should use srvrecord, unless you have somehow miscofigured AD. >>> Can you please elaborate more what does it mean 'DNS srv records are not well managed'? >> >> The command >> dig +short _ldap._tcp.dsone.3ds.com any | wc -l >> return 122 lines. Out of that, I can only use less than 10, all other generates timeout. I don't know if it's firewall or forgotten DC that generate that. There is no way I can use srvrecord. >> This domain is totally out of my reach, I have to take it as is. > > ok, that's not good, but if some of the domains which are working are in same site, you can use 'domain-conversion'(works only with srvrecord): > pool.default.serverset.srvrecord.domain-conversion.type = regex > pool.default.serverset.srvrecord.domain-conversion.regex.pattern = ^(?<domain>.*)$ > pool.default.serverset.srvrecord.domain-conversion.regex.replacement = WORKING-SITE._sites.${domain} What is that supposed to do ? All my DC are in the form xx-xxx-dcs99.${domain} and I have to pick a in this list. dig _sites.${domain} return nothing for me what a regex will do ?

> Is that your case? Can you please share log of extensions-tool, so we can better understand > your problem and provide better help. I have no knowledge about AD, I'm a 100% linux sysadmin and just use AD as an LDAP server, so all those forest/GC are unknown things for me. I will send that in a private mail.