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@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
