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]] _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel