I have started to write a design page for 'Migrating existing
environments to Trust'
It shall cover https://fedorahosted.org/freeipa/ticket/3318 and
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.
= 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
* Migration/Consolidation of domains currently managed by other solutions, e.g.
https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a
= Design =
In Ticket [https://fedorahosted.org/freeipa/ticket/3979
https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are
# 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
#* 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
#* 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
= Test Plan =
Test scenarios that will be transformed to test cases for FreeIPA
Continuous Integration during implementation or review phase.
= RFE Author =
Freeipa-devel mailing list