[ovirt-users] Can't perform search after setting up an Active Directory

Thu May 26 11:10:01 UTC 2016

On 05/26/2016 11:56 AM, Alexis HAUSER wrote:
>>> Where should I add this ? in /etc/hosts ? Somewhere in the ovirt config ? On the DNS server I'm using ?
>> On DNS you are using, usually on AD DNS.
>
> Well actually this DNS name doesn't exist and seem to be only an unspecified variable in ovirt...I have no reason to create a DNS entry for it.

If you run:

  $ dig @one_of_the_adservers.com _ldaps._tcp.mydomain.com SRV

you will get something like this:

  ;; ANSWER SECTION:
  _ldap._tcp.mydomain.com 600 IN SRV 0 100 389 server1.mydomain.com.
  _ldap._tcp.mydomain.com. 600 IN SRV 0 100 389 server2.mydomain.com.

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. To get more info how the 
DNSSRVRecordServerSet works you can read this:

https://docs.ldap.com/ldap-sdk/docs/javadoc/com/unboundid/ldap/sdk/DNSSRVRecordServerSet.html

>
> I think you missed my previous mail (with the error logs with different parameters for DNS) :)
>
>>> Actually, it's using ldaps yes. It doesnt solve my issue but I don't know where this DNS server comes from, I think it doesn't exist...
>
>> In AD startTLS usually works by default, strange. Why you disable it?
>
> Here we're using ldaps
>
>>
>> I tried to configure it by adding vars.dns = dns://one_of_the_adservers.com and the same with ":636" at the end, but none of them works, it's still trying to reach this weird address with underlines : _ldaps._tcp.university.mydomain.com
>
>> This error means, that you don't have SRV record for
>> '_ldaps._tcp.university.mydomain.com'. You need to create first, before
>> changing aaa-ldap configuration.
>
>> You can check if it's resolvable, by running following command:
>
>>  $ dig @one_of_the_adservers.com _ldaps._tcp.university.mydomain.com SRV
>
>
> dig @one_of_the_adservers.com _ldaps._tcp.university.mydomain.com SRV
>
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> @one_of_the_adservers.com _ldaps._tcp.university.mydomain.com SRV
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29630
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;_ldaps._tcp.university.mydomain.com. IN	SRV
>
> ;; AUTHORITY SECTION:
> university.mydomain.com. 3600	IN	SOA	one_of_the_adservers.com. another_server.com. 36174 900 600 86400 3600
>
> ;; Query time: 5 msec
> ;; SERVER: X.X.X.X#53(X.X.X.X)
> ;; WHEN: Thu May 26 11:36:43 2016
> ;; MSG SIZE  rcvd: 134
>
> 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.

>
>
>>> Actually that's what I said : only .properties file are detected. The problem is about the namespaces : when LDAP.properties file and AD.properties file are activated, the >>namespace suggested in the web interface in the user tab, when choosing AD, is the DN of the LDAP...Which seems to be a bug....Namespaces of everything are mixed...And if I >>select internal and then select again AD, a new namespace appears : * (from internal).
>>> This a weird behavior, right ?
>>>
>
>> Yes, that's weird, but I guess it's misconfigured. Doesn't your names of
>> extensions conflict?
>> I think that you combine values(names) 'ovirt.engine.extension.name' for
>> both AD and OpenLDAP. It should differ. Can you post those configurations?
>
> Actually I don't have any ovirt.engine.extension.name parameter in the aaa/.properties
> If you mean the authn and authz files, here they are (is that single line with ovirt-engine/ at the end of the first (AD) authz a normal thing...?)  :

No it's not, 'ovirt-engine/' shouldn't be there.

>
> AD :
>
> ovirt.engine.extension.name = AD-authz
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
> config.profile.file.1 = ../aaa/AD.properties
> ovirt-engine/
>
> ovirt.engine.extension.name = AD-authn
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
> ovirt.engine.aaa.authn.profile.name = AD
> ovirt.engine.aaa.authn.authz.plugin = AD-authz
> config.profile.file.1 = ../aaa/AD.properties
>
>
> LDAP :
>
> ovirt.engine.extension.name = public-authz
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
> config.profile.file.1 = ../aaa/public.properties
>
> ovirt.engine.extension.name = public-authn
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
> ovirt.engine.aaa.authn.profile.name = public
> ovirt.engine.aaa.authn.authz.plugin = public-authz
> config.profile.file.1 = ../aaa/public.properties
>
>

Configurations looks OK, so you hit some bug, can you please opent a bz 
for it? Thanks.

>
>