Ticket #1032 (closed enhancement: fixed)

Opened 4 years ago

Last modified 2 years ago

[RFE] sssd should support DNS sites

Reported by: sgallagh Owned by: pbrezina
Priority: major Milestone: SSSD 1.10 beta
Component: Async Resolver Version: 1.5.1
Keywords: Cc: pspacek
Blocked By: Blocking:
Sensitive: Tests Updated: no
Coverity Bug: Patch Submitted: yes
Red Hat Bugzilla: 743503 Design link: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSSites
Feature Milestone:
Design review: yes Fedora test page:
Chosen: May Candidate to push out: no
Release Notes: In larger Active Directory environments there is typically more than one domain controller. Some of them are used for redundancy, others to build different administrative domains. But in environments with multiple physical locations each location often has at least one local domain controller to reduce latency and network load between the locations. Now clients have to find the local or nearest domain controller. For this the concept of sites was introduce where each physical location can be seen as an individual site with a unique name. The naming scheme for DNS service records was extended so that clients can first try to find the needed service in the local site and can fall back to look in the whole domain if there is no local service available. Additionally clients have to find out about which site they belong to. This must be done dynamically because clients might move from one location to a different one on regular basis (roaming users). For this a special LDAP request, the (C)LDAP ping, was introduced.
Temp mark:

Description (last modified by dpal) (diff)


SSSD should support DNS "sites" concept known from Active Directory. Example:
Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin.
I have machine in Prague and I want it to join CONTOSO.COM. Now if I used:
dns_discovery_domain = contoso.com
sssd would try to connect to any DC in the domain - even the one in Dublin, completely ignoring sites.
I have to use:
dns_discovery_domain = Prague._sites.contoso.com
To force it to use Prague DCs only.
My understanding is, that the "DC locator" tries to communicate with DC's first to determine local site and remote DC's are only used if no valid/working DC can be found in the local site (Prague in this case).

This is AD specific functionality, but this concept would find its use also in large IPA domains where multiple IPA servers for the same domain exist in demographically different sites.

I believe some of the necessary code can be "stolen" from the Samba winbind component which implements this functionality

Change History

comment:1 Changed 4 years ago by dpal

  • Milestone changed from NEEDS_TRIAGE to SSSD 1.9.0
  • upgrade set to 0
  • tests set to 0
  • Patch Submitted unset
  • Tests Updated unset
  • Description modified (diff)

comment:2 Changed 4 years ago by mkosek

  • Red Hat Bugzilla set to [https://bugzilla.redhat.com/show_bug.cgi?id=743503 743503]

comment:3 Changed 4 years ago by dpal

  • Priority changed from minor to critical

AD integration enhancements are critical for 1.9.

comment:4 Changed 4 years ago by dpal

  • Milestone changed from SSSD 1.9.0 to SSSD Deferred

comment:5 Changed 3 years ago by dpal

  • Milestone changed from SSSD Deferred to NEEDS_TRIAGE
  • proposed_priority set to Core

comment:6 Changed 3 years ago by ondrejv

As per discussion on 15.8. I can confirm that the concept of "preferred" ldap servers as per weight option in the DNS SRV record in not sufficient in this case as all servers have the same priority, but belongs to a different site.

What happens now is that sssd pickup the first ldap server which might be on a different site and hence available over slow VPN link only.

SSSD should implement something like "DC locator" functionality already found in the Samba code (see my comment above) to guess the valid DNS site first and use it to bind to the nearest LDAP server. If none available, we might even stay disconnected or attempt to bind a server on different site - this should be perhaps configurable.

comment:7 Changed 3 years ago by jhrozek

  • Cc pspacek added

Petr, is this something the planned DNS views feature would help with?

comment:8 Changed 3 years ago by pspacek

Jakub, it is :-)

It will allow to return different DNS records for each subnet/querier's IP address. As a result you can return DNS SRV records with modified prioties and/or weights for each site.

Unfortunatelly, support for DNS views will be a quite big change in IPA and bind-dyndb-ldap. I can't predict real timeline for implementation.

comment:9 Changed 3 years ago by ondrejv

I would not go down this route (if I can ask) as guessing based on subnets or IPs can be dangerous and unreliable. What I would really like to see here is something similar or the same as concept of DNS sites known from Active Directory - see for example http://technet.microsoft.com/es-es/library/cc759550%28v=ws.10%29.aspx As I said this needs implementing something like DC locator functionality. I am sure Simo Sorce would explain more (please add him to comment). I must say I like this concept.

