Bug 766601

Summary: PRD35 - [RFE][AAA] Support Active Directory multi-domain setup
Product: [oVirt] ovirt-engine-extension-aaa-ldap Reporter: Yaniv Kaul <ykaul>
Component: Profile.adAssignee: Alon Bar-Lev <alonbl>
Status: CLOSED ERRATA QA Contact: Ondra Machacek <omachace>
Severity: medium Docs Contact:
Priority: unspecified    
Version: ---CC: alonbl, bazulay, bsettle, bugs, cww, iheim, juwu, lpeer, oourfali, pstehlik, rbalakri, Rhev-m-bugs, sherold, yeylon, ylavi, yzaslavs
Target Milestone: ---Keywords: FutureFeature, Improvement, Reopened
Target Release: 1.0.0Flags: alonbl: devel_ack+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-11 18:12:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1063095, 1142923, 1156165    

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