On Mon, 09 Mar 2015, 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
  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

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.
Do you have sites defined in AD?

If so, can you enable debug_level=10 in /etc/sssd/sssd.conf on IPA master
in the other datacenter and attempt to login as AD user. We'll see in
SSSD logs how it discovers what AD DC to talk to.

Add following to /etc/sssd/sssd.conf:
debug_level = 10

debug_level = 10

and restart sssd.

I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference,
the working setup was based on this howto:


... 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
Currently each master has to be prepared with ipa-adtrust-install if any
of IPA clients connected to this master need to be accessible to AD

/ Alexander Bokovoy

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

Reply via email to