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


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 

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to