On Tue, Mar 10, 2015 at 09:47:18AM +0100, Sumit Bose wrote: > On Mon, Mar 09, 2015 at 08:27:05PM -0400, Dmitri Pal wrote: > > On 03/09/2015 03:40 PM, Jakub Hrozek wrote: > > >On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: > > >>On 03/09/2015 02:29 PM, Traiano Welcome wrote: > > >>>Hi Alexander > > >>> > > >>> Thanks for the response: > > >>> > > >>>On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy <aboko...@redhat.com> > > >>>wrote: > > >>>>On Mon, 09 Mar 2015, Traiano Welcome wrote: > > >>>>>Hi List > > >>>>> > > >>>>> > > >>>>>I have AD trusts configured and working between an IPA server and a > > >>>>>"master" primary domain controller (dc-1) in a forest in one data > > >>>>>center. This allows me to connect with SSH to linux servers in the > > >>>>>same data-center, authenticating with my AD credentials. > > >>>>> > > >>>>>I'm trying to test a scenario where I have an IPA server set up in > > >>>>>another data center, and trust is established with an AD domain > > >>>>>controller (dc-2) in that data-center. > > >>>>>This domain controller takes dc-1 as it's authoritative source. > > >>>>>Ideally, the IPA server will interact with the domain controller > > >>>>>nearest to it (i.e dc-2), however, from tcpdump, I note the following: > > >>>>> > > >>>>>- IPA server communicates with dc-2 first > > >>>>>- dc-2 returns a list of domain controllers in all the datacenters, > > >>>>>including dc-1 > > >>>>>the IPA server then begins querying ldap and kerberos ports on dc-1, > > >>>>>the domain controller furthest from it. > > >>>>>- Authentication on clients fail > > >>>>> > > >>>>>My question is: Is it possible to get IPA to query and interact only > > >>>>>with the domain controller it initially established trust with? > > >>>>Let's first separate multiple issues. > > >>>> > > >>>>1. Terminology > > >>>> Cross-forest trust is established between domain controllers in > > >>>> forest > > >>>>root > > >>>> domains. In case of IPA we need that access only once, when trust is > > >>>> created. You don't need to establish trust again with dc-2 once you > > >>>> have established it with dc-1. > > >>>> > > >>>> When trust is established, AD DCs will look up IPA masters via SRV > > >>>> records in DNS (_ldap._tcp.<ipa-domain>). We don't provide > > >>>> site-specific SRV records as IPA does not handle sites in this area > > >>>> yet. > > >>>> > > >>>Thanks for the clarification. > > >>> > > >>> > > >>>> However, this is not your problem. > > >>>> > > >>>>2. User and group lookups are done by SSSD against global catalog > > >>>> service (_gc._tcp.<ad-domain>) and AD DS (_ldap._tcp.<ad-domain>), > > >>>> along with Kerberos KDC (AD DCs). > > >>>> > > >>>> These DCs are found via SRV records in DNS and SSSD since 1.9.5 > > >>>> uses site-specific SRV records for AD domain controllers lookups in > > >>>> case of IPA-AD trust. > > >>>> > > >>>>You are interested in (2) being site-aware. However, you didn't say what > > >>>>is your distribution and software versions so it is quite hard to give > > >>>>any recommendation. > > >>>My objective is basically distribution of IPA servers across multiple > > >>>data centers linked by a WAN: > > >>> > > >>>- There is a central 'head office' with an AD domain-controller, this > > >>>is the primary source of identity for the domain. > > >>>- A number of other data-centers each have their own local AD domain > > >>>controller linked to the head-office domain controller > > >>>- The datacenters are in different timezones. > > >>>- An IPA server in each data-center with trust established with the > > >>>local domain controller > > >>>- Each IPA server is configured with it's own realm, but provides > > >>>access to the global AD domain via AD Trusts > > >>> > > >>>The idea was to prevent IPA authentication related traffic going > > >>>across the WAN (latency, different time-zones etc) to a central ad > > >>>domain controller at head office. So this setup seemed reasonable. > > >>> > > >>>I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, > > >>>the working setup was based on this howto: > > >>> > > >>>http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description > > >>> > > >>>... which works fine if the IPA server has a trust relationship > > >>>directly with the primary domain controller at head office (which it > > >>>is collocated with). > > >>> > > >>>I can live without site-awareness per se if I can achieve IPA > > >>>centralised authentication across datacenters in different timezones, > > >>>with AD as the primary source of identity. An alternative setup that > > >>>I've considered testing: > > >>> > > >>>- IPA server at the head office with trust established to the primary AD > > >>>DC. > > >>>- A replica of the primary in each DC (different timezones), on the same > > >>>realm > > >>> > > >>>However, I doubt replicas can work across timezones, and with high WAN > > >>> latencies. > > >>> > > >> > > >>As Alexander said the trust on the fores level. > > >>There is no pairing between IPA replicas and AD DCs to a specific data > > >>center. > > >> > > >>What you need to concentrate is making sure that SSSD on a client picks AD > > >>in the local data center and IPA in the same data center (for the > > >>additional > > >>lookup operations). > > >>I do not know whether one can explicitly set this in sssd.conf. This is > > >>something to ask SSSD list. The alternative would be to make DNS return > > >>the > > >>right server. > > >You can set the site and the DNS domain for the direct integration, but not > > >for the server mode. The server mode is designed to operate with mostly > > >defaults -- the reason not being that much that we don't want to support > > >configuration, but the current failover code can't handle two totally > > >separate domains in a single back end. > > > > > >This is a known pain point me and Pavel Brezina were talking about for a > > >long time. So far there hasn't been a driver that would justify > > >refactoring the failover layer to achive this functionality. > > > > > >>For AD DC the AD DNS will be returning the server to authenticate against > > >>and there should be a way to configure AD DNS this way. > > >>I do not think it is possible to force specific DNS entry out of IPA - it > > >>does not support sites yet. But may be there is a way to override it on > > >>SSSD. > > >> > > >>In case of other (legacy Linux or other platforms) clients that talk to > > >>IPA > > >>you can configure them with the explicit fail over list. They do not talk > > >>to > > >>AD directly. > > >>You might also consider configuring SSSD on the IPA server to use AD in > > >>the > > >>same location as a primary server. > > >SSSD on the IPA server /does/ support DNS sites, but only the DNS > > >autodiscovery. Unfortunately you can't specify a custom site.. > > > > > It looks like time to file a ticket(s) to support this kind of functionality > > (affinity to AD controllers within the same site). > > I think we already have a solution in the context of > https://fedorahosted.org/sssd/ticket/2486 where a new option 'ad_site' > was added. What is missing is to make it possible to use this option > with sub-domains. Currently all configuration options are only for the > primary domain, the IPA domain in this case. As Jakub said before the AD > sub-domain configuration use mostly suitable default values. We have to > decide if we want only special sub-domain option accessible or if we want > to allow access to all (there was a recent discussion on sssd-devel > about another option). Depending on this we have to figure out how to > make it available with the current configuration scheme. > > bye, > Sumit
OK, I filed https://fedorahosted.org/sssd/ticket/2599 to track this. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project