2:10 p.m.
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/DNSSRV...
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.