[Freeipa-users] Two way A/D trust versus one way trust

[Nordgren, Bryce L -FS]

> -----Original Message-----
> I went through this thread:
> https://www.redhat.com/archives/freeipa-users/2014-
> January/msg00177.html

Since January, I've been turning this problem over and over. A good summary of my functional requirements is here: http://www.freeipa.org/page/External_Collaboration_Domains

My current solution is described here: http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration


> I have another situation where I need a one way AD trust.  We have an IPA
> domain with a bunch of Linux servers and an AD domain for the corporate
> network.  Typical scenario.  We want IPA to trust AD but do not want AD to
> trust IPA.  Access is availalbe to administrator/root accounts in both the AD
> and IPA domains.

Mulling this over for the past nine months, I've settled on two important factors which may help navigate the muddy waters of fear, paranoia, and ignorance:

* Is there a security boundary (firewall) separating your IPA domain from AD? Could you tolerate one if it made deployment more likely/acceptable?
* How similar are the roles played by users on Linux servers vs the AD servers?

These are both indicative of how tightly coupled your two domains really need to be, so you know how much AD-provided functionality you can agree to do without as you try to make the Windows admins feel safer. If there's no similarity at all between roles on the Linux systems and roles on the windows systems, you can just use AD for authentication and basic user attributes.

This is if you're lucky enough to just be dealing with fearful people and not faceless, one size fits all policies designed by paranoid people for a windows environment within a single security boundary.

> Reading through the thread above, when we set up cross forest trusts with
> this version, the IPA side does not yet have the equivalent of a Windows
> Global Catalog.  So even though it says it's a 2-way trust, it's really not
> because IPA has no way to store the global catalog copies of what it needs
> for Windows to trust IPA.  So with the version right now as it exists today, de-
> facto, IPA trusts AD, but AD has no way to trust IPA yet because IPA doesn't
> have all the pieces in place.

Perhaps your chances of obtaining a cross-forest trust may go up if you agree to manage users and groups in AD, and Linux machines/services only in IPA (e.g., no users in IPA to infiltrate the windows environment).

If politically necessary, AD can issue a "realm trust" (Kerberos only), which can be one-way. At least authentication will function. IPA does not officially support that yet, but there is a workaround: https://www.redhat.com/archives/freeipa-users/2014-August/msg00096.html All your machines will need access to port 88 on the AD servers so they can kinit, but they can be joined to IPA rather than AD. If you do this, write it up! Otherwise, I'll write it up after I do it (which is predicated on me obtaining a realm trust).

The downside is that currently you really can only use IPA to manage machines and services in this context. IPA can manipulate groups defined in AD as atomic units, but I'm not sure even that will work if a cross-forest style trust has not been established. An in-progress feature called "views" provides the machinery to recognize and manage individual users defined externally. Things will get better.

> The AD group at this site is concerned that with some future version of IPA,
> since Windows already "thinks" it trusts IPA, that IPA will get the correct
> components and that suddenly IPA users will be able to authenticate in the
> AD domain.  Ideally, they would like to set up an official one way trust today
> so that future possibility never happens.  If that isn't possible, what other
> steps could they take to guard against that future possibility?

1] Don't manage users or groups in IPA.
2] Don't couple the domains more tightly than needed.
3] Create a security boundary to segregate the domains, particularly if it is appropriate to do so (i.e., protect business systems from crazy experimentation in R&D department).

HTH
Bryce




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.