> -----Original Message-----
> I went through this thread:
Since January, I've been turning this problem over and over. A good summary of
my functional requirements is here:
My current solution is described here:
> 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
* 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,
> 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:
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).
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
Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project