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 766601 - PRD35 - [RFE][AAA] Support Active Directory multi-domain setup
Summary: PRD35 - [RFE][AAA] Support Active Directory multi-domain setup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: ovirt-engine-extension-aaa-ldap
Classification: oVirt
Component: Profile.ad
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: ---
: 1.0.0
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks: oVirt-AAA-LDAP rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2011-12-12 12:17 UTC by Yaniv Kaul
Modified: 2016-02-10 19:22 UTC (History)
16 users (show)

Fixed In Version: ovirt-engine-3.5.0_rc1
Doc Type: Enhancement
Doc Text:
The new LDAP generic provider ovirt-engine-extension-aaa-ldap fully supports multiple Active Directory forests.
Clone Of:
Environment:
Last Closed: 2015-02-11 18:12:01 UTC
oVirt Team: Infra
alonbl: devel_ack+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0174 normal SHIPPED_LIVE new package: ovirt-engine-extension-aaa-ldap 2015-02-11 22:40:02 UTC

Description Yaniv Kaul 2011-12-12 12:17:27 UTC
Description of problem:
It's all matter of:
1. Adding the correct substring to the DNS queries: _ldap._tcp.gc._msdcs.<fqdn> instead of just _ldap._tcp.<fqdn>
2. Doing it first, then the regular _ldap._tcp.<fqdn>

(3. Note that you'll end up with duplicate entries - as each GC is also a regular host that you'll get in #2)

4. Repeat Same with Kerberos.

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

How reproducible:


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


Expected results:


Additional info:

Comment 1 Itamar Heim 2013-01-08 09:19:16 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Comment 2 Yaniv Kaul 2013-01-08 11:41:53 UTC
The fix is quite small, and the value is significant, IMHO, re-opening.

Comment 3 Yair Zaslavsky 2013-01-20 10:34:31 UTC
(In reply to comment #0)
> Description of problem:
> It's all matter of:
> 1. Adding the correct substring to the DNS queries:
> _ldap._tcp.gc._msdcs.<fqdn> instead of just _ldap._tcp.<fqdn>
> 2. Doing it first, then the regular _ldap._tcp.<fqdn>
> 
> (3. Note that you'll end up with duplicate entries - as each GC is also a
> regular host that you'll get in #2)
> 
> 4. Repeat Same with Kerberos.
> 
> Version-Release number of selected component (if applicable):
> 3.0GA
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
>   
> Actual results:
> 
> 
> Expected results:
> 
> 
> Additional info:

Regarding the kerberos part - engine code has no control regarding the queries towards kerberos. Manage-domains can now optionally issue SRV records in order to construct a list of KDCS per domain or not (if the use dns flags are true, this is not required). What is the exact change required for kerberos? please elaborate.

Comment 4 Yaniv Kaul 2013-01-20 10:57:19 UTC
Personally, I'd use the exact same results we got for LDAP for Kerberos. While it is possible to separate the LDAP and Kerberos services to different servers, I have never practically seen such a deployment. 

Alternatively, just do the regular _kerberos._tcp.dc._msdcs.DnsDomainName and find all domain controllers that are also Kerberos servers, and compare with the list you've got for the LDAP GC (note - GC look for Forest names, not domain names!) and see if there's a match.

Comment 6 Alon Bar-Lev 2014-06-11 14:14:20 UTC
the new ldap implementation uses ldap only, so kerberos is irrelevant.

it is also using SAM account name and domain name to construct principal, so there is no need to go into global catalog.

avoiding using the user principal name enables that.

if in future we require to support user principal name we can also query the global catalog to perform the locate the domain, but I do not think this will be actually required.

Comment 8 Alon Bar-Lev 2014-09-23 21:39:17 UTC
Eventually, since active directory truncate long user names within sam account name, we must use user principal name and consult gc (lower performance).

Comment 11 errata-xmlrpc 2015-02-11 18:12:01 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.