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

[Alexander Bokovoy]

On Thu, 17 Apr 2014, Sumit Bose wrote:
>On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote:
>> On 04/15/2014 05:13 AM, 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 .
>> >
>> >I came across several questions which need answers so that more details
>> >can be added to the design. Besides that comments and suggestions are
>> >welcome as well.
>> >
>> >For your convenience I added the test below as well.
>> >
>> >bye,
>> >Sumit
>> >
>> >= Overview =
>> >
>> >This page illustrates how existing solutions which make AD users
>> >available to Linux hosts can be migrated to FreeIPA with Trusts. This
>> >includes migrations from the FreeIPA WinSync feature or environments
>> >where the AD users where correlated to NIS users.
>> >
>> >The common problem here is that some if not all attributes needed by a
>> >POSIX user or group must be overwritten or supplied by the IPA server.
>> >The link to the related AD object is preferably the SID but if it is not
>> >available on both sides the name of the object must be used. AD will
>> >keep the responsibility for authentication and provide the AD
>> >group-memberships of the object.
>> >
>> >= Use Cases =
>> >* Migration from the FreeIPA Sync solution to the FreeIPA Trust solution
>> >** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318]
>> >* Migration/Consolidation of domains currently managed by other solutions, e.g. NIS
>> >** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution)
>>
>> As I mentioned in the ticket not only that. Based on conversations
>> with different potential consumers of the trust functionality the
>> ability to use existing POSIX attributes and manage them in IPA
>> while user accounts come from AD is a crucial next step.
>
>Thank you for your feedback, it was very helpful but I'm afraid it might
>also caused some new questions.
>
>>
>> >
>> >= Design =
>> >In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained.
>> ># Instead of just offering a single override option the introduction of
>> >   views are suggested. A suitable client can ask for a specific view
>> >   with override options different from the default override
>> >   view.
>>
>> Yes.
>>
>> >Questions:
>> >#* Will the default view always be applied? I think it makes sense to
>> >    always apply it to get a consistent default behavior. If there is a
>> >    reason for a client to get the unmodified data a special view called
>> >    e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin
>> >    to be able to send the raw data to the IPA client so that SSSD can use
>> >    different views on the client which might be needed for docker/container
>> >    use cases.
>>
>> Sounds reasonable to have the default view and apply it always. If
>> the view does not contain posix attributes for the specific user we
>> should use dynamic mapping based on SIDs.
>
>Quite some time ago we have decided to not mix algorithmic mapping and
>manually managed POSIX IDs. E.g. think about the case where a view with
>POSIX ID was added for an existing user which already has an algorithmic
>ID assigned on some clients.
>
>I think the admin has to decide what he wants. Below you mentioned a
>migration use case where old users should keep their IDs but new users
>will get algorithmically generated ones. I think this is bad practice
>and technically is it next to impossible without additional admin
>effort to decide if a given AD user is an old or a new user. The admin
>either has to add special flags/attributes to the old AD user objects or
>we have to keep an immutable list of old users in IPA. Please note that
>this has to be done for groups as well. Imo it would be
>easier and safer for the admin to either do a full migration to
>algorithmically mapped IDs or manage all POSIX IDs manually on the IPA
>side.
>
>Additionally I think that in your use case there might be even the need
>to manually manage POSIX IDs even for new user. E.g. in the case where a
>larger amount of new users is added to AD which where managed by a
>completely independent system before.
For this case admins could force manual POSIX mapping even if there are no
POSIX attributes in AD, then use views to supply proper IDs to those
users that require them.


>>
>> >#* Will views only be applied to users from other domains or to IPA
>> >    users as well?
>> Design goal will be to allow them to be applied to all users.
>
>Why, what is the use case to override attribute of IPA users which
>cannot be solved by adding other attributes with the needed values to
>the IPA user object directly?
I agree, why should we introduce a new level of shadowing for IPA users
given that the only tool that would accept these views would be a new
SSSD version. I could understand that shadowing to IPA users on selected
old clients or machines not under IPA control (NFS filers, for example)
but there are no means to force them to use views we are designing here.


>> Implementation goal will be to apply them to external users first.
>> Or I should say we need to figure out the procedure:
>> 1) Pre migration: AD with no POSIX, LDAP/NIS with POSIX for some/same users.
>> 2) Past migration: AD with no POSIX, no duplicate accounts in IdM,
>> POSIX attributes for AD users are migrated into a view.
>>
>> How we do it is the question but we need to have a path. May be it
>> would require some kind of tool:
>> ipa create-view --check
>>
>> This will go through all users in IPA and check them against
>> available trusted domains and would report which users will be
>> removed becuase they are found in a specific domain.
>
>I think it should only report conflicts. The admin should decide how to
>solve the conflict.
Agreed.


>> ipa create-view --create --except=<group list>
>>
>> This will actually do the work but if there are special users that
>> need to be processed in some special way admin might temporarily put
>> them into a specific group and then exclude this group or groups
>> from cleanup.
>>
>> Just a thought...
>>
>> >#* Do we want stackable views?
>>
>> We want client oriented views. I.e. views should be attached to host groups.
>> For the legacy clients there should be a way to expose a view as a
>> separate base=DN so that one set of legacy clients can be pointed to
>> one DN and another to another.
>
>I'm not sure if this will stretch the compat tree too much, I let
>Alexander and Nalin decided.
Technically it is possible but configurable manually and not replicable
as configuration is in cn=config.


>>
>> If the host based views and DN based views do not have data for a
>> specific user the data should be fetched from a global default view.
>> I think we can use CoS for that in conjunction with the compat
>> plugin but I would leave this to experts to decide.
>>
>> Bottom line: one global fallback view and then specific views for
>> host groups and for legacy clients.
>> I know I might be asking a lot ;-)
>
>How shall this 'global default view' work? E.g. if there is an AD user
>without a POSIX ID in AD and algorithmic mapping is not enabled for this
>user. If there is no override object for this user in the current view
>or if the override object does not contains a POSIX ID attribute where
>should the ID come from?
It is unclear to me as well. I could understand if there would have been
a way to override certain properties based on a regular expression or a
membership but this is pushing too far the whole idea and basically
locking down further migrations.


>> >#* Shall we allow different UIDs/GIDs in different views?
>>
>> Yes.
>
>I hope the admin knows what he does in this case. I think it's similar
>like with the user name, is there really a user-case for this with
>cannot be solved better by creating a new user with the given UID? Think
>about what happens if a host is moved to a new host group e.g. to change
>the HBAC rules but by chance has now a different view with different
>UIDs?
Again, question is what purpose would such view serve? Given that only
new SSSD version can resolve these views properly and a likely reason
for deviating would be to present such a user somewhere on a legacy
system, I see certain conflict of use case wishes.

-- 
/ Alexander Bokovoy