Can't perform search after setting up an Active Directory
Hi, I added an Active Directory server to RHEV, but I can't perform any search and I don't see any namespace in the interface. I'm able to perform search using with the same search user DN / passwd and certificate : LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -H ldaps://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' in the engine.log, if I grep warn, I can see the following messages : 2016-05-25 05:54:55,840 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-3) [] Illegal search: ADUSER@AD-authz:undefined: allnames=*: null 2016-05-25 05:54:55,843 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-3) [] Illegal search: ADGROUP@AD-authz:undefined: name=*: null 2016-05-25 05:54:58,160 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-9) [] Illegal search: ADUSER@AD-authz:undefined: allnames=*: null 2016-05-25 05:54:58,162 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-9) [] Illegal search: ADGROUP@AD-authz:undefined: name=*: null I also tried adding the following configuration but it didn't solve my problem : sequence-init.init.100-my-basedn-init-vars = my-basedn-init-vars sequence.my-basedn-init-vars.010.description = set baseDN sequence.my-basedn-init-vars.010.type = var-set sequence.my-basedn-init-vars.010.var-set.variable = simple_baseDN sequence.my-basedn-init-vars.010.var-set.value = CN=Users,DC=something,DC=com Any ideas ? By the way, if I didn't rename my .profile and auth* files from my LDAP configuration, I had the LDAP namespace suggested by the web interface in my AD domain when trying to perform a search. Is that a bug ?
On 05/25/2016 12:20 PM, Alexis HAUSER wrote:
Hi,
I added an Active Directory server to RHEV, but I can't perform any search and I don't see any namespace in the interface.
I'm able to perform search using with the same search user DN / passwd and certificate :
LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -H ldaps://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
in the engine.log, if I grep warn, I can see the following messages :
2016-05-25 05:54:55,840 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-3) [] Illegal search: ADUSER@AD-authz:undefined: allnames=*: null 2016-05-25 05:54:55,843 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-3) [] Illegal search: ADGROUP@AD-authz:undefined: name=*: null 2016-05-25 05:54:58,160 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-9) [] Illegal search: ADUSER@AD-authz:undefined: allnames=*: null 2016-05-25 05:54:58,162 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-9) [] Illegal search: ADGROUP@AD-authz:undefined: name=*: null
Can you please send what's happening during initialization of engine? (logs right after ovirt-engine is restarted). Or run this command and send output of file 'login.log': $ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log aaa login-user --profile=ad --user-name=some_user --password=pass:some_user_password
I also tried adding the following configuration but it didn't solve my problem :
sequence-init.init.100-my-basedn-init-vars = my-basedn-init-vars sequence.my-basedn-init-vars.010.description = set baseDN sequence.my-basedn-init-vars.010.type = var-set sequence.my-basedn-init-vars.010.var-set.variable = simple_baseDN sequence.my-basedn-init-vars.010.var-set.value = CN=Users,DC=something,DC=com
Any ideas ?
By the way, if I didn't rename my .profile and auth* files from my LDAP configuration, I had the LDAP namespace suggested by the web interface in my AD domain when trying to perform a search. Is that a bug ?
Not sure I understand. The name of the profile could be whatever, so it doesn't matter what is the name.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Can you please send what's happening during initialization of engine? (logs right after ovirt-engine is restarted).
Or run this command and send output of file 'login.log':
$ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log aaa login-user --profile=ad --user-name=some_user --password=pass:some_user_password
Yes, these are the logs when using the command you gave me, using the search user : https://bpaste.net/show/bbb0bc319765
By the way, if I didn't rename my .profile and auth* files from my LDAP configuration, I had the LDAP namespace suggested by the web interface in my AD domain when trying to >>perform a search. Is that a bug ?
Not sure I understand. The name of the profile could be whatever, so it doesn't matter what is the name.
I meant I had to disable the LDAP (openLDAP) profile, renaming the file with .save so ovirt doesn't detect them. If both profiles are activated, ovirt-web interface propose me the DN of the LDAP into AD (in namespace field)... Is that a bug or normal behavior ?
On 05/25/2016 03:47 PM, Alexis HAUSER wrote:
Can you please send what's happening during initialization of engine? (logs right after ovirt-engine is restarted).
Or run this command and send output of file 'login.log':
$ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log aaa login-user --profile=ad --user-name=some_user --password=pass:some_user_password
Yes, these are the logs when using the command you gave me, using the search user : https://bpaste.net/show/bbb0bc319765
You use 389 with SSL? I guess you wrongly specified it. But, if you want to use SSL and you have it on 636, then you should create new SRV dns records for example: _ldaps._tcp.university.mydomain.com ... 636 and then change: pool.default.serverset.srvrecord.service=ldaps But I guess you wanted to use startTLS with 389, which you can enable by adding: pool.default.ssl.startTLS=true and remove line: pool.default.ssl.enable=true Does it solve your issue?
By the way, if I didn't rename my .profile and auth* files from my LDAP configuration, I had the LDAP namespace suggested by the web interface in my AD domain when trying to >>perform a search. Is that a bug ?
Not sure I understand. The name of the profile could be whatever, so it doesn't matter what is the name.
I meant I had to disable the LDAP (openLDAP) profile, renaming the file with .save so ovirt doesn't detect them. If both profiles are activated, ovirt-web interface propose me the DN of the LDAP into AD (in namespace field)... Is that a bug or normal behavior ?
Hmm, that's strange, because only files with *.properties suffix should be detected and used. So yes please open bz that also other suffixes are loaded. Btw: you can add at the begging of each file (authz and authn) this line to disable it: ovirt.engine.extension.enabled = false
You use 389 with SSL? I guess you wrongly specified it. But, if you want to use SSL and you have it on 636, then you should create new SRV dns records for example: _ldaps._tcp.university.mydomain.com ... 636
Where should I add this ? in /etc/hosts ? Somewhere in the ovirt config ? On the DNS server I'm using ?
and then change: pool.default.serverset.srvrecord.service=ldaps But I guess you wanted to use startTLS with 389, which you can enable by adding: pool.default.ssl.startTLS=true and remove line: pool.default.ssl.enable=true Does it solve your issue?
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... 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 "2016-05-26 09:54:52,872 WARN [org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (ajp-/127.0.0.1:8702-7) [] [ovirt-engine-extension-aaa-ldap.authn::AD-authn] Cannot initialize LDAP framework, deferring initialization. Error: An error occurred while attempting to query DNS in order to retrieve SRV records with name '_ldaps._tcp.university.mydomain.com': javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name '_ldaps._tcp.campus.enst-bretagne.fr'"
I meant I had to disable the LDAP (openLDAP) profile, renaming the file with .save so ovirt doesn't detect them. If both profiles are activated, ovirt-web interface propose >>me the DN of the LDAP into AD (in namespace field)... Is that a bug or normal behavior ?
Hmm, that's strange, because only files with *.properties suffix should be detected and used. So yes please open bz that also other suffixes are loaded.
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 ?
On Thu, May 26, 2016 at 10:11 AM, Alexis HAUSER < alexis.hauser@telecom-bretagne.eu> wrote:
You use 389 with SSL? I guess you wrongly specified it. But, if you want to use SSL and you have it on 636, then you should create new SRV dns records for example: _ldaps._tcp.university.mydomain.com ... 636
Where should I add this ? in /etc/hosts ? Somewhere in the ovirt config ? On the DNS server I'm using ?
and then change: pool.default.serverset.srvrecord.service=ldaps But I guess you wanted to use startTLS with 389, which you can enable by adding: pool.default.ssl.startTLS=true and remove line: pool.default.ssl.enable=true Does it solve your issue?
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...
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
"2016-05-26 09:54:52,872 WARN [org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (ajp-/127.0.0.1:8702-7) [] [ovirt-engine-extension-aaa-ldap.authn::AD-authn] Cannot initialize LDAP framework, deferring initialization. Error: An error occurred while attempting to query DNS in order to retrieve SRV records with name '_ldaps._ tcp.university.mydomain.com': javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name '_ldaps._ tcp.campus.enst-bretagne.fr'"
I meant I had to disable the LDAP (openLDAP) profile, renaming the file with .save so ovirt doesn't detect them. If both profiles are activated, ovirt-web interface propose >>me the DN of the LDAP into AD (in namespace field)... Is that a bug or normal behavior ?
Hmm, that's strange, because only files with *.properties suffix should be detected and used. So yes please open bz that also other suffixes are loaded.
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 ?
If I understand correctly, you have only one AD server/domain, right? If so, what do you want to use profile LDAP.properties for?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Thu, May 26, 2016 at 10:11 AM, Alexis HAUSER < alexis.hauser@telecom-bretagne.eu> wrote:
You use 389 with SSL? I guess you wrongly specified it. But, if you want to use SSL and you have it on 636, then you should create new SRV dns records for example: _ldaps._tcp.university.mydomain.com ... 636
Where should I add this ? in /etc/hosts ? Somewhere in the ovirt config ? On the DNS server I'm using ?
and then change: pool.default.serverset.srvrecord.service=ldaps But I guess you wanted to use startTLS with 389, which you can enable by adding: pool.default.ssl.startTLS=true and remove line: pool.default.ssl.enable=true Does it solve your issue?
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...
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
Please don't port 636 for DNS server, 636 is only for LDAPS protocol: vars.dns = dns://one.of.adservers.com
"2016-05-26 09:54:52,872 WARN [org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (ajp-/127.0.0.1:8702-7) [] [ovirt-engine-extension-aaa-ldap.authn::AD-authn] Cannot initialize LDAP framework, deferring initialization. Error: An error occurred while attempting to query DNS in order to retrieve SRV records with name '_ldaps._ tcp.university.mydomain.com': javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name '_ldaps._ tcp.campus.enst-bretagne.fr'"
I meant I had to disable the LDAP (openLDAP) profile, renaming the file with .save so ovirt doesn't detect them. If both profiles are activated, ovirt-web interface propose >>me the DN of the LDAP into AD (in namespace field)... Is that a bug or normal behavior ?
Hmm, that's strange, because only files with *.properties suffix should be detected and used. So yes please open bz that also other suffixes are loaded.
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 ?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Please don't port 636 for DNS server, 636 is only for LDAPS protocol: vars.dns = dns://one.of.adservers.com Ok, but as I explained, even without using 636, the result is the same.
When using the option "pool.default.serverset.srvrecord.service = ldaps" and "dns://one.of.adservers.com" I get the following error (it still trying to point to the wrong adress) "{Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=An error occurred while attempting to query DNS in order to retrieve SRV records with name 'ldaps._tcp.university.mydomain.com': javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name 'ldaps._tcp.university.mydomain.com', Extkey[name=EXTENSION_INVOKE_RESULT;type=class java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2}" when disabling (commenting the line) "pool.default.serverset.srvrecord.service = ldaps" I get the following error : "{Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=An error occurred while attempting to connect to server one.of.adservers.com:389: java.io.IOException: LDAPException(resultCode=91 (connect error), errorMessage='Unable to verify an attempt to to establish a secure connection to 'one.of.adservers.com:389' because an unexpected error was encountered during validation processing: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated') caused by LDAPException(resultCode=91 (connect error), errorMessage='Unable to verify an attempt to to establish a secure connection to 'one.of.adservers.com:389' because an unexpected error was encountered during validation processing: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated')LDAPException(resultCode=91 (connect error), errorMessage='Unable to verify an attempt to to establish a secure connection to 'one.of.adservers.com:389' because an unexpected error was encountered during validation processing: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated') caused by javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated, Extkey[name=EXTENSION_INVOKE_RESULT;type=class java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2}" So I think I need a way to combine both of them, but using the right dns, what option can do that ?
On 05/26/2016 10:11 AM, Alexis HAUSER wrote:
You use 389 with SSL? I guess you wrongly specified it. But, if you want to use SSL and you have it on 636, then you should create new SRV dns records for example: _ldaps._tcp.university.mydomain.com ... 636
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.
and then change: pool.default.serverset.srvrecord.service=ldaps But I guess you wanted to use startTLS with 389, which you can enable by adding: pool.default.ssl.startTLS=true and remove line: pool.default.ssl.enable=true Does it solve your issue?
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?
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
"2016-05-26 09:54:52,872 WARN [org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (ajp-/127.0.0.1:8702-7) [] [ovirt-engine-extension-aaa-ldap.authn::AD-authn] Cannot initialize LDAP framework, deferring initialization. Error: An error occurred while attempting to query DNS in order to retrieve SRV records with name '_ldaps._tcp.university.mydomain.com': javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name '_ldaps._tcp.campus.enst-bretagne.fr'"
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
I meant I had to disable the LDAP (openLDAP) profile, renaming the file with .save so ovirt doesn't detect them. If both profiles are activated, ovirt-web interface propose >>me the DN of the LDAP into AD (in namespace field)... Is that a bug or normal behavior ?
Hmm, that's strange, because only files with *.properties suffix should be detected and used. So yes please open bz that also other suffixes are loaded.
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?
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. 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.
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...?) : 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
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/DNSSRVRec...
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.
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.
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 ?
Configurations looks OK, so you hit some bug, can you please opent a bz for it? Thanks.
Ok, no problem, I'll do that.
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.
This is really weird : If I manually run : dig _ldap._tcp.my_forst_name.com SRV I can see the 4 AD servers in ANSWER, AUTHORITY and ADDITIONAL SECTION If I use : pool.default.serverset.srvrecord.service = ldaps In the logs I see this : "An error occurred while attempting to query DNS in order to retrieve SRV records with name '_ldaps._tcp.my_forest_name.com':" The same happens with : dig @any_of_the_4_AD_server _ldap._tcp.my_forest_name.com SRV So why dig can resolve it but not ovirt ?
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.
Interesting, now I understand better...
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.
"ldaps" is also a kind of conventional "microsoft SRV record" like _ldaps_tcp ? With startTLS I didn't have any success (and I don't really get why) : "2016-05-26 17:23:36,535 WARN [org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (ajp-/127.0.0.1:8702-6) [] [ovirt-engine-extension-aaa-ldap.authn::AD2-authn] Cannot initialize LDAP framework, deferring initialization. Error: 00000000: LdapErr: DSID-0C090CF0, comment: Error initializing SSL/TLS, data 0, vece" "{Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=00000000: LdapErr: DSID-0C090CF0, comment: Error initializing SSL/TLS, data 0, vece, Extkey[name=EXTENSION_INVOKE_RESULT;type=class java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2}"
On 05/26/2016 05:28 PM, Alexis HAUSER wrote:
This is really weird : If I manually run : dig _ldap._tcp.my_forst_name.com SRV
^_ldap
I can see the 4 AD servers in ANSWER, AUTHORITY and ADDITIONAL SECTION
If I use : pool.default.serverset.srvrecord.service = ldaps In the logs I see this : "An error occurred while attempting to query DNS in order to retrieve SRV records with name '_ldaps._tcp.my_forest_name.com':"
^_ldaps
The same happens with : dig @any_of_the_4_AD_server _ldap._tcp.my_forest_name.com SRV
^_ldap
So why dig can resolve it but not ovirt ?
you use '_ldaps._tcp' in ovirt not '_ldap._tcp' as in dig. And '_ldaps' is what's missing in your DNS.
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.
Interesting, now I understand better...
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.
"ldaps" is also a kind of conventional "microsoft SRV record" like _ldaps_tcp ?
Unfortunatelly using '_ldaps._tcp' is not any standart. But that's what usually people do if they can't use startTLS.
With startTLS I didn't have any success (and I don't really get why) :
"2016-05-26 17:23:36,535 WARN [org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (ajp-/127.0.0.1:8702-6) [] [ovirt-engine-extension-aaa-ldap.authn::AD2-authn] Cannot initialize LDAP framework, deferring initialization. Error: 00000000: LdapErr: DSID-0C090CF0, comment: Error initializing SSL/TLS, data 0, vece"
"{Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=00000000: LdapErr: DSID-0C090CF0, comment: Error initializing SSL/TLS, data 0, vece, Extkey[name=EXTENSION_INVOKE_RESULT;type=class java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2}"
This message doesn't say much. Can you please send full Java exception stack trace? Don't forget to also remove lines: pool.default.ssl.enable = true pool.default.serverset.srvrecord.service = ldaps
you use '_ldaps._tcp' in ovirt not '_ldap._tcp' as in dig. And '_ldaps' is what's missing in your DNS.
Oh ! you're right, I didn't even see that ! I was confused by all this. I'll ask someone to add these SRV records.
Unfortunatelly using '_ldaps._tcp' is not any standart. But that's what usually people do if they can't use startTLS.
So, in a way we could say that Ovirt expect users to use Start_TLS with AD, but not ldaps ? Should I open a RFE about this ?
This message doesn't say much. Can you please send full Java exception stack trace?
Yes, here is the full log when trying to use StartTLS : https://bpaste.net/show/5719b47c45e5 Please tell me if it gives you see anything in it. (and again, thanks for all your help)
On 05/27/2016 11:15 AM, Alexis HAUSER wrote:
you use '_ldaps._tcp' in ovirt not '_ldap._tcp' as in dig. And '_ldaps' is what's missing in your DNS.
Oh ! you're right, I didn't even see that ! I was confused by all this. I'll ask someone to add these SRV records.
Unfortunatelly using '_ldaps._tcp' is not any standart. But that's what usually people do if they can't use startTLS.
So, in a way we could say that Ovirt expect users to use Start_TLS with AD, but not ldaps ? Should I open a RFE about this ?
Well startTLS is prefered always before ldaps, not only in AD. So maybe you can open documentation bug, so we will properly describe how this DNS SRV server set works and what needs to be done, to get it properly working.
This message doesn't say much. Can you please send full Java exception stack trace?
Yes, here is the full log when trying to use StartTLS : https://bpaste.net/show/5719b47c45e5
Please tell me if it gives you see anything in it.
Unfortunatelly no, I can only see that's something wrong with SSL. 'ovirt-engine-extensions-tool' logs would be more helpfull. Btw, did you installed it via 'ovirt-engine-extension-aaa-ldap-setup'? There you can choose startTLS, so you can avoid typos in configuration.
(and again, thanks for all your help)
you're welcome
Well startTLS is prefered always before ldaps, not only in AD. So maybe you can open documentation bug, so we will properly describe how this DNS SRV server set works and what needs to be done, to get it properly working.
Ok, I'll do that. I counted : that will be my 18th bug in my list (counting also the RFE and docs bugs, not only the software bugs, I didn't report all of them yet) for RHEV/ovirt... I should be payed by Red Hat team ;) (by the way, I hope the stability of RHEV will increase)
Unfortunatelly no, I can only see that's something wrong with SSL.
That's also the only thing I saw.
'ovirt-engine-extensions-tool' logs would be more helpfull.
Here it is : https://bpaste.net/show/a166df875909
Btw, did you installed it via 'ovirt-engine-extension-aaa-ldap-setup'? There you can choose startTLS, so you can avoid typos in configuration.
Yes that's what I did, I made a different profile for all cases, using the tool.
'ovirt-engine-extensions-tool' logs would be more helpfull.
Here it is : https://bpaste.net/show/a166df875909 I can't see anything else than this SSL error and what seems to be a missing python module : "ImportError: No module named dnf" Can you see something else or do you have any idea of what I could do to solve this StartTLS problem ?
On 05/30/2016 12:03 PM, Alexis HAUSER wrote:
'ovirt-engine-extensions-tool' logs would be more helpfull.
Here it is : https://bpaste.net/show/a166df875909
I can't see anything else than this SSL error and what seems to be a missing python module : "ImportError: No module named dnf"
Can you see something else or do you have any idea of what I could do to solve this StartTLS problem ?
This is output of installation script 'ovirt-engine-extension-aaa-ldap-setup', which is written in python, but aaa-ldap extension in Java. So the strange thing is that you can connect via startTLS in python script, but later you can't connect with aaa-ldap Java extension. Can you please also share output of this command: $ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log aaa login-user --profile=AD2 --user-name=mysearchuser --password=pass:password Hopefully it tell more. Thanks.
This is output of installation script 'ovirt-engine-extension-aaa-ldap-setup', which is written in python, but aaa-ldap extension in Java. So the strange thing is that you can connect via startTLS in python script, but later you can't connect with aaa-ldap Java extension. Can you please also share output of this command: $ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log aaa login-user --profile=AD2 --user-name=mysearchuser --password=pass:password Hopefully it tell more. Thanks.
Yes, Here it is : https://bpaste.net/show/4530b8075e1d I don't see much more than these SSL errors. What about you ? By the way, I've never found out what password should be used for the automatically generated .jks files from the ovirt-engine-extension-aaa-ldap-setup. That's why I use a generated .jks file (with keytool command). Anyway, I don't think there could be any problem with that, as I can use this cert for ldapsearch, I was just wondering what that default password of that automatically generated file could...
On 05/30/2016 03:11 PM, Alexis HAUSER wrote:
This is output of installation script 'ovirt-engine-extension-aaa-ldap-setup', which is written in python, but aaa-ldap extension in Java. So the strange thing is that you can connect via startTLS in python script, but later you can't connect with aaa-ldap Java extension. Can you please also share output of this command: $ ovirt-engine-extensions-tool --log-level=FINEST --log-file=login.log aaa login-user --profile=AD2 --user-name=mysearchuser --password=pass:password Hopefully it tell more. Thanks.
Yes, Here it is :
https://bpaste.net/show/4530b8075e1d
I don't see much more than these SSL errors. What about you ?
By the way, I've never found out what password should be used for the automatically generated .jks files from the ovirt-engine-extension-aaa-ldap-setup. That's why I use a generated .jks file (with keytool command). Anyway, I don't think there could be any problem with that, as I can use this cert for ldapsearch, I was just wondering what that default password of that automatically generated file could...
Default password is 'changeit' (without quotes). Hmm, can you please try use the .jks file generated by aaa-ldap-setup tool? Just to be sure. Anyway, the strange thing is that aaa-ldap-setup tool passes, but extension don't work later. My guess is that it could be unsupported TLS version. Can you please try running: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' and LDAPTLS_PROTOCOL_MIN=3.2 LDAPTLS_CACERT=/somewhere/myca.pem -Z -H ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' Does both commands succed? If the later one don't work then probably your AD don't accept TLSv1. You can change it byt this configuration options: pool.default.ssl.startTLSProtocol=TLSv1 to secure: pool.default.ssl.startTLSProtocol=TLSv1.2 or: pool.default.ssl.startTLSProtocol=SSLv3 But, you should use TLSv1.2. If none of this is true, then I would try to enable insecure connection: pool.default.ssl.insecure = true If it will work, then the problem is most probably with certificate. If it won't work, then the problem is most probably with startTLS configuration on AD side.
Default password is 'changeit' (without quotes). Hmm, can you please try use the .jks file generated by aaa-ldap-setup tool? Just to be sure.
I still have the same error with the default jks
Anyway, the strange thing is that aaa-ldap-setup tool passes, but extension don't work later. My guess is that it could be unsupported TLS version. Can you please try running: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' and LDAPTLS_PROTOCOL_MIN=3.2 LDAPTLS_CACERT=/somewhere/myca.pem -Z -H ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
Does both commands succed?
Yes, they both succeed.
If the later one don't work then probably your AD don't accept TLSv1. You can change it byt this configuration options: pool.default.ssl.startTLSProtocol=TLSv1 to secure: pool.default.ssl.startTLSProtocol=TLSv1.2 or: pool.default.ssl.startTLSProtocol=SSLv3 But, you should use TLSv1.2. If none of this is true, then I would try to enable insecure connection: pool.default.ssl.insecure = true
I still get the same SSL error with all these options (even insecure)
If it will work, then the problem is most probably with certificate. If it won't work, then the problem is most probably with startTLS configuration on AD side.
So, do you think it's startTLS on AD side ?
On 05/30/2016 06:17 PM, Alexis HAUSER wrote:
Default password is 'changeit' (without quotes). Hmm, can you please try use the .jks file generated by aaa-ldap-setup tool? Just to be sure.
I still have the same error with the default jks
Anyway, the strange thing is that aaa-ldap-setup tool passes, but extension don't work later. My guess is that it could be unsupported TLS version. Can you please try running: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' and LDAPTLS_PROTOCOL_MIN=3.2 LDAPTLS_CACERT=/somewhere/myca.pem -Z -H ldap://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
Does both commands succed?
Yes, they both succeed.
If the later one don't work then probably your AD don't accept TLSv1. You can change it byt this configuration options: pool.default.ssl.startTLSProtocol=TLSv1 to secure: pool.default.ssl.startTLSProtocol=TLSv1.2 or: pool.default.ssl.startTLSProtocol=SSLv3 But, you should use TLSv1.2. If none of this is true, then I would try to enable insecure connection: pool.default.ssl.insecure = true
I still get the same SSL error with all these options (even insecure)
If it will work, then the problem is most probably with certificate. If it won't work, then the problem is most probably with startTLS configuration on AD side.
So, do you think it's startTLS on AD side ?
Oh, I see it, we was blind all the time. The problem is in AD2 and AD3. AD1 and AD4 are fine. So yes the problem is on AD side but only for AD2 and AD3, that's why it worked for aaa-ldap-setup :) So actually this command shouldn't work for you: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD2.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' but this should: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD4.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
Oh, I see it, we was blind all the time. The problem is in AD2 and AD3. AD1 and AD4 are fine. So yes the problem is on AD side but only for AD2 and AD3, that's why it worked for aaa-ldap-setup :) So actually this command shouldn't work for you: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD2.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' but this should: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD4.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
Nice catch ! I made tests on the 4 servers, with ldapsearch : OK : ldaps://AD1:636 Not working : ldaps://AD2:636 Not working : ldaps://AD3:636 OK : ldaps://AD4:636 So, half of AD don't like ldaps... Without using ldaps, it was working for the 3 first of them, but not AD3...(the search user was disabled on this one, I asked for it to be enabled, now ldapsearch works on this one, but only with ldap, not ldaps), so now : ldapsearch works using ldap:AD1,2,3,4, even when using LDAPTLS_PROTOCOL_MIN=3.2 In the SRV records when using dig _ldap._tcp.mydomain.com, there are 5 AD...One of them has been disabled but not removed from the SRV records. (but when using dig @AD1,2,3,4 _ldap_tcp.mydomain, I can see this 5th AD has been removed) Now the thing is : I don't have access to SRV records, I don't have access to AD configuration. For a strange reason it now works with "insecure", but not pool.default.ssl.enable or StartTLS.
On 05/31/2016 12:03 PM, Alexis HAUSER wrote:
Oh, I see it, we was blind all the time. The problem is in AD2 and AD3. AD1 and AD4 are fine. So yes the problem is on AD side but only for AD2 and AD3, that's why it worked for aaa-ldap-setup :) So actually this command shouldn't work for you: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD2.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' but this should: LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -Z -H ldap://AD4.mydomain.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com'
Nice catch ! I made tests on the 4 servers, with ldapsearch :
OK : ldaps://AD1:636 Not working : ldaps://AD2:636 Not working : ldaps://AD3:636 OK : ldaps://AD4:636
So, half of AD don't like ldaps...
Without using ldaps, it was working for the 3 first of them, but not AD3...(the search user was disabled on this one, I asked for it to be enabled, now ldapsearch works on this one, but only with ldap, not ldaps), so now :
ldapsearch works using ldap:AD1,2,3,4, even when using LDAPTLS_PROTOCOL_MIN=3.2
In the SRV records when using dig _ldap._tcp.mydomain.com, there are 5 AD...One of them has been disabled but not removed from the SRV records. (but when using dig @AD1,2,3,4 _ldap_tcp.mydomain, I can see this 5th AD has been removed)
Now the thing is : I don't have access to SRV records, I don't have access to AD configuration.
For a strange reason it now works with "insecure", but not pool.default.ssl.enable or StartTLS.
Until administrators will fix AD servers, in order to use SSL you can temporarily use following setup: pool.default.serverset.single.server = AD1 pool.default.dc-resolve.enable = false pool.default.ssl.startTLS = true But this is only temporary solution and you should switch back to 'srvrecord' until AD is fixed.
Until administrators will fix AD servers, in order to use SSL you can temporarily use following setup: pool.default.serverset.single.server = AD1 pool.default.dc-resolve.enable = false pool.default.ssl.startTLS = true But this is only temporary solution and you should switch back to 'srvrecord' until AD is fixed.
Thank you, this actually works. Yes, I'll remove it as soon as possible. Now with RHEV + AD, it seems better than RHEV + LDAP for groups : it finds most of the groups a user belongs to. RHEV + LDAP is only able to find one group a user belongs to (which is not the same group found when I search the same user with ldapsearch...Still not able to solve that mystery....) By the way, how would you change the default password associated with the .jks certificate automatically generated from the interactive setup ?
On 05/31/2016 03:29 PM, Alexis HAUSER wrote:
Until administrators will fix AD servers, in order to use SSL you can temporarily use following setup: pool.default.serverset.single.server = AD1 pool.default.dc-resolve.enable = false pool.default.ssl.startTLS = true But this is only temporary solution and you should switch back to 'srvrecord' until AD is fixed.
Thank you, this actually works. Yes, I'll remove it as soon as possible.
Now with RHEV + AD, it seems better than RHEV + LDAP for groups : it finds most of the groups a user belongs to. RHEV + LDAP is only able to find one group a user belongs to (which is not the same group found when I search the same user with ldapsearch...Still not able to solve that mystery....)
That's very strange, we test it and it works for us. But you said you use more namingContexts than one, right? It could be the problem as we support only one.
By the way, how would you change the default password associated with the .jks certificate automatically generated from the interactive setup ?
Run this command: $ keytool -storepasswd -keystore /path/to/jks/x.jks It will ask you for old and new password.
Thank you, this actually works. Yes, I'll remove it as soon as possible. Now with RHEV + AD, it seems better than RHEV + LDAP for groups : it finds most of the groups a user belongs to. RHEV + LDAP is only able to find one group a user belongs to >>(which is not the same group found when I search the same user with ldapsearch...Still not able to solve that mystery....)
That's very strange, we test it and it works for us. But you said you use more namingContexts than one, right? It could be the problem as we support only one.
Which attribute is used by RHEV/ovirt to guess which user a group belong (or the controry), in the case of LDAP and in the case of AD ? I can see that not all attributes are filled in the AD/LDAP database here.
Run this command: $ keytool -storepasswd -keystore /path/to/jks/x.jks It will ask you for old and new password.
Thank you, I'll ask rhev-docs to add this to the documentation, as they make you generate a new certificate even when using the automatic setup, which makes the automatically generated certificate useless. By the way, is there a list of all the possible options/values of .properties file ?
On Tue, May 31, 2016 at 4:24 PM, Alexis HAUSER < alexis.hauser@telecom-bretagne.eu> wrote:
Thank you, this actually works. Yes, I'll remove it as soon as possible. Now with RHEV + AD, it seems better than RHEV + LDAP for groups : it finds most of the groups a user belongs to. RHEV + LDAP is only able to find one group a user belongs to >>(which is not the same group found when I search the same user with ldapsearch...Still not able to solve that mystery....)
That's very strange, we test it and it works for us. But you said you use more namingContexts than one, right? It could be the problem as we support only one.
Which attribute is used by RHEV/ovirt to guess which user a group belong (or the controry), in the case of LDAP and in the case of AD ? I can see that not all attributes are filled in the AD/LDAP database here.
It depends on what profile do you include in /etc/ovirt-engine/aaa/<PROFILE_NAME>.properties: 1) Included ad.properties are defined in /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties and here are attribute mappings: attrmap.map-principal-record.attr.PrincipalRecord_DN.map = _dn attrmap.map-principal-record.attr.PrincipalRecord_ID.map = objectGUID attrmap.map-principal-record.attr.PrincipalRecord_ID.conversion = BASE64 attrmap.map-principal-record.attr.PrincipalRecord_NAME.map = name attrmap.map-principal-record.attr.PrincipalRecord_PRINCIPAL.map = userPrincipalName attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = displayName attrmap.map-principal-record.attr.PrincipalRecord_DEPARTMENT.map = department attrmap.map-principal-record.attr.PrincipalRecord_FIRST_NAME.map = givenName attrmap.map-principal-record.attr.PrincipalRecord_LAST_NAME.map = sn attrmap.map-principal-record.attr.PrincipalRecord_TITLE.map = title attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = mail attrmap.map-group-record.attr.GroupRecord_DN.map = _dn attrmap.map-group-record.attr.GroupRecord_ID.map = objectGUID attrmap.map-group-record.attr.GroupRecord_ID.conversion = BASE64 attrmap.map-group-record.attr.GroupRecord_NAME.map = name attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = description 2) In case of LDAP, please take a look at include=<XYZ.properties> to find out what profile are you using
Run this command: $ keytool -storepasswd -keystore /path/to/jks/x.jks It will ask you for old and new password.
Thank you, I'll ask rhev-docs to add this to the documentation, as they make you generate a new certificate even when using the automatic setup, which makes the automatically generated certificate useless.
By the way, is there a list of all the possible options/values of .properties file ?
No tool for that, you need to investigate properties files. Please start reading README.profile in aaa-ldap package, which contains doc about the structure of each file.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (3)
-
Alexis HAUSER -
Martin Perina -
Ondra Machacek