[Freeipa-users] AD trust deployment without IPA authority over reverse lookup zone

[Petr Spacek]

On 1.8.2015 21:19, John Stein wrote:
> Hi,
> 
> Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to
> RHEL 7?

You can watch the progress here:
https://bugzilla.redhat.com/show_bug.cgi?id=1214827

Unfortunately fixing this bug will not be sufficient for your particular
scenario. FreeIPA does not allow ordinary host/ principals used by client
machines (not to be confused with FreeIPA servers) to get tickets for AD
Kerberos realms.

It effectively means that nsupdate will properly detect the AD realm and
generate correct request but the request will be refused because the client
will not be able to get ticket.

I.e. you will have to resort to manual PTR record update OR convince
Alexander/Simo that allowing host/ principals from FreeIPA realm to get
tickets for AD realm is not a security issue :-)

Petr^2 Spacek

> Thanks again,
> John
> 
> On Mon, Jul 27, 2015 at 5:30 PM Alexander Bokovoy <abokovoy at redhat.com>
> wrote:
> 
>> On Mon, 27 Jul 2015, John Stein wrote:
>>> Hi,
>>>
>>> I consider deploying IPA in my organization.The environment is
>> disconnected
>> >from the internet.I have some concerns I'm not sure how to resolve.
>>>
>>> The environment consists mostly of windows servers (thousands) and
>>> workstations (ten thousand) managed by AD (CORP.COM). There is also a
>> small
>>> linux environment (up to a thousand servers) that are currently not
>>> centerally managed (user-wise).
>>>
>>> I want to utilize IPA and the AD trust feature to implement SSO.
>>>
>>> I'd like to have a sub-domain ran by IPA (LINUX.CORP.COM).
>>>
>>> Because the environment is windows dominated, the AD is used as the
>>> authoritative DNS server for all forward and reverse lookup zones.
>>>
>>> The AD trust requires that both the IPA and AD will be authoritative over
>>> their respective forward and reverse lookup zones. However, the linux and
>> No. We require that *some entity* is responsible for the zones. If you
>> put everything in AD DNS, fine, but then you are responsible for manual
>> update of the zone records and that all specific records are there.
>>
>>> windows servers are spread across multiple subnets without any big-scale
>>> logic, therefore it is not practical to create a reverse lookup zone for
>>> each subnet in the IPA server as those subnets contain both linux and
>>> windows machines.
>> You cannot have machines from IPA and AD domains in the same DNS zone at
>> the same time. A/AAAA records of those IPA and AD machines must belong
>> to different DNS zones.
>>
>> This is basic requirement of Active Directory deployment -- each AD
>> domain is responsible for at least one DNS zone and you cannot have
>> machines from two different AD domains in the same DNS zone.
>>
>>> I came up with some solutions:
>>>
>>> 1) Have only the AD as a DNS server and give up on ipa-client-install and
>>> automatic client registration.
>> Totally unrelated to how you handle DNS zones. ipa-client-install does
>> not require you to allow creation of DNS records. It can sufficiently
>> work with a configuration where a DNS record for the host is
>> pre-created.
>>
>>> 2) DNS synchronization between IPA and AD.
>> Unrelated and is not recommended. In DNS lexicon only a single entity is
>> responsible for the single DNS zone. IPA cannot be authoritative at the
>> same time as AD. (Neither we support IPA being a slave for other DNS
>> server).
>>
>>> 3) Have the IPA manage the forward zone (linux.corp.com), and have the
>>> clients update its own A record automatically upon ipa-client-install,
>>> while having the AD manage the reverse zones (A or B class subnets) with
>> me
>>> creating the PTR records manually. The IPA will be configured as a
>>> conditional forwarder for linux.corp.com, while the AD will be configured
>>> as a global forwarder in the IPA server.
>> That would work. There is a bug in nsupdate tool that prevents you from
>> GSSAPI-updating PTR records (over AD trust) so going with manual PTR
>> records would work.
>>
>> You need to make sure AD has no policy to periodically remove PTR
>> records for Linux machines.
>>
>> --
>> / Alexander Bokovoy