> -----Original Message-----
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Monday, August 25, 2014 3:04 AM
> To: Nordgren, Bryce L -FS
> Cc: 'freeipa-users@redhat.com'; 'sssd-us...@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.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
