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

[Alexander Bokovoy]

On Fri, 30 May 2014, 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.
Please leave the hope to base any differentiation on the connection
properties. They are unreliable, especially for the mobile and NATed
clients.

The only thing we can use for legacy clients is to have differentiated
base DN. Using multi-valued RDN like cn=compat+view=viewname should give
us enough clue. Given that view has to be setup by the admin manually
anyway, asking them to amend the client's configuration to use
multi-valued RDN seems to be a reasonable compromise. We can also take
the view name into account when generating advices by the ipa-advise
tool as it could simple pull down whole set of views, place mapping of
hostname to view name in the generated script,  and then can use hostname
on the machine to properly give base DN configuration.
-- 
/ Alexander Bokovoy