Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 16. Identity: ID Views and Migrating Existing Environments to Trust
The ID Views mechanism that is part of Red Hat Identity Management enables the administrator to specify POSIX attributes for users or groups. When a new ID view is created, the administrator can define what user or group attributes it should override; these newly defined attributes are then applied to the user or group. By allowing this, ID views provide a solution to preserve existing environments during migration from other identity management and system integration solutions.
Important
The client must be enrolled with an IdM server based on Red Hat Enterprise Linux 7.1 or later to benefit from this functionality.
ID views can only be used on Red Hat Enterprise Linux 6 clients running Red Hat Enterprise Linux 6.7 or later.
The administrator can only manage ID views on the server side; no configuration is available on Red Hat Enterprise Linux 6 clients. This chapter describes ID views from the client side. For complete information about ID views including the server-side functionality, see the Windows Integration Guide for Red Hat Enterprise Linux 7.
After running the
ipa-adtrust-install command on the IdM server, the Default Trust View is created. The Default Trust View is always applied to Active Directory users and groups, which allows the administrator to define POSIX attributes for AD users and groups regardless of how AD itself defined them. If you add a host-specific ID view that overrides the AD users or groups, the attributes from the host-specific ID view are applied on top of the Default Trust View. While the new ID view overrides the Default Trust View, the default view itself cannot be deleted. If no specific ID view is applied to a client, the Default Trust View always applies.
Note
If
ipa-adtrust-install is not run, you can still use the ID Views feature in a pure IdM environment to manage ID views and overrides for IdM users.
In a setup with a synchronization-based AD integration, all users are copied to the IdM server with generated POSIX attributes, such as login name, UID, GID, or shell. By enabling the administrator to modify the POSIX attributes that AD previously generated for AD users, the ID Views feature provides a solution to migrate existing environments to a trust-based AD integration.
Note
For a comparison of the synchronization-based and the trust-based approach, see the Red Hat Enterprise Linux 7 Windows Integration Guide.
Use cases covered by ID Views include:
- Store POSIX attributes and SSH keys for AD users
- Define POSIX attributes or SSH keys and SSH login information for AD users, and let them be applied when an AD user authenticates to clients running SSSD with ID Views support or when the AD user authenticates using a compat LDAP tree, which offers a simplified LDAP tree with user and group data for legacy clients.This capability is useful for migration from a synchronization-based solution or in a situation when a Linux administrator would like to manually define POSIX attributes for AD users but the AD policy does not allow it.
- Migrate from a synchronization-based to a trust-based integration
- Configure the POSIX attributes for users that are in a synchronization-based environment by creating an ID view override specifying previously used UID or other tools. Then move the users back to AD.
- Perform per-host group override of the IdM user POSIX attributes
- NIS-based infrastructure that is being migrated to an IdM integration with AD still often requires that the original POSIX data remain unchanged on some NIS domains or the company policies might prevent setting the original POSIX data in AD directly. In these situations, you can use ID Views to configure the POSIX data directly on the Identity Management server.
- Set different POSIX attributes or SSH keys for different environments
- Set different POSIX attributes or different user SSH public keys for different production environments – such as development, testing, or production – depending on the corresponding host groups.
16.1. User Overrides and Group Overrides
Every ID view is a collection of user overrides and group overrides that applies to specified hosts. An override provides a new user or group attribute that overrides the previous one; this enables you to, for example, replace a previously generated attribute with a new one. Every override is related to an AD or IdM user or group.
Note
Non-IdM integration systems can generate the UID and GID attributes using an algorithm that is different from the algorithm used in IdM. By overriding the previously generated attributes so that they are in compliance with the IdM system, a client that used to be a member of another integration system can be fully integrated with IdM.
The following user attributes can be overridden in an ID view:
uid: user login nameuidNumber: user UID numbergidNumber: user GID numberloginShell: user login shellgecos: user GECOS entryhomeDirectory: user home directoryipaSshPubkey: user SSH public key or keys
The following group attributes can be overridden in an ID view:
cn: group namegidNumber: group GID number
Note
IdM uses ID ranges to avoid collisions of POSIX IDs from different domains. POSIX IDs in ID Views do not use a special range type because IdM must allow overlaps with other kinds of ID ranges: for example, AD users created through synchronization have POSIX IDs from the same ID range as IdM users. If a collision occurs, it can be easily fixed by changing the conflicting IDs because POSIX IDs are managed manually in ID Views on the IdM side.
