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

[Dmitri Pal]

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

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.