diff options
Diffstat (limited to 'doc/ipa/sch-ipa.txt')
| -rw-r--r-- | doc/ipa/sch-ipa.txt | 93 |
1 files changed, 93 insertions, 0 deletions
diff --git a/doc/ipa/sch-ipa.txt b/doc/ipa/sch-ipa.txt index b5a585b..f560580 100644 --- a/doc/ipa/sch-ipa.txt +++ b/doc/ipa/sch-ipa.txt @@ -87,3 +87,96 @@ on IPA masters. As 'system-auth' PAM service is not used directly by any other application, it is safe to use it for trusted domain users via compatibility path. + +== Support for ID views == + +When FreeIPA 4.1 is in use, Schema compatibility plugin can be configured to +override POSIX attributes according to an identity view (ID View) which +contains overrides for users and groups. + +The overrides are managed by FreeIPA separately for users and groups: + +* management of ID views: + ipa idview-add 'my view' + +* management of an override for a user: + ipa idoverrideuser-add 'my view' auser --login=foo --shell=/bin/ksh \ + --homedir=/home/foo --uid=12345 + +* management of an override for a group: + ipa idoverridegroup-add 'my view' agroup --group-name=bgroup --gid=54321 + +FreeIPA transparently supports overrides for users and groups from trusted AD +domains. This means that for trusted domains, IPA doesn't require to place +POSIX attributes in Active Directory. Instead, a global ID view named 'Default +Trust View' is used to contain POSIX attributes for existing AD users. +Additionally, specialized ID views can be added on top of the 'Default Trust +View' and then assigned to specific hosts. + +Schema compatibility plugin does support ID overrides from a single view. The +feature is designed to allow host-specific ID view, where the view is specified +through the search base. + +For native IPA users default POSIX attributes are stored natively, thus only a +host-specific ID view is applied, if any. For trusted AD users 'Default Trust +View' ID view is applied automatically by SSSD running on the IPA master, thus +Schema compatibility plugin only applies a host-specific ID view, if specified. + +In FreeIPA Schema compatibility is configured to serve entries through the +host-specific ID view with base DN of cn=<ID view>,cn=views,cn=compat,$SUFFIX. + +=== ID views implementation === +Detailed design of ID views in FreeIPA can be seen here: +http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust + +In Schema compatibility plugin support for ID views is done on top of existing +map cache. It is expected that there are less overrides than non-overridden +entries for IPA users and groups. For trusted AD users POSIX attributes from +'Default Trust View' are applied by SSSD on IPA master. Thus, if there are no +host-specific overrides, trusted AD users treated by Schema compatibility +plugin as before -- as entries which content comes from nssswitch API. + +This approach allows to only keep original entry in the memory and apply +host-specific override only at the time when entry with explicitly requested ID +view is returned as part of a search result. + +In order to map original entry to an override, FreeIPA configuration for Schema +compatibility plugin adds ipaAnchorUUID attribute and ipaOverrideTarget object +class to every generated entry. ipaAnchorUUID is based on ipaUniqueID for IPA +objects and on SID for trusted AD objects: + +* ipaAnchorUUID=:IPA:<domain>:<ipaUniqueID> for IPA object (user, group)_ + +* ipaAnchorUUID=:SID:<SID> for trusted AD user or group + +For ID overrides FreeIPA maintains ipaAnchorUUID with the same value so that an +override can be found by simple matching of the ipaAnchorUUID attribute's +value. FreeIPA also stores original uid value for user objects in ID override +as ipaOriginalUid attribute, to allow mapping back memberUid values for groups. + +When a query request comes, the view in the base DN is detected and remembered. +Base DN is rewritten to exclude the cn=<ID view>,cn=views so that a normal +search can be performed against cached entries. Additionally, search filter is +analyzed to replace references to rewritten uid (for user) and cn (for group) +attributes by references to the original objects. The references come from the +ID view overrides, if they exist. + +Once search results are gathered for the map, they are processed in order to +apply an override. For users entry attributes overridden with the values from +an override. For groups additional processing is performed on values of +memberUid attribute. + +As opposed to member attribute, memberUid attribute contains only values of uid +attribute of the original member entry. Given that an ID override may redefine +uid value, corresponding memberUid value of a group needs to be rewritten to +include redefined uid value. In order to do that, original memberUid value is +compared with ipaOriginalUid attribute's value to find an override +corresponding to the original user object. If such override is detected, memberUid +value is replaced by the uid value of the override. + +When attributes of the entry are processed and optionally amended with overridden +values, DN of the entry is rewritten as well, to reflect the fact that entry is +served through the view. + +For all returned entries ipaAnchorUUID attribute and ipaOverrideTarget objectclass +are removed. Resulting entry is sent to the client. |