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