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
Enjoy, 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.
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.
-----Original Message----- From: Alexander Bokovoy [mailto:abokovoy@redhat.com] Sent: Monday, August 25, 2014 3:04 AM To: Nordgren, Bryce L -FS Cc: 'freeipa-users@redhat.com'; 'sssd-users@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 more widely.
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, are interesting.
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.
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 trust.
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.
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.
sssd-users@lists.fedorahosted.org