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

Tue Mar 10 08:47:18 UTC 2015

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

> 
> -- 
> 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