In some cases it would be really beneficial to be able to create alternative views of the user/group database for specific users and for specific target clients.
A few use cases:
In all these cases it is very useful to have a special set of maps to override the values found by the sources.
For the AD sync/migration case there is a single map that operates as an override used by the plugin that generates the compat tree/trust tree.
The same map structure can also be used to generate specific "view maps" in alternate subtrees, that smart clients (SSSD) can use to locally override IDs. These maps are only stored in LDAP but not necessarily used by the server. They have a specific name that the smart client is configured to use directly or indirectly (for example by creating a host group and associating the "view map" to the host group).
These maps should use new objectclasses that mimics posixAccount and posixGroup classes but have all attributes set to MAY, so that only specific attributes are overridden, not necessarily all of them.
Example classes To Be Discussed:
objectclass: ( $OID NAME 'ipaOverrideAnchor' DESC 'Anchors and override view to an object' SUP top STRUCTURAL MUST ( cn $ ipaAnchorUUID ) ) objectclass: ( $OID NAME 'ipaUserView' DESC 'Overrides for User Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory $ loginShell $ gecos $ description ) ) objectclass: ( $OID NAME 'ipaGroupView' DESC 'Overrides for Group Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( cn $ gidNumber $ description ) )
I haven't added overrides for group members as that may be a tad dangerous, hower it should be discussed.
These amps are associated to the object via a UUID attribute (is this always ok ? Is it too hard when mapping AD objects ?).
A new subtree called views under cn=accounts is created within which named subtrees are created. the 'default' subtree is used by the compat plugin to source overrides, any other tree is used by the smart clients directly.
Example:
cn=default,cn=views,cn=accounts,$SUFFIX |_ cn=users |_ anchorUUID=123456... |_ cn=groups
Will help to solve #3318
BTW can we re-use some machinery from http://tools.ietf.org/html/draft-bannister-dbis-mapping-03 ? (I didn't looked into design, I'm just throwing ideas aroud :-))
Based on the discussions at the Summit this is really the next big thing people are looking for for us to implement around trusts. That would provide not only migration from NIS but also from LDAP based solutions that already manage POSIX attributes centrally. It would also allow migration from 3rd party solutions that people do not like but have to live with. If done with the views it will allow zoning in the similar way to some of the popular 3rd party solutions.
As we will be addressing these use cases in #3318 (4.2) I am moving the ticket there.
Prototype of similar activity using off the shelf tools described at:
http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration
The use case is a view which provides a "merged domain" of FreeIPA and upstream identities, where sensitive attributes which must not collide are managed centrally (i.e., by FreeIPA)
Requirements, implementation description, and evaluation included.
Framework part finished:
master:
ipa-4-1:
extdom enhancements:
sssd Requires was bumped.
This commit concludes the feature. Thanks everyone!
Metadata Update from @simo: - Issue assigned to tbabej - Issue set to the milestone: FreeIPA 4.1
Login to comment on this ticket.