comment:10 Changed 3 years ago by ondrejv

This link is probably somewhat better explains the DC locator: http://premglitz.wordpress.com/2012/04/01/dc-locator-process-in-w2k-w2k3r2-and-w2k8/

comment:11 Changed 3 years ago by pspacek

Thanks for you comments! We need your feedback.

I'm not AD geek, please correct me if I'm wrong:

I looked into MS docs and, if I understood correctly, "sites" are defined on IP address basics for client machines.

See "Defining sites using subnets" in "Sites overview" from MS: http://technet.microsoft.com/en-us/library/cc782048%28v=ws.10%29.aspx

Also, from the link you posted: http://technet.microsoft.com/es-es/library/cc759550%28v=ws.10%29.aspx Section "Domain Controller Location in the Closest Site" says: "... For example, a portable computer that was moved to a new location could contact a domain controller in its home site, which is not the site to which the computer is currently connected. In this situation, the domain controller looks up the client site on the basis of the client IP address by comparing the address to the sites that are identified in Active Directory, and then returns the name of the site that is closest to the client. ..."

Pure DNS solution is universal, so each service can use it (as plain Kerberos and LDAP clients and so on). SSSD will not be necessary (generally).

Also, we can use some combination of both approaches. E.g. return records with priorities modified (selected by querier's IP address) and export all "sites" through DNS in similar way as AD does it. This approach should allow quick deployment for well-IP-partitioned configurations and manual setting for other situations.

Please, continue with ideas and cons of this approach!

comment:12 Changed 3 years ago by ondrejv

I think you are right here. Every AD Site is assigned some set of IP subnets which reflects the actual physical location. In a nutshell it works as follows:

  • Client compares its own IP address with the set of (by admin already pre-defined) set of subnets thus discovering to which site it belongs.
  • Performs DNS lookup in form of _ldap._tcp.<SITE>._sites.<DOMAIN> to obtain a set of ldap servers valid for the site given
  • Attempt to bind to the list obtained above using the weight factor saved in the SRV record.

This is very simplified view of the actual process. In reality it is bit more complex as every client has to obtain the "sites" definition in the first place. But this is the task for the "DC locator" mentioned above.

But I am no AD geek either so that's why I recommend we add Simo (or someone from the Samba team) to the CC list as they could explain it bit more deeper & advise which code can be re-used here.

comment:13 Changed 3 years ago by dpal

  • Milestone changed from NEEDS_TRIAGE to Temp milestone

comment:14 Changed 3 years ago by simo

Proper site discovery in AD domains involves using CLDAP as well. AS that's what tells you what site you should really hook up to normally.

comment:15 Changed 3 years ago by simo

I think we should create a pluggable discovery infrastructure, by creating the 'name' provider. Then turn the current stuff into the 'default' name provider. In AD we will instead by default use the AD name provider which will use AD sites. For IPA we will use the IPA Location discovery provider.

comment:16 Changed 3 years ago by jgalipea

  • Summary changed from RFE: sssd should support DNS sites to [RFE] sssd should support DNS sites

comment:17 Changed 3 years ago by dpal

  • Milestone changed from Temp milestone to SSSD 1.10 beta

Moving all the features planned for 1.10 release into 1.10 beta.

comment:18 Changed 3 years ago by dpal

  • Chosen set to May
  • Design review unset

comment:19 Changed 3 years ago by arubin

  • Priority changed from critical to major

comment:20 Changed 3 years ago by jhrozek

  • Owner changed from somebody to pbrezina

comment:21 Changed 3 years ago by jhrozek

Pavel, before implementing the AD discovery itself, you would also need to convert the SRV discovery into a plugin of its own, special-case IPA with the hostname discovery (Petr Spacek can help with setting up the environment) and then finally the AD specific site discovery.

Unit tests would also be nice, this interface is quite isolated, so it should't be too much trouble to mock them.

comment:22 Changed 3 years ago by jhrozek

  • Design review set
  • Design link set to https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSSites

The desing was done by Sumit and reviewed on the sssd-devel mailing list: https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013553.html

comment:23 Changed 3 years ago by dpal

  • Candidate to push out unset

comment:25 Changed 3 years ago by pbrezina

  • Status changed from new to assigned

comment:26 Changed 3 years ago by pbrezina

  • Patch Submitted set

comment:28 Changed 2 years ago by mkosek

  • Release Notes modified (diff)
Note: See TracTickets for help on using tickets.