From: Alexander Bokovoy [mailto:firstname.lastname@example.org]
Sent: Monday, August 25, 2014 3:04 AM
To: Nordgren, Bryce L -FS
Cc: 'freeipa-users(a)redhat.com'; 'sssd-users(a)lists.fedorahosted.org'
Subject: Re: [Freeipa-users] A prototype of merged domains ("views")
What essentially you want is to arbitrate access control to certain services
regardless the source users or groups are coming from. This is already
possible to achieve with HBAC rules because we already can make external
SIDs members of a non-POSIX group that is included into a POSIX group
which is referenced by an HBAC rule. This works already and doesn't need
any views because HBAC rules already can be subjected to a specific host and
specific service on the host.
Ah. My system is intended to work when there is no upstream SID (e.g., the source could be
something other than active directory). This is necessary to provide a loose one-way
coupling from the more-truested intranet to the less-trusted collaboration network.
Getting this established as a foundation is also a critical prerequisite to experimenting
with a web sso/kerberos gateway.
We need to extend concept of external members of non-POSIX groups to
have the same resolving features as we are planning with ID view overrides
(SID:S-..., IPA:<uuid>, etc) so that external non-POSIX groups can be used
Nonlocal groups are not interesting to me. They are defined in the internal corporate
environment which is not at all similar to an external collaboration domain. Locally
defined groups, containing members drawn from any of the contributing identity sources,
Your other problem is that you seem to unable to establish two-way
with AD as currently IPA requires. I have plans to get one-way trust back
working but it needs additional changes on our side to properly protect trust
account credentials when distributing them to a group of IPA masters
participating in the trust.
One way trust was requested in April and is still pending. Chances of getting a two-way
trust are zero. I'll be using the documented workaround to add the Kerberos
cross-realm principal to the KDC if and when I get it.
Chances of getting a "trust" go up if you eliminate all the crap MS overloads
that word with. A simple Kerberos trust ("realm trust") should be easier to get
than a domain/forest/etc. trust because it exposes the intranet to less vulnerability.
Much of my problem so far has been that people assume I want a domain or forest trust when
I'm really asking for a realm trust. If it helps, you can think of this as a prototype
of what FreeIPA's going to need views to do in order to implement a vanilla Kerberos
I want them (CIO) to authenticate users for me and provide a handful of well controlled
and harmless user attributes. Port 88, port 389, and port 636. Nothing else.
In other words, I want a very loose, one-way coupling between the collaboration domain and
the intranet. Not two way. Not tight coupling. Understand that the point of the
collaboration domain is to delegate root access to people who are not part of the CIO and
may not even be employees. Tight, two-way coupling of the intranet to this environment
amounts to unnecessary exposure to risk.
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.