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

[Sumit Bose]

Hi,

I have updated
http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust
with the results of various discussions with Simo and Alexander (thank
you). For your convenience you can find the text below as well. I'm
working on some figures which hopefully can help to understand the
user-view even better.

Comments and suggestions are welcome.

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

On the SSSD side we try to avoid changes. The AD users and group are
looked up via the extdom plugin which applies all needed views for the
client.

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 view-*, or can be added below the trust name space, ipa
trust-view-*. These tools will create and delete the views and assign
them to hosts and hostgroups. Additionally viewuser-* and viewgroup-*
commands must be created to add users and groups to the views and
specify their override values. 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 =

As said we try to avoid changes on the client side so the older clients
using the extdom plugin can benefit from the views.

On the server side we have to modify SSSD running in IPA server mode,
the extdom plugin and the slapi-nis plugin for the compat tree.

== SSSD (IPA server mode) ==
The main purpose of the IPA server mode of SSSD is to look up the users
and groups from the trusted domains so that they are available for
standard POSIX calls like getpwnam().

Before writing the data from AD to the cache SSSD will check if there is
a default view for the AD object. For this it will search the container
of the default view with the SID of the AD object as a key. If a default
view was found the given overrides are applied and the result is written
into the cache of SSSD.

The following should be noted here:
* all IPA servers and replicas are hardcoded to the default view, it is
* not possible to assign a different view to them
* for overridden values the original data will not be available (we
* might want to store them with a 'orig' prefix in the SSSD cache, but
* currently there is no use for this data in the IPA domain)
* it makes no sense to assign the default view to any host or
* hostgroups, because it is apllied by design to the whole IPA domain
* all other views are applied on top of the default view:
** if the default view e.g. overrides the uidNumber attribute from AD
the original value from AD is _not_ available to any other view
** if an override value is changed in the default view and not
overridden by e.g. view xyz the change in the default view will be
visible on call clients assigned to the xyz view as well.

== extdom plugin ==
The original purpose of the extdom plugin was to SIDs of AD objects to
POSIX UIDs and GIDs. There are plans to enhance the plugin
[https://fedorahosted.org/freeipa/ticket/4031
https://fedorahosted.org/freeipa/ticket/4031] but since some of them
might relate to user-views the user-views related changes should be done
first. As a consequence currently only UID and GID can be overridden,
not home-directory or shell. But changing the IDs is the main purpose of
the views anyways.

Before sending the data back to the client the extdom plugin must check
if it has to apply a different view then the default view for the
client. Since the SSSD client use SASL binds with the the host keytab to
access the IPA LDAP server the client DN is available as SLAPI_CONN_DN
in the Slapi_PBlock struct. With the DN the host object of the client
can be looked up to get the hostgroups the client is a member of. With
the DNs of the client and the hostgroups the view objects can be
searched for a match. If there is a view the extdom plugin must look up
the SID of the object the client requested and search the container of
the view with the SID as a key. If there is a view for the object it
will be applied and the result is returned to the client.

In case of an error during this operations or if more than one view was
found the data from SSSD were only the default view is applied will be
returned to the client. If the extdom plugin finds that a client is
assigned to multiple views it should be reported in the log at a high
level. Adding checks in the CLI or WebUI does not make sense because
every change to a host group would require such a check.

== slapi-nis plugin/compat tree ==
The compat tree offers a simplified LDAP tree with user and group data
for legacy clients. No data for this tree is stored on disk but it is
always created on the fly. It has to be noted that legacy clients might
be one of the major users of the user-views because chances are that
they were attached to the legacy systems with legacy ID management which
should be replaced by IPA.

In contrast to the extdom plugin it is not possible to determine the
client based on the DN because connection might be anonymous. The
Slapi_PBlock contains the IP address of the client in
SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA
tree requires a reverse-DNS lookup which might be unreliable. If the
reverse-DNS lookup was successful the slapi-nos plugin can follow the
same steps as the extdom plugin to lookup up and apply the view.

As a alternative slapi-nis can provide one tree for each view.

The first approach has the advantage that everything can be manages on
the server and no change on the legacy clients is needed, even if the
are assigned to a different view, but requires reverse-DNS and has more
search overhead. With the second approach every legacy system which
should get a specific view different from the default view has to be
pointed to the new tree. Using both in parallel is possible but might
not be worth the additional effort.

=Feature Management =
== UI ==
=== View management ===
A page to list all view and a page to change the attributes of the view
object are needed (see CLI section below for details).

=== Management of the overrides ===
I'm currently not sure if a user/group oriented approach or a view based
one is the better choice.

In the first case there will be a new tab on the user and group page
where views can be selected and overrides can be specified.

In the second case the view page (see above) will have tabs for users
and groups in the view.

Maybe both approaches can be combined.

== CLI ==
=== View management ===
Views must be added, displayed, modified and deleted. Imo the object for
the default view does not need any changes and should not be deleted, so
the tool can reject any attempt to change the default view.

Besides the name the only attributes for the view object are the
assignments to hosts and hostgroups. Maybe there might be use-cases for
host-categories as well, but the ALL category is already covered by the
default view. Maybe we can add the category already to the schema to
avoid updates in future but not expose it through the cli tools.

=== Management of the overrides ===
It must be possible to add, display, modify and delete an override
object for any trusted user or group in any view.

Since user and groups have different attributes there should be a
command family for user and another one for groups. It should be
possible to identify the trusted object by its fully qualified name or
by its SID.

I think the find and show operations should take the fully qualified
name or SID as an argument and should display the overrides found in any
view if not a specific view is given by an option.

= Major configuration options and enablement =
I think it is better to enable views manually than to have them by
default because they have special use-cases and will generate overhead
in the general case.

If this feature is only needed for users from trusted domains it can be
activated during ipa-adtrust-install. If it should be used for local
users in the long run as well there should be a special operation to
activate it and to create the container for views and the default view
container.

The existence of the view container cn=views,cn=accounts,$SUFFIX can be
uses as an indicator if views are enabled or not.

= Replication =
Views must be replicated.

= Updates and Upgrades =
Since views and not enabled by default only the new schema entries must
ba added during updates.

= Dependencies =
Currently no new package or library dependencies are expected.

= External Impact =
Enhancements for SSSD's IPA server mode a re needed.

= Backup and Restore =
All data needed for user-views are in the replicated LDAP tree and
should be backuped with the other data in the tree.

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