[Freeipa-users] A prototype of merged domains ("views")

[Alexander Bokovoy]

On Sun, 24 Aug 2014, Nordgren, Bryce L -FS wrote:
>Over the past month, I rearranged my local systems for our
>collaboration environment. The essence of the work is to combine
>employee identities (defined in AD) with identities for external users
>(defined in FreeIPA), massage them so that they look the same, and
>export them to every posix desktop and web application I support.
>
>Defining cross-domain posix groups is included, and was successfully
>performed, but sssd doesn't have a vocabulary to describe a merged
>domain (one identity provider, multiple auth providers). Still trying
>to figure out if I can force this to work somehow.
>
>The activity may shine a light on some of the things "views" might be
>required to do.
>
>http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration
After reading the page I think you are over-complicating your own
deployment for no real benefit.

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.

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 more widely.

Note that ID view overrides per host will then affect HBAC rule content
automatically as SSSD would perform group/user resolution prior to
evaluating the rule.

Your other problem is that you seem to unable to establish two-way trust
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.

-- 
/ Alexander Bokovoy