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? > == 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. The rest looks good to me. Thank you! _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
