[Freeipa-devel] [RFC] Migrating existing environments to Trust

[Simo Sorce]

On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote:
> On 05/27/2014 03:52 PM, Simo Sorce wrote:
> > On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote:
> >> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote:
> >>> Hi,
> >>>
> >>> I have started to write a design page for 'Migrating existing
> >>> environments to Trust'
> >>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust
> >>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and
> >>> https://fedorahosted.org/freeipa/ticket/3979 .
> >>>
> >> while working on a new version of the page with more details on design
> >> and implementation I came across the following problem. On the IPA
> >> server there should be a way for SSSD to deliver unmodified data (no
> >> view applied) or views other than the one for the IPA server to
> >> processes which delivers user and group data to other clients. This are
> >> mainly the extdom and the compat plugin of dirsrv.
> >>
> >> The two currently use standard glibc calls like getpwnam_r() to get the
> >> needed data from SSSD. While they can read the view objects form the
> >> LDAP tree there is no way to read the original data for users from
> >> trusted domains because it is only in the cache of SSSD.
> >>
> >> I'm looking for a way to allow SSSD to deliver the data without changing
> >> the protocol used by the NSS responder.
> >>
> >> One way I can think of is to use a new socket like
> >> /var/lib/sss/pipes/nss_noview and create a small library for the extdom
> >> and compat plugin to use the new socket. With this the plugin have to
> >> apply the views on their own if needed.
> >>
> >> Another way would be a new command for the NSS responder with two
> >> arguments, the view name (or empty for unmodified data) and a blob which
> >> contains the data for the corresponding request like e.g. getpwnam_r() or
> >> getgrgid_r(). Here the plugins have to use some new calls but all view
> >> processing can happen in sssd and the plugins can deliver the data
> >> directly.
> >>
> >> A drawback in both cases is that the memcache cannot be used.
> >>
> >> If someone has suggestions for SSSD or other ways how to deliver user
> >> and group data to client with other views than the IPA server I'm all
> >> ears.
> > Ok this one is hard to deal with in a way that will satisfy every
> > possible user.
> >
> > I think what we need to aim is simplicity and predictability at the
> > expense of flexibility.
> >
> > What I mean is that freeipa servers should be allowed to only stick to
> > one view, the default view for external users.
> 
> I do not understand what you mean by "one" view?

The "one" view is the view exposed via the (default) compat tree.

> Server should be able to have "all" views.
> "View" is an equivalent of the "zones".
> 
> SSSD has to get raw data from the external domain and give it to IPA.
> IPA would have to merge the data coming from SSSD in server mode with 
> some set of data associated with a subset of clients.
> I am not sure how it will be done (compat, cos or some other mechanism) 
> but this is the requirement.

This would require multiple compat trees, one per view, it would be very
expensive.

> So for clarity let me restate the use cases:
> 
> a) I had my users in a NIS or LDAP with POSIX attributes there. I used 
> to sync users from AD. I migrate from that to IPA but want to use trust 
> for my users because AD is authoritative source and I do not want/can 
> put POSIX into AD.
> b) I have several NIS domains that I need to consolidate. For whatever 
> reasons I can't migrate to the unified POSIX namespace. I want an 
> equivalent of the Centrify Zones when different clients get different 
> uid/gid assignments for the same users.
> c) I used sync so my POSIX attributes are in IPA but now I want to 
> switch to trust.
> d) I had a third party solution that had posix zoning and I want to 
> replace it with the similar solution based on IPA.
> 
> Views (plural) are a way to merge data and present it to a subset of 
> clients. In this context it is not really clear what you mean by "one" 
> view.

In order to see views you'll need a modern SSSD client that knows how to
apply them. Ie viewS are applied on the client side. The server shows
only one view via LDAP.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York