Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 650593 - PRD35 - [RFE][AAA] Kerberos and LDAP should be performed against current AD site first (preferably, the global catalog in this site) using rhevm-manage-domains
Summary: PRD35 - [RFE][AAA] Kerberos and LDAP should be performed against current AD s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-extension-aaa-ldap
Version: 3.0.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 3.5.0
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks: 806907 oVirt-AAA-LDAP rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2010-11-07 09:21 UTC by Yaniv Kaul
Modified: 2018-12-03 17:12 UTC (History)
21 users (show)

Fixed In Version: ovirt-engine-3.5.0_rc1
Doc Type: Enhancement
Doc Text:
With the new LDAP implementation provided by the ovirt-engine-extension-aaa-ldap package, you can now query an LDAP service using the site's DNS service record. For example: pool.default.serverset.srvrecord.service = ldap pool.default.serverset.srvrecord.protocol = tcp pool.default.serverset.srvrecord.domain = MYSITE._sites.ad.dc._msdcs.my-activedirecotry.com For more information, see the ovirt-engine-extension-aaa-ldap package documentation.
Clone Of:
Environment:
Last Closed: 2015-02-11 18:11:52 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 70533 None None None Never
Red Hat Product Errata RHEA-2015:0174 normal SHIPPED_LIVE new package: ovirt-engine-extension-aaa-ldap 2015-02-11 22:40:02 UTC
Red Hat Bugzilla 584625 None None None Never

Description Yaniv Kaul 2010-11-07 09:21:42 UTC
Description of problem:
If RHEVM is in a domain, and
If RHEVM is in the same domain as the domain that is entered in the setup, then:

Please fetch the site name from registry (HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName) and put it in the configuration. 
Our AD/LDAP code in the future will use this information to try and locate the global catalog in its site (instead of querying some remote site).

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Itamar Heim 2010-12-14 06:43:51 UTC
note this RFE requires backend to actually support site based queries optimization first

Comment 5 Yaniv Kaul 2012-02-19 07:51:36 UTC
*** Bug 795043 has been marked as a duplicate of this bug. ***

Comment 8 Itamar Heim 2012-02-21 22:11:19 UTC
oved - can't this be limited to a specific site via the config key specifying which ldap servers to use?

Comment 9 Oved Ourfali 2012-02-22 07:27:38 UTC
Not exactly.
The rhevm/engine-manage-domains no longer changes the LdapServers entry. This entry was changed only when we supported SIMPLE (and not GSSAPI) authentication.
So, the engine performs DNS LDAP SRV records query for the domain, and uses these LDAP servers. Normally, that is the flow. However, if the LdapServers entry is changed manually to contain a specific address for a domain (domain:ldap_server, domain1:ldap_server...), then we only use this specific server for LDAP queries. 
It supports only one address per domain so if this LDAP server is not available then the query will fail.

We can add an option to set this key for a specific domain explicitly.

Is the Forest data available on the DNS? If so we might be able to limit the DNS query we do to a specific forest.

Comment 11 David Simmons 2012-02-23 16:45:51 UTC
To keep things simple, what about only quering LDAP/Kerberos within a local subnet?

