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:
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
The fix is quite small, and the value is significant, IMHO, re-opening.
(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.
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.
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.
Eventually, since active directory truncate long user names within sam account name, we must use user principal name and consult gc (lower performance).
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