ID views

An ID view gives a subset of hosts a different set of user / group attributes: uid, gid, home, shell, GECOS, SSH keys. The global directory is untouched; only hosts the view is applied to see the overrides.

Typical uses:

• Migration. zhangwei was uid 1500 on the legacy system and IPA allocated 60005; until the old file server is re-chowned, these hosts keep seeing 1500.
• A different shell or home on certain hosts (a bastion that only grants rbash).
• POSIX attributes for AD users on Linux: users from an AD trust have no uid / shell of their own; they come from overrides in Default Trust View or from the ID range algorithm.

Overrides

One override per user / group per view; fill only the fields to change, empty fields keep the global value. The target of a user override can be an IPA user or an AD user (user@ad.example.com).

Applied to

A view is applied to hosts or host groups. A host has at most one view at a time; applying another replaces it. IPA servers cannot have a view. The client's sssd cache must be cleared (sss_cache -E) or expire before overrides become visible.

Default Trust View is created when the AD trust is set up and applies to every host without an explicit view; overrides for AD users live there by default. Deleting it drops every Linux-side attribute override for AD users.

Boundaries

• Overriding a uid does not change ownership on disk; after migration either chown or keep the view for good.
• Overrides play no part in HBAC / sudo evaluation, which looks at global objects and group membership.
• Views work only on IPA clients running sssd 1.12+; legacy systems talking plain LDAP to IPA do not see them.