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

[Dmitri Pal]

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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.