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

[Sumit Bose]

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)

= 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.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.
#* Will views only be applied to users from other domains or to IPA
   users as well?
#* Do we want stackable views?
#* Do we want to override everything or shall there be immutable
   attributes like e.g. the SID or the user name?
#* Shall we allow different UIDs/GIDs in different views?
#* 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.
# 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?"
#* 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.

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.

= Implementation =

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