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

[Dmitri Pal]

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?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.