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

Thu Apr 17 01:02:00 UTC 2014

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.

>
> = 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.

> #* 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.
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.
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.

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 ;-)

> #* Do we want to override everything or shall there be immutable
>     attributes like e.g. the SID or the user name?

I do not know why would overwrite the SID but I think that overwriting 
the user name would give us an interesting aliasing capability as a 
feature as a side effect.

> #* Shall we allow different UIDs/GIDs in different views?

Yes.

> #* I think overriding UIDs/GIDs should only be allowed for
>     ipa-ad-trust-posix idranges, mixing override with algorithmic mapping
>     does not make sense imo.

I think it does at least for the migration time. But it might not be 
achievable.
The idea is that you really should be required to manage UID/GID for the 
users manually via views if it is an old user.
If it is a new user that never was on the Linux side before the 
algorithmic mapping might be preferred.
But I also think that this should be controlled by a policy and admin 
would have to decide whether the IPA should generate UIDs or he would 
prefer to set the manually explicitly.

> # The views will be stored in containers below
>    cn=views,cn=accounts,$SUFFIX with containers for users and groups. The
>    objectclasses will look similar to posixAccount and posixGroup
>    objectclasses but with only optional (MAY) attributes. Questions:
> #* Do we want to consider to allow to add arbitrary attributes to a view
>     to cover requests like "We have this beautiful application which can get
>     all user data via the SSSD D-BUS responder but our AD admin will not
>     extend the AD LDAP schema to add the required attributes. Can IPA add
>     them for users from trusted domains?"
Yes but probably not as phase 1. So it is a separate enhancement.

> #* It was suggested to use a UUID to reference the original objects. For
>     AD users and groups the SID would be a good choice because it is unique
>     and already contains a reference to the original domain. I wonder if we
>     should add  a type prefix like 'SID:' to be able to add other types like
>     'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will
>     be a reference to the other IPA domain. On the other hand a type can be
>     added later and if the type is missing a SID is assumed.
>
> On the SSSD side the views can be stored below the corresponding user or
> group object in the cache and the SYSDB API has to be enhanced to return
> merged results. The merging only happens in the responders (NSS, D-BUS)
> before sending data to the clients.

Why SSSD should know about different views?
It should know raw and not raw but it always sees one merged view from 
the server.
What am I missing?
>
> To manage the views a new set CLI tools/Web UI pages should be added.
> Depending if we would like to allow to override IPA users as well or
> only users from trusted domains the tools might get their own name
> space, ipa override-*, or can be added below the trust name space, ipa
> trust-override-*.  It has to be noted that changes of a view will only
> be visible on the client after the related cached object is expired.

OK.

>
> = Implementation =
See comments above. I hope they give enough hints for implementation. At 
least for the first pass.

> =Feature Management =
> == UI ==
> == CLI ==
>
> = Major configuration options and enablement =
> Any configuration options? Any commands to enable/disable the feature or
> turn on/off its parts?
>
> = Replication =
> Any impact on replication?
>
> = Updates and Upgrades =
> Any impact on updates and upgrades?
>
> = Dependencies =
> Any new package and library dependencies.
>
> = External Impact =
> Impact on other development teams and components
>
> = Backup and Restore =
> Any files or configuration that needs to be taken care of in backup or
> restore procedure.
>
> = Test Plan =
> Test scenarios that will be transformed to test cases for FreeIPA
> Continuous Integration during implementation or review phase.
>
> = RFE Author =
> [[User:Sbose|Sumit Bose]]
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.