Ticket #1032 (closed enhancement: fixed)

Opened 3 years ago

Last modified 11 months 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:
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.

Description (last modified by dpal) (diff)

https://bugzilla.redhat.com/show_bug.cgi?id=743503

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 3 years ago by dpal

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

comment:2 Changed 2 years ago by mkosek

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

comment:3 Changed 2 years ago by dpal

  • Priority changed from minor to critical

AD integration enhancements are critical for 1.9.

comment:4 Changed 2 years ago by dpal

  • Milestone changed from SSSD 1.9.0 to SSSD Deferred

comment:5 Changed 20 months ago by dpal

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

comment:6 Changed 20 months 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 20 months ago by jhrozek

  • Cc pspacek added

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

comment:8 Changed 20 months 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 20 months 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 20 months 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 20 months 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 20 months 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 20 months ago by dpal

  • Milestone changed from NEEDS_TRIAGE to Temp milestone

comment:14 Changed 20 months 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 20 months 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 20 months ago by jgalipea

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

comment:17 Changed 20 months 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 16 months ago by dpal

  • Design review unset
  • Chosen set to May

comment:19 Changed 16 months ago by arubin

  • Priority changed from critical to major

comment:20 Changed 14 months ago by jhrozek

  • Owner changed from somebody to pbrezina

comment:21 Changed 14 months 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 14 months ago by jhrozek

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

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 13 months ago by dpal

  • Candidate to push out unset

comment:25 Changed 12 months ago by pbrezina

  • Status changed from new to assigned

comment:26 Changed 12 months ago by pbrezina

  • Patch Submitted set

comment:28 Changed 11 months ago by mkosek

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