[SSSD] Design Discussion: SSSD should support DNS sites

Sumit Bose sbose at redhat.com
Fri Feb 22 08:33:55 UTC 2013


On Thu, Feb 21, 2013 at 07:02:47PM +0100, Jakub Hrozek wrote:
> On Thu, Feb 21, 2013 at 05:16:07PM +0100, Sumit Bose wrote:
> > After a discussion with Simo I updated the page again.
> > 
> > bye,
> > Sumit
> > 
> 
> Hi,
> 
> I think this plugin architecture matches what we discussed over the
> phone. I only have two questions, one of which is inline. The other is
> -- since the AD specific plugin would link with a Samba library, should
> I ressurect the patch that splits responders into multiple packages?

yes, I think this would help to avoid pull in unwanted dependencies.
E.g. AD, IPA provider and PAC responder can be put into a new package
which has a dependency on samba(4)-libs. Then the other stuff only
depends on libldap and libkrb5.

> 
> > == Use Active Directory's DNS sites ==
> > Related ticket(s):
> > * [https://fedorahosted.org/sssd/ticket/1032 RFE sssd should support DNS sites]
> > 
> > === Problem Statement ===
> > 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 (see e.g. http://technet.microsoft.com/en-us/library/cc759550(v=ws.10).aspx) 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 (http://msdn.microsoft.com/en-us/library/cc223811.aspx), was introduced.
> > 
> > === Overview view of the solution ===
> > ==== General considerations ====
> > The solution in SSSD should take into account that other types of domains, e.g. a FreeIPA domain, want to implement their own scheme to discover the nearest service of a certain type. A plugin interface where the configured ID provider can implement methods to determine the location of the client looks like the most flexible solution here.
> > 
> > Since the currently available (AD sites) or discussed schemes (http://www.freeipa.org/page/V3/DNS_Location_Mechanism) use DNS SRV lookups the plugin will be called in this code path. Since network lookups will be needed the plugin interface must allow asynchronous operations. SSSD prefers the tevent_req style for asynchronous operations where the plugin has to provide a *_send and a *_recv method. Besides a list of server names which will be handled as primary servers, like the servers currently returned by DNS SRV lookups, the *_recv method can additionally return a list of fallback servers to make full use of the current fallback infrastructure on SSSD.
> > 
> > ==== Sites specific details ====
> > 
> > The plugin of the AD provider will do the following steps:
> > 1. do a DNS lookup to find any DC
> > 1. send a CLDAP ping to the first DC returned to get the client's site
> > 1. after a timeout send a CLDAP ping to the next DC on the list
> > 1. if after an overall timeout no response is received the CLDAP lookups will be terminated and the client's site is unknown
> > 1. if the clients site is known a DNS SRV _service._protocol.site-name._sites.domain.name for primary server and _service._protocol.domain.name for backup server is send, otherwise only one with _service._protocol.domain.name is done
> > 1. if primary and backup server lists are available all primary servers are removed from the backup list
> 
> ^^^ I don't really understand when can this happen. Is this for the case
> when the backup list is configured but the primary list is discovered
> from DNS? Then it would be a generic problem, not one specific to site
> discovery.

No, _service._protocol.domain.name will return all servers in the domain
and  _service._protocol.site-name._sites.domain.name return the nearest.
The nearest are the primary servers. Since the nearest servers will be
in the list of all servers, to avoid checking a non working server twice
they should be removed there and the remaining servers can be used as
backup servers.

HTH

bye,
Sumit
> 
> The rest looks good to me. Thank you!
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list