5:20 a.m.
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 ?
5:57 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
8:47 a.m.
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 ?
9:51 a.m.
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
3:11 a.m.
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 ?
3:20 a.m.
On Thu, May 26, 2016 at 10:11 AM, Alexis HAUSER <
alexis.hauser(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3:22 a.m.
On Thu, May 26, 2016 at 10:11 AM, Alexis HAUSER <
alexis.hauser(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3:56 a.m.
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 ?
4:26 a.m.
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?
4:56 a.m.
> 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
6:10 a.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.
8:35 a.m.
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/DNSSRV...
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.
8:55 a.m.
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/DNSSRV...
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.
10:28 a.m.
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}"
12:58 p.m.
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
4:15 a.m.
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)
6:19 a.m.
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
8:55 a.m.
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.
5:03 a.m.
'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 ?
5:16 a.m.
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.
8:11 a.m.
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...
10:02 a.m.
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.
11:17 a.m.
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 ?
3:44 p.m.
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'
5:03 a.m.
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.
7:19 a.m.
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.
8:29 a.m.
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 ?
8:50 a.m.
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.
9:24 a.m.
> 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 ?
9:50 a.m.
On Tue, May 31, 2016 at 4:24 PM, Alexis HAUSER <
alexis.hauser(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3142
days inactive
3148
days old
29 comments
3 participants
participants (3)
-
Alexis HAUSER -
Martin Perina -
Ondra Machacek