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 <[email protected]> > >>>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 > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > 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 -- 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
