Feature #6352


Updated DC locator for SMB and idmap

Added by Gordon Ross over 6 years ago. Updated over 6 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


We need the Domain Controller (DC) Locator code updated per. the MS spec.

We then need to centralize the functionality, so that all parts of the system use the same DC.

Design notes:

Before the implementation of this fix (enhancement) there are three DC Locators in the system: (a) one in idmap, (b) one in smbd, and (c) one in the kerberos library, where it locates a KDC. Worse, none of them are compliant with the specification mentioned above.

With Active Directory, we need to have exactly one entity keep track of who is our current DC, and have all parts of the system use that. To do otherwise is not only inefficient, but can cause failures when we update information on one DC, and another part of the system uses a different DC. (AD updates may be delayed, so that second DC may not have the latest information immediately - a form of "split brain".)

We have chose the instance of a DC Locator in idmap to be the "one true DC Locator", mostly because idmap has the best service lifetime for this purpose. By contrast, the SMB service may stop or restart during operations like join domain, which would perturb our information about our current DC and potentially cause a switch to a new DC at an unfortunate time.

Later, the DC Locator in idmap, along with those parts of idmap and smbd that make outbound requests to our AD server should be relocated into a new service (probably named "netlogon", to be like Windows).
That new service would aggregate requests and cache results, similar in spirit to the name service cache deamon but with AD capabilities such as name-to-SID and SID-to-name lookup. For now, those functions are split between idmap and smbd.

The idmap daemon (idmapd) uses the DC Locator code in libadutils. That implementation is enhanced to include the "LDAP Ping" mechanism (a connectionless LDAP query) to select a responsive AD server. This is important because the DNS reponse to our SRV record lookup to find AD servers may return a long list of potential AD servers, many of which may be either turned off or not reachable from our network. The LDAP ping mechanism efficiently discards all those unresponsive AD servers.

A new "ads" door service is created to give access to the state of the DC Locator and to allow "poking" it into action if necessary. This new door service is currently hosted in idmapd. It's a new service instead of adding functions to the existing idmap door service to facilitate the later relocation of this functionality into a separate service like "netlogon" as described above.

Changes in smbd and its libraries mostly eliminate the duplicate DC Locator, replacing it with calls to the "ads" door service to get our current DC. To simplify the changes, the smbd process actually keeps vestiges of its old DC Locator for now, including a thread that keeps a local copy of the DC information up-to-date.
That thread gets a notification from idmapd when the DC information changes. This vestige of a second DC Locator can be eliminated when the separate "netlogon" service is implemented.

The last of the three DC Locators is the "KDC service locator" in the Kerberos libraries. These libraries "do their own thing" for KDC location, which is to look in /etc/krb5/krb5.conf and then use DNS lookup. For our AD client-side operation, we don't want any of that. We just want Kerberos to use the AD server we've already located, and nothing else. The Kerberos library is augmented with a new service location override mechanism, where mech_krb5 uses dlsym() to look for a special function in the main program. If found, that function operates like a (standard) krb5 service locator plugin, except instead of being a system-wide plugin, the override applies only to the program in which it exists. Both idmap and smbd use ldap_sasl_bind (which end up using Kerberos) so both provide this override function to control KDC location.

And with that, we're down to just one DC Locator. Yea!

There's also a new test & diagnostic program "nltest", that can be used to query the DC Locator (also via the "ads" door service) and to "poke" the DC Locator (force DC rediscovery)

Actions #2

Updated by Electric Monk over 6 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit b3700b074e637f8c6991b70754c88a2cfffb246b

commit  b3700b074e637f8c6991b70754c88a2cfffb246b
Author: Gordon Ross <>
Date:   2015-10-26T14:17:47.000Z

    6352 Updated DC locator for SMB and idmap
    Portions contributed by: Matt Barden <>
    Portions contributed by: Kevin Crowe <>
    Portions contributed by: Alek Pinchuk <>
    Reviewed by: Bayard Bell <>
    Reviewed by: Alek Pinchuk <>
    Reviewed by: Rick McNeal <>
    Reviewed by: Kevin Crowe <>
    Reviewed by: Tony Nguyen <>
    Approved by: Robert Mustacchi <>


Also available in: Atom PDF