Bug 650593

note this RFE requires backend to actually support site based queries optimization first

*** Bug 795043 has been marked as a duplicate of this bug. ***

oved - can't this be limited to a specific site via the config key specifying which ldap servers to use?

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.

To keep things simple, what about only quering LDAP/Kerberos within a local subnet?

(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.

Can we get a PM ack on this?

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.

(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.

(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).

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".

Is this something we can get confirmed for RHEV 3.2?

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?

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?

(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.

Bryan,
IMHO we should fix (1) in a separate bug.

(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?

In reply to comment #42 - a bug was already opened -


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

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.

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

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

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