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

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to