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

[Simo Sorce]

On Tue, 2015-08-25 at 15:19 +0200, Petr Spacek wrote:
> 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 :-)

There is no security issue per se, host/ principals can get tickets just
fine but we do not attach a PAC here, and AD may refuse to operate w/o a
MS-PAC. Please open a RFE if this is breaking operations. We'll need to
decide how to assign a SID to hosts but that's the only "security" issue
that needs to be solved.

Simo.

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


-- 
Simo Sorce * Red Hat, Inc * New York