Red Hat Security: Identity Management and Authentication
Redefine POSIX attribute values associated with IdM or Active Directory users on IdM clients.
Identity management systems other than IdM typically generate user identifiers (UIDs) and group identifiers (GIDs) based on a different algorithm than the one that IdM uses. ID views enable administrators to specify values for POSIX user or group attributes, as well as to define on which clients these values apply. Using ID views, IdM can override the values for clients that used to be members of other integration systems to make them compliant.
With ID views, you can change the user attribute values defined in Active Directory. For example, in a heterogeneous environment comprised of Linux and Microsoft Windows servers, use ID views to override attributes values. The use of ID views provides the following benefits:
Overriding Active Directory user attributes, such as POSIX attributes or SSH login information
Migrating integration from synchronization-based to trust-based integration
Applying user attributes on a per-host basis
By default, IdM uses Default Trust View as the default view.
This view is always applied to Active Directory users and groups in trust-based setups.
The Default Trust View is created automatically when you establish a trust using the ipa-adtrust-install command.
You cannot delete this view.
You can use the Default Trust View to define POSIX attributes for Active Directory domain users and groups that are presented by the IdM service to its clients. You can define custom POSIX attributes for Active Directory users and groups by using the Default Trust View. Doing so overrides the values in Active Directory.
Note
The Default Trust View can only be used to override attribute values for Active Directory domain users and groups that are presented by the IdM service to clients. It cannot be used to override the attribute values for users and groups native to the IdM service.
A new ID view overrides the attribute values from the Default Trust View. In other words, the Default Trust View overrides the original data, and then the new ID view makes further changes, potentially overriding changes made by the Default Trust View. If an attribute is not overridden by the new ID view, the value from the Default Trust View is used. You cannot assign different ID views to users and groups; they always inherit the values of the Default Trust View.
Red Hat Enterprise Linux (RHEL) 7.1 and later support host-specific ID views.
Host-specific ID views are not supported on clients running RHEL 6.4 to 7.0.
On RHEL 6.3 and earlier, clients can request that a specific ID view be applied.
To do so, change the base distinguished name on the client to cn=id_view_name,cn=views,cn=compat,dc=example,dc=com.
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. If an ID collision occurs, then you can update the conflicting IDs in IdM.
You can use ID views even if there is an Active Directory policy preventing the use of attributes.
When Active Directory users authenticate to clients running SSSD, or authenticate using a compat LDAP tree, the new values are used in the authentication process.
ID views can override or specify any of the following user attributes:
Table 8.1. ID View Manageable User Attributes
| Attribute | Description |
|---|---|
Login name (uid) | The alphanumeric ID of the user, entered when logging in to a system. |
GECOS entry (gecos) | A comment regarding the user. |
UID number (uidNumber) | The numeric ID of the user, used by the OS. |
GID number (gidNumber) | The numeric ID of the user's primary group. |
Login shell (loginShell) | The default shell that launches when the user logs in. |
Home directory (homeDirectory) | The initial directory a user owns and is placed in when logging in. |
SSH public keys (ipaSshPubkey) | A user's SSH public key. |
Certificate (userCertificate) | A user's X509 certificate. |
The following table describes the group attributes that an ID view can override or define:
Table 8.2. ID View Manageable Group Attributes
| Attribute | Description |
|---|---|
Group name (cn) | The alphanumeric ID of the group. |
Group GID number (gidNumber) | The numeric ID of the group, used by the OS. |
Important
Only IdM users can manage ID views. Active Directory users cannot manage them.
You can override attributes by creating an ID view and adding a user ID override in the ID view, and specify the required attribute value. Then, you apply the ID view to a specific host.
In some scenarios, you might have to clear the SSSD cache to ensure that the overridden attributes are applied.
Use the sss_cache -E command or restart the SSSD service to clear the SSSD cache.
Log in to the IdM web console and navigate to → to manage ID views. The view is the only view available. Click to create an ID view, and give it a name and a description. You can customize the view after creating it.
You can override the following attributes with an ID view from the web console:
The user to override
The user login
GECOS, user UID, and GID
The user certificate
The login shell and the home directory
Click the tab and then click to override user settings.
Note
You can also create ID views for groups. However, settings are limited to the group name and the GID.
Upon creation of the ID view, select the hosts that inherit the ID view.
You can use short usernames or group names for resolution and authentication in Active Directory instead of the user principal name (UPN) notation.
The UPN notation consists of the user account name and the domain name joined by the "at" (@) sign.
For example, user@domain or someuser@example.com.
The short name notation, which strips the domain of the user, is supported in an IdM environment that trusts Active Directory, or on Red Hat Enterprise Linux servers that are members of Active Directory using SSSD.
You can use the ipa config-mod command with the --domain-resolution-order option to set the domain resolution order to all clients in the trust.
This operation enables the short name notation.
For example, short name notation substitutes a user from Active Directory with the login of aduser05@ad.example.com with aduser05.
When using SSH to log in to a client, ssh aduser05@ad.example.com@client.lab.example.com becomes ssh aduser05@client.lab.example.com.
Important
You must use qualified names if a username exists in multiple domains or if the SSSD configuration includes the default_domain_suffix option and you want to query a domain that is not specified with the option.
Red Hat recommends applying the domain resolution both globally and for an ID view. Clients consult the following three locations, in order, to determine the domain resolution order, and use the first one found.
The local
sssd.confconfiguration fileThe ID view configuration
The global IdM configuration
Note
You can only set the domain resolution order on a client in environments in which Red Hat Enterprise Linux is directly integrated into an Active Directory environment.
To specify the order in which a list of domains is searched to return a match for a given username, use the domain_resolution_order option in the [sssd] section of the /etc/sssd/sssd.conf configuration file:
[sssd]
...output omitted...
domain_resolution_order = subdomain1.ad.example.com, subdomain2.ad.example.comYou can configure the domain resolution order globally so that it applies to all clients in the trust.
To do so, use the ipa config-mod command.
The following example shows how to configure the domain resolution order in an IdM domain that trusts an Active Directory forest with multiple subdomains.
With this order, users from both the IdM domain and from the trusted Active Directory forest can log in using short names.
Note
Notice the use of a colon to separate each domain or subdomain.
[user@host ~]$ipa config-mod \ --domain-resolution-order='idm.example.com:ad.example.com:\ domain1.ad.example.com:domainX.ad.example.com'Maximum username length: 32 Home directory base: /home ...output omitted...Domain Resolution Order: idm.example.com:ad.example.com:domain1.ad.example.com:domainX.ad.example.com...output omitted...
Use this option to apply the setting to the clients in a specific domain. The following example shows how to configure the domain resolution order for a specific view:
[user@host ~]$ipa idview-add custom-view \--desc "ID View for Custom Short Name Resolution" \--domain-resolution-order subdomain2.ad.example.com:subdomain1.ad.example.com...output omitted... ID View Name: custom Description: ID View for Custom Short Name Resolution Domain Resolution Order: subdomain2.ad.example.com:subdomain1.ad.example.com [user@host ~]$ipa idview-apply custom-view --hosts server.idm.example.com...output omitted... Applied ID View "custom-view" ----------------------------------- hosts: server.idm.example.com ...output omitted...
References
For more information, refer to Managing IdM Users, Groups, Hosts, and Access Control Rules at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/index
For more information, refer to Installing Trust Between IdM and AD at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/installing_trust_between_idm_and_ad/index
sssd-ad(5) man page.