Comment 12 Yaniv Kaul 2012-02-23 17:27:57 UTC
(In reply to comment #11)
> To keep things simple, what about only quering LDAP/Kerberos within a local
> subnet?

It's not going to make anything simple, and is not realistic. The chances of the AD to be on the local subnet is slim.

Comment 15 Bryan Yount 2012-03-12 18:27:10 UTC
Can we get a PM ack on this?

Comment 17 Ricky Nelson 2012-05-08 13:53:21 UTC
The workaround for specifying a single AD within the database worked for my strategic customer, Red Hat IT.

To be honest though, I don't identify this as an RFE, and neither does my customer. This is a bug. Right now, since there are numerous environments that depend on Kerberos integration, and most of these Kerberos domains consist of multiple nodes within a forest, specifying 1 AD server allows them to keep moving, but that's a single point of failure.

Thoughts? And feel free to shut me down. I just know that Red Hat IT will be running this environment with the workaround until RHEV has the ability to do site based queries.

Comment 18 Yaniv Kaul 2012-05-08 15:13:20 UTC
(In reply to comment #17)
> The workaround for specifying a single AD within the database worked for my
> strategic customer, Red Hat IT.
> 
> To be honest though, I don't identify this as an RFE, and neither does my
> customer. This is a bug. Right now, since there are numerous environments that
> depend on Kerberos integration, and most of these Kerberos domains consist of
> multiple nodes within a forest, specifying 1 AD server allows them to keep
> moving, but that's a single point of failure.
> 
> Thoughts? And feel free to shut me down. I just know that Red Hat IT will be
> running this environment with the workaround until RHEV has the ability to do
> site based queries.

Red Hat IT, last time I've checked (and debugged their Kerberos issue), did not have the DNS correctly configured for Kerberos. I doubt if it's been fixed since.

It's not a bug to try any correctly configured server from DNS, but:
1. You may not be able to reach it (because of firewall/network/other issues) - and we do not 'punish' non-responsive/slow servers fast/good enough (we have 'high' and 'low' rating, but that's about it).
2. It's far from being optimal. Asking from the US a Kerberos and LDAP server in China for credentials is not the best strategy.

For above reasons, I think it should be implemented in high priority. I also  think (aside from understanding which site you are in, which is complex to do automatically), it's simple to implement and the fallback to current behavior is also easy, relatively.

Comment 19 Ricky Nelson 2012-05-08 15:25:02 UTC
(In reply to comment #18)
> Red Hat IT, last time I've checked (and debugged their Kerberos issue), did not
> have the DNS correctly configured for Kerberos. I doubt if it's been fixed
> since.
> 

Good note, I'll see what records are configured just for reference.

> It's not a bug to try any correctly configured server from DNS, but:
> 1. You may not be able to reach it (because of firewall/network/other issues) -
> and we do not 'punish' non-responsive/slow servers fast/good enough (we have
> 'high' and 'low' rating, but that's about it).

One failure was due to the Kerberos server being outside of the firewall.

> 2. It's far from being optimal. Asking from the US a Kerberos and LDAP server
> in China for credentials is not the best strategy.
> 

One failure was due to a timeout from the above scenario (not China, but a server outside of the US).

Comment 20 Bryan Yount 2012-05-20 19:32:09 UTC
Why was this bumped from RHEV 3.1? This is an important feature for us to add to rhevm-manage-domains because the workaround listed involves creating a single point of failure for authentication. With the workaround, the customer only has a single AD server to query as indicated by Oved's comment #9:

> So, the engine performs DNS LDAP SRV records query for the domain, and uses
> these LDAP servers. Normally, that is the flow. However, if the LdapServers
> entry is changed manually to contain a specific address for a domain
> (domain:ldap_server, domain1:ldap_server...), then we only use this specific
> server for LDAP queries. 
> It supports only one address per domain so if this LDAP server is not
> available then the query will fail.

So, this makes the RHEV product more prone to failure if there's a single AD server that we're querying instead of a whole "site".

Comment 26 Bryan Yount 2012-09-10 18:37:46 UTC
Is this something we can get confirmed for RHEV 3.2?

Comment 29 Itamar Heim 2012-12-27 08:31:10 UTC
bryan - have you tried a workaround of specifying the dns/ip of the server you want to use via config, instead of the automatic detection?

Comment 40 Yair Zaslavsky 2013-01-10 05:19:11 UTC
Bryan -
I checked the code, and found the following:
1. My suggestion (due to a bug) will work only for one ldap server per domain.
2. Another limitation (maybe less of an issue, but still ) - all the ldap servers must have the same ldap port.

To provide a fast workaround, we can fix 1
(Current entries at ldapServers options at vdc_options look like:

mydomain.com:myldapserer1.mydomain.com,yourdomain.com:yourldapserver2.yourdomain.com

This means we have two domains (mydomain.com, yourdomain.com) and each one of them has one ldap server

What do you think?

Comment 41 Bryan Yount 2013-01-12 00:28:08 UTC
(In reply to comment #40)
> Bryan -
> I checked the code, and found the following:
> 1. My suggestion (due to a bug) will work only for one ldap server per
> domain.
> 2. Another limitation (maybe less of an issue, but still ) - all the ldap
> servers must have the same ldap port.

Ah, that makes sense. I would say number 2 isn't really an issue from what I can tell. Fixing 1 would be great.

> To provide a fast workaround, we can fix 1
> (Current entries at ldapServers options at vdc_options look like:
> 
> mydomain.com:myldapserer1.mydomain.com,yourdomain.com:yourldapserver2.
> yourdomain.com
> 
> This means we have two domains (mydomain.com, yourdomain.com) and each one
> of them has one ldap server. What do you think?

I think that sounds like a workable fix for now until rhevm-manage-domains can support a "sites" option. State Street will be excited for this fix.

Comment 42 Yair Zaslavsky 2013-01-13 05:41:15 UTC
Bryan,
IMHO we should fix (1) in a separate bug.

Comment 43 Bryan Yount 2013-01-14 23:08:03 UTC
(In reply to comment #42)
> Bryan,
> IMHO we should fix (1) in a separate bug.

Yeah, I agree. Do I need to open the bug or do you mind since you know exactly what needs to be fixed?

Comment 44 Yair Zaslavsky 2013-01-15 07:11:09 UTC
In reply to comment #42 - a bug was already opened -


https://bugzilla.redhat.com/show_bug.cgi?id=894681

Comment 47 Alon Bar-Lev 2014-03-16 20:53:02 UTC
I think that querying GC is bad practice, and is good for authentication but not authorization.

However, Generic LDAP provider will enable sysadmin to configure which servers to query for each phase.

Comment 48 Alon Bar-Lev 2014-06-11 13:41:23 UTC
new ldap implementation does not have a utility so utility notes has no resolve.

the new ldap implementation can be configured to query any srv record, including site srv record[1]

 _ldap._tcp. SiteName . _sites.dc._msdcs. DnsDomainName .

[1] http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

Comment 50 Ondra Machacek 2014-09-03 12:36:44 UTC
It's possible now to define site which should be queried.

pool.default.serverset.srvrecord.service = ldap
pool.default.serverset.srvrecord.protocol = tcp
pool.default.serverset.srvrecord.domain = 
MYSITE._sites.ad.dc._msdcs.my-activedirecotry.com

Comment 54 errata-xmlrpc 2015-02-11 18:11:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0174.html


Note You need to log in before you can comment on or make changes to this bug.