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

Simo Sorce simo at redhat.com
Fri May 30 04:54:22 UTC 2014


On Fri, 2014-05-30 at 00:09 -0400, Dmitri Pal wrote:
> On 05/29/2014 02:13 PM, Simo Sorce wrote:
> > On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote:
> >> On 05/29/2014 11:41 AM, Simo Sorce wrote:
> >>> On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote:
> >>>> On 05/28/2014 11:20 PM, Simo Sorce wrote:
> >>>>> 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.
> >>>>>
> >>>> OK, I agree with multiple views being expensive and merging things on
> >>>> the client but how you define which one is the "default" on the server?
> >>> We'll have one called "default" ?
> >>>
> >>> Simo.
> >>>
> >>>
> >> I do not care about the name i care about the content. Imagine that
> >> there can be several different views. Which one is the default one? How
> >> it is picked? Id there a way to change from one view to another? Also
> >> this means that all legacy clients would have just one view because
> >> there will be a single compat all of them can be pointed to. May be if
> >> we can switch views on different replicas we would be able to create
> >> zones such that different replicas are used to serve different groups of
> >> legacy clients.
> > No we can't switch the default view for external users via LDAP on
> > different replicas, as that would cause clients to have conflicting
> > data.
> >
> > If we need different views via LDAP we will have to explicitly enable
> > additional compat views.
> >
> > Simo.
> >
> 
> May be we can enhance the compat view to use sub types for posix 
> attributes that denote a view.
> Then use mapping of client IP/Hostname to a view using some kind of 
> relation object.
> DS can already consider IP of the client so may be we can extend it to 
> use IP to pick the right sub-type value from a MV attribute.

Using the IP of a client in general is unreliable, we cannot base a
change of behavior on that information. It would be a nightmare to
debug.

NAT, mobile clients, etc... will all cause any policy based on IP
addresses to be unusable in various situations.

Simo.

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




More information about the Freeipa-devel mailing list