[Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers

Tue Mar 10 09:25:28 UTC 2015

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 <abokovoy at 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.