Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 35. Using an ID view to override a user attribute value on an IdM client
Use ID views to override user attribute values such as login names, home directories, and SSH keys on specific Identity Management (IdM) clients. ID views let administrators customize user attributes per host without changing the centrally stored LDAP data.
For example, you can specify a different home directory for a user on the IdM client that the user most commonly uses, such as /home/encrypted/username on one client and /dropbox/username on another, without modifying the user’s LDAP entry.
35.1. ID views Link kopierenLink in die Zwischenablage kopiert!
Customize POSIX attributes for users and groups on specific Identity Management (IdM) clients using ID views to support different environment requirements. ID views enable you to override values like UIDs, home directories, and login names without modifying centrally defined user data.
An ID view in Identity Management (IdM) is an IdM client-side view specifying the following information:
- New values for centrally defined POSIX user or group attributes
- The client host or hosts on which the new values apply.
An ID view contains one or more overrides. An override is a specific replacement of a centrally defined POSIX attribute value.
You can only define an ID view for an IdM client centrally on IdM servers. You cannot configure client-side overrides for an IdM client locally.
For example, you can use ID views to achieve the following goals:
-
Define different attribute values for different environments. For example, you can allow the IdM administrator or another IdM user to have different home directories on different IdM clients: you can configure
/home/encrypted/usernameto be this user’s home directory on one IdM client and/dropbox/usernameon another client. Using ID views in this situation is convenient as alternatively, for example, changingfallback_homedir,override_homediror other home directory variables in the client’s/etc/sssd/sssd.conffile would affect all users. See Adding an ID view to override an IdM user home directory on an IdM client for an example procedure. - Replace a previously generated attribute value with a different value, such as overriding a user’s UID. This ability can be useful when you want to achieve a system-wide change that would otherwise be difficult to do on the LDAP side, for example make 1009 the UID of an IdM user. IdM ID ranges, which are used to generate an IdM user UID, never start as low as 1000 or even 10000. If a reason exists for an IdM user to impersonate a local user with UID 1009 on all IdM clients, you can use ID views to override the UID of this IdM user that was generated when the user was created in IdM.
You can only apply ID views to IdM clients, not to IdM servers.
35.2. Potential negative impact of ID views on SSSD performance Link kopierenLink in die Zwischenablage kopiert!
Understand how ID views can reduce System Security Services Daemon (SSSD) performance by preventing certain optimizations during group lookups. This impact becomes most apparent when the SSSD cache is empty or recently cleared.
When you define an ID view, IdM places the desired override value in the IdM server’s SSSD cache. The SSSD running on an IdM client then retrieves the override value from the server cache.
Applying an ID view can have a negative impact on SSSD performance, because certain optimizations and ID views cannot run at the same time. For example, ID views prevent SSSD from optimizing the process of looking up groups on the server:
- With ID views, SSSD must check every member on the returned list of group member names if the group name is overridden.
- Without ID views, SSSD can only collect the user names from the member attribute of the group object.
This negative effect becomes most apparent when the SSSD cache is empty or after you clear the cache, which makes all entries invalid.
35.3. Attributes an ID view can override Link kopierenLink in die Zwischenablage kopiert!
ID views in Identity Management (IdM) can override POSIX user and group attributes to customize account properties on specific hosts. This enables per-host customization of login names, UIDs, GIDs, home directories, and other attributes without changing global user definitions.
User and group ID overrides can define new values for the following POSIX attributes:
- User attributes
-
Login name (
uid) -
GECOS entry (
gecos) -
UID number (
uidNumber) -
GID number (
gidNumber) -
Login shell (
loginShell) -
Home directory (
homeDirectory) -
SSH public keys (
ipaSshPubkey) -
Certificate (
userCertificate)
-
Login name (
- Group attributes
-
Group name (
cn) -
Group GID number (
gidNumber)
-
Group name (
35.4. Getting help for ID view commands Link kopierenLink in die Zwischenablage kopiert!
Access built-in help documentation for ID view management commands in the Identity Management (IdM) CLI to understand command syntax and available options. This helps you efficiently manage ID views and overrides.
Prerequisites
- You have obtained a Kerberos ticket for an IdM user.
Procedure
To display all commands used to manage ID views and overrides:
$ ipa help idviews ID Views Manage ID Views IPA allows to override certain properties of users and groups[...] [...] Topic commands: idoverridegroup-add Add a new Group ID override idoverridegroup-del Delete a Group ID override [...]To display detailed help for a particular command, add the
--helpoption to the command:$ ipa idview-add --help Usage: ipa [global-options] idview-add NAME [options] Add a new ID View. Options: -h, --help show this help message and exit --desc=STR Description [...]
35.5. Using an ID view to override the login name of an IdM user on a specific host Link kopierenLink in die Zwischenablage kopiert!
Create an ID view in Identity Management (IdM) to override a user’s POSIX attributes, such as their login name, on a specific host without changing the user’s global IdM account.
Create an ID view to map the IdM user idm_user to the alias user_1234 for logins on client1. This configuration overrides the default username on the specified host, allowing the user to authenticate with localized credentials.
Prerequisites
- You are logged in as IdM administrator.
Procedure
On the IdM server, create a new ID view. For example, to create an ID view named
example_for_client1:$ ipa idview-add example_for_client1 --------------------------- Added ID View "example_for_client1" --------------------------- ID View Name: example_for_client1Add a user override to the example_for_client1 ID view. To override the user login:
-
Enter the
ipa idoverrideuser-addcommand - Add the name of the ID view
- Add the user name, also called the anchor
Add the
--loginoption:$ ipa idoverrideuser-add example_for_client1 idm_user --login=user_1234 ----------------------------- Added User ID override "idm_user" ----------------------------- Anchor to override: idm_user User login: user_1234For a list of the available options, run
ipa idoverrideuser-add --help.NoteThe
ipa idoverrideuser-add --certificatecommand replaces all existing certificates for the account in the specified ID view. To append an additional certificate, use theipa idoverrideuser-add-certcommand instead:$ ipa idoverrideuser-add-cert example_for_client1 user --certificate="MIIEATCC..."
-
Enter the
-
Optional: Using the
ipa idoverrideuser-modcommand, you can specify new attribute values for an existing user override. Apply
example_for_client1to theclient1.idm.example.comhost:$ ipa idview-apply example_for_client1 --hosts=client1.idm.example.com ----------------------------- Applied ID View "example_for_client1" ----------------------------- hosts: client1.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------NoteThe
ipa idview-applycommand also accepts the--hostgroupsoption. The option applies the ID view to hosts that belong to the specified host group, but does not associate the ID view with the host group itself. Instead, the--hostgroupsoption expands the members of the specified host group and applies the--hostsoption individually to every one of them.This means that if a host is added to the host group in the future, the ID view does not apply to the new host.
To apply the new configuration to the IdM client system immediately:
SSH to the client system as root:
$ ssh root@client1 Password:On the IdM client, clear the SSSD cache:
# sss_cache -E- On the IdM client, restart the SSSD daemon:
# systemctl restart sssd
Verification
If you have the credentials of user_1234, you can use them to log in to the IdM client:
SSH to the client system using user_1234 as the login name:
# ssh user_1234@client1.idm.example.com Password: Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 $On the client system, display the working directory:
$ pwd /home/idm_user/
Alternatively, if you have root credentials on the IdM client, you can use them to check the output of the
idcommand for idm_user and user_1234:# id idm_user uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user) # user_1234 uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)
35.6. Modifying an IdM ID view Link kopierenLink in die Zwischenablage kopiert!
Update ID view overrides to change POSIX attribute values like home directories or UIDs for specific users on Identity Management (IdM) clients. This way, you can adjust client-specific user configurations without changing centrally defined user data.
In this example, you modify an ID view to enable the user named idm_user to use the /home/user_1234/ directory as the user home directory instead of /home/idm_user/ on the client1.idm.example.com IdM client.
Prerequisites
- You have root access to the IdM client system.
- You are logged in as a user with the required privileges, for example admin.
- You have an ID view configured for idm_user that applies to the IdM client.
Procedure
On the IdM client, create the directory that you want idm_user to use on client1.idm.example.com as the user home directory:
# mkdir /home/user_1234/On the IdM client, change the ownership of the directory:
# chown idm_user:idm_user /home/user_1234/On the IdM server, display the ID view, including the hosts to which the ID view is currently applied. To display the ID view named
example_for_client1:$ ipa idview-show example_for_client1 --all dn: cn=example_for_client1,cn=views,cn=accounts,dc=idm,dc=example,dc=com ID View Name: example_for_client1 User object override: idm_user Hosts the view applies to: client1.idm.example.com objectclass: ipaIDView, top, nsContainerThe output shows that the ID view currently applies to client1.idm.example.com.
On the IdM server, modify the user override of the example_for_client1 ID view. To override the user home directory:
-
Enter the
ipa idoverrideuser-addcommand - Add the name of the ID view
- Add the user name, also called the anchor
Add the
--homediroption:$ ipa idoverrideuser-mod example_for_client1 idm_user --homedir=/home/user_1234 ----------------------------- Modified a User ID override "idm_user" ----------------------------- Anchor to override: idm_user User login: user_1234 Home directory: /home/user_1234/
For a list of the available options, run
ipa idoverrideuser-mod --help.-
Enter the
To apply the new configuration to the client1.idm.example.com system immediately:
SSH to the IdM client system as root:
$ ssh root@client1 Password:On the IdM client, clear the SSSD cache:
# sss_cache -E- On the IdM client, restart the SSSD daemon:
# systemctl restart sssd
Verification
SSHto the client system as idm_user:# ssh idm_user@client1.idm.example.com Password: Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 [user_1234@client1 ~]$On the client system, print the working directory:
$ pwd /home/user_1234/
35.7. Adding an ID view to override an IdM user home directory on an IdM client Link kopierenLink in die Zwischenablage kopiert!
Create an ID view in Identity Management (IdM) to override POSIX attributes like home directories for specific users on specific clients. With this, you can customize user environments without changing global user settings.
For example, you can create an ID view to override the home directory of an IdM user on an IdM client.
Prerequisites
- You have root access to the IdM client system.
- You are logged in as a user with the required privileges, for example admin.
Procedure
On the IdM client, create the directory that you want idm_user to use as the user home directory:
# mkdir /home/user_1234/On the IdM client, change the ownership of the directory:
# chown idm_user:idm_user /home/user_1234/On the IdM server, create an ID view. For example, to create an ID view named example_for_client1:
$ ipa idview-add example_for_client1 --------------------------- Added ID View "example_for_client1" --------------------------- ID View Name: example_for_client1On the IdM server, add a user override to the example_for_client1 ID view. To override the user home directory:
-
Enter the
ipa idoverrideuser-addcommand - Add the name of the ID view
- Add the user name, also called the anchor
-
Add the
--homediroption:
$ ipa idoverrideuser-add example_for_client1 idm_user --homedir=/home/user_1234 ----------------------------- Added User ID override "idm_user" ----------------------------- Anchor to override: idm_user Home directory: /home/user_1234/-
Enter the
On the IdM server, apply
example_for_client1to theclient1.idm.example.comhost:$ ipa idview-apply example_for_client1 --hosts=client1.idm.example.com ----------------------------- Applied ID View "example_for_client1" ----------------------------- hosts: client1.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------NoteThe
ipa idview-applycommand also accepts the--hostgroupsoption. The option applies the ID view to hosts that belong to the specified host group, but does not associate the ID view with the host group itself. Instead, the--hostgroupsoption expands the members of the specified host group and applies the--hostsoption individually to every one of them.This means that if a host is added to the host group in the future, the ID view does not apply to the new host.
To apply the new configuration to the IdM client system immediately:
SSH to the IdM client system as root:
$ ssh root@client1 Password:On the IdM client, clear the SSSD cache:
# sss_cache -E- On the IdM client, restart the SSSD daemon:
# systemctl restart sssd
Verification
SSHto the IdM client system as idm_user:# ssh idm_user@client1.idm.example.com Password: Activate the web console with: systemctl enable --now cockpit.socket Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 [idm_user@client1 /]$Print the working directory:
$ pwd /home/user_1234/
35.8. Applying an ID view to an IdM host group Link kopierenLink in die Zwischenablage kopiert!
Apply an ID view to all hosts in a host group in Identity Management (IdM) to override POSIX attributes for multiple systems simultaneously. This enables consistent user attribute customization across groups of hosts without modifying global user settings.
The ipa idview-apply command accepts the --hostgroups option. However, the option acts as a one-time operation that applies the ID view to hosts that currently belong to the specified host group, but does not dynamically associate the ID view with the host group itself. The --hostgroups option expands the members of the specified host group and applies the --hosts option individually to every one of them.
If you add a new host to the host group later, you must apply the ID view to the new host manually, using the ipa idview-apply command with the --hosts option.
Similarly, if you remove a host from a host group, the ID view is still assigned to the host after the removal. To unapply the ID view from the removed host, you must run the ipa idview-unapply id_view_name --hosts=name_of_the_removed_host command. .Prerequisites
- Ensure that the ID view you want to apply to the host group exists in IdM. For example, to create an ID view to override the GID for an AD user, see Overriding Default Trust View attributes for an AD user on an IdM client with an ID view
Procedure
Create a host group and add hosts to it:
Create a host group. For example, to create a host group named baltimore:
[root@server ~]# ipa hostgroup-add --desc="Baltimore hosts" baltimore --------------------------- Added hostgroup "baltimore" --------------------------- Host-group: baltimore Description: Baltimore hostsAdd hosts to the host group. For example, to add the host102 and host103 to the baltimore host group:
[root@server ~]# ipa hostgroup-add-member --hosts={host102,host103} baltimore Host-group: baltimore Description: Baltimore hosts Member hosts: host102.idm.example.com, host103.idm.example.com ------------------------- Number of members added 2 -------------------------
Apply an ID view to the hosts in the host group. For example, to apply the example_for_host1 ID view to the baltimore host group:
[root@server ~]# ipa idview-apply --hostgroups=baltimore ID View Name: example_for_host1 ----------------------------------------- Applied ID View "example_for_host1" ----------------------------------------- hosts: host102.idm.example.com, host103.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 2 ---------------------------------------------Add a new host to the host group and apply the ID view to the new host:
Add a new host to the host group. For example, to add the somehost.idm.example.com host to the baltimore host group:
[root@server ~]# ipa hostgroup-add-member --hosts=somehost.idm.example.com baltimore Host-group: baltimore Description: Baltimore hosts Member hosts: host102.idm.example.com, host103.idm.example.com,somehost.idm.example.com ------------------------- Number of members added 1 -------------------------Optional: Display the ID view information. For example, to display the details about the example_for_host1 ID view:
[root@server ~]# ipa idview-show example_for_host1 --all dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com ID View Name: example_for_host1 [...] Hosts the view applies to: host102.idm.example.com, host103.idm.example.com objectclass: ipaIDView, top, nsContainerThe output shows that the ID view is not applied to somehost.idm.example.com, the newly-added host in the baltimore host group.
Apply the ID view to the new host. For example, to apply the example_for_host1 ID view to somehost.idm.example.com:
[root@server ~]# ipa idview-apply --host=somehost.idm.example.com ID View Name: example_for_host1 ----------------------------------------- Applied ID View "example_for_host1" ----------------------------------------- hosts: somehost.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------
Verification
Display the ID view information again:
[root@server ~]# ipa idview-show example_for_host1 --all dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com ID View Name: example_for_host1 [...] Hosts the view applies to: host102.idm.example.com, host103.idm.example.com, somehost.idm.example.com objectclass: ipaIDView, top, nsContainerThe output shows that ID view is now applied to somehost.idm.example.com, the newly-added host in the baltimore host group.
35.9. Migrating NIS domains to Identity Management Link kopierenLink in die Zwischenablage kopiert!
Migrate your NIS domain users and groups to Identity Management (IdM), using ID views to preserve existing host-specific UIDs and GIDs so that file and directory permissions remain intact after migration.
Prerequisites
-
You authenticated yourself as an admin using the
kinit admincommand.
Procedure
Add users and groups in the IdM domain.
-
Create users using the
ipa user-addcommand. For more information, see Adding users to IdM. -
Create groups using the
ipa group-addcommand. For more information see: Adding groups to IdM.
-
Create users using the
Override IDs IdM generated during the user creation:
-
Create a new ID view using
ipa idview-addcommand. For more information see: Getting help for ID view commands. -
Add ID overrides for the users and groups to the ID view using
ipa idoverrideuser-addandidoverridegroup-addrespectively.
-
Create a new ID view using
-
Assign the ID view to the specific hosts using
ipa idview-applycommand. - Decommission the NIS domains.
Verification
To check if all users and groups were added to the ID view correctly, use the
ipa idview-showcommand.$ ipa idview-show example-view ID View Name: example-view User object overrides: example-user1 Group object overrides: example-group
35.10. Using Ansible to override the login name and home directory of an IdM user on a specific host Link kopierenLink in die Zwischenablage kopiert!
Use the ansible-freeipa idoverrideuser module to override an Identity Management (IdM) user’s POSIX attributes, such as their login name and home directory, on a specific host for custom host-specific configurations.
The procedure uses the example of an ID view that enables an IdM user named idm_user to log in to an IdM client named client1.idm.example.com by using the user_1234 login name. Additionally, the ID view modifies the home directory of idm_user so that after logging in to client1, the user home directory is /home/user_1234/.
Prerequisites
On the control node:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Create your Ansible playbook file add-idoverrideuser-with-name-and-homedir.yml with the following content:
--- - name: Playbook to manage idoverrideuser hosts: ipaserver become: false gather_facts: false vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Ensure idview_for_client1 is present idview: ipaadmin_password: "{{ ipaadmin_password }}" name: idview_for_client1 - name: Ensure idview_for_client1 is applied to client1.idm.example.com idview: ipaadmin_password: "{{ ipaadmin_password }}" name: idview_for_client1 host: client1.idm.example.com action: member - name: Ensure idm_user is present in idview_for_client1 with homedir /home/user_1234 and name user_1234 ipaidoverrideuser: ipaadmin_password: "{{ ipaadmin_password }}" idview: idview_for_client1 anchor: idm_user name: user_1234 homedir: /home/user_1234Run the playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file::
$ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/inventory <path_to_playbooks_directory>/add-idoverrideuser-with-name-and-homedir.ymlOptional: If you have
rootcredentials, you can apply the new configuration to the IdM client system immediately:SSH to the client system as
root:$ ssh root@client1 Password:On the IdM client, clear the SSSD cache:
# sss_cache -EOn the IdM client, restart the SSSD daemon:
# systemctl restart sssd
Verification
SSHto IdM client as idm_user:# ssh idm_user@client1.idm.example.com Password: Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 [user_1234@client1 ~]$Print the working directory:
$ pwd /home/user_1234/
35.11. Using Ansible to configure an ID view that enables an SSH key login on an IdM client Link kopierenLink in die Zwischenablage kopiert!
Use the idoverrideuser Ansible module to assign an SSH key to an Identity Management (IdM) user for key-based login on a specific IdM client.
The procedure uses the example of an ID view that enables an IdM user named idm_user to log in to an IdM client named client1.idm.example.com with an SSH key.
This ID view can be used to enhance a specific HBAC rule.
Prerequisites
On the control node:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.'s SSH public key. - The idview_for_client1 ID view exists.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Create your Ansible playbook file ensure-idoverrideuser-can-login-with-sshkey.yml with the following content:
--- - name: Playbook to manage idoverrideuser hosts: ipaserver become: false gather_facts: false vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Ensure test user idm_user is present in idview idview_for_client1 with sshpubkey ipaidoverrideuser: ipaadmin_password: "{{ ipaadmin_password }}" idview: idview_for_client1 anchor: idm_user sshpubkey: - ssh-rsa AAAAB3NzaC1yc2EAAADAQABAAABgQCqmVDpEX5gnSjKuv97Ay ... - name: Ensure idview_for_client1 is applied to client1.idm.example.com ipaidview: ipaadmin_password: "{{ ipaadmin_password }}" name: idview_for_client1 host: client1.idm.example.com action: memberRun the playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
$ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/inventory <path_to_playbooks_directory>/ensure-idoverrideuser-can-login-with-sshkey.ymlOptional: If you have
rootcredentials, you can apply the new configuration to the IdM client system immediately:SSH to the client system as
root:$ ssh root@client1 Password:On the IdM client, clear the SSSD cache:
# sss_cache -EOn the IdM client, restart the SSSD daemon:
# systemctl restart sssd
Verification
Use the public key to
SSHto the client system:# ssh -i ~/.ssh/id_rsa.pub idm_user@client1.idm.example.com Last login: Sun Jun 21 22:34:25 2023 from 192.168.122.229 [idm_user@client1 ~]$
The output confirms that you have logged in successfully.
35.12. Using Ansible to give a user ID override access to the local sound card on an IdM client Link kopierenLink in die Zwischenablage kopiert!
Use the ansible-freeipa group and idoverrideuser modules to grant Identity Management (IdM) or AD users access to the sound card on an IdM client by adding them to the local audio group.
The procedure uses the example of the Default Trust View ID view to which the aduser@addomain.com ID override is added in the first playbook task. In the next playbook task, an audio group is created in IdM with the GID of 63, which corresponds to the GID of local audio groups on RHEL hosts. At the same time, the aduser@addomain.com ID override is added to the IdM audio group as a member.
Prerequisites
-
You have
rootaccess to the IdM client on which you want to perform the first part of the procedure. In the example, this is client.idm.example.com. You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
On client.idm.example.com, add
[SUCCESS=merge]to the/etc/nsswitch.conffile:[...] # Allow initgroups to default to the setting for group. initgroups: sss [SUCCESS=merge] filesIdentify the GID of the local
audiogroup:$ getent group audio --------------------- audio:x:63On your Ansible control node, create an add-aduser-to-audio-group.yml playbook with a task to add the aduser@addomain.com user override to the Default Trust View:
--- - name: Playbook to manage idoverrideuser hosts: ipaserver become: false tasks: - name: Add aduser@addomain.com user to the Default Trust View ipaidoverrideuser: ipaadmin_password: "{{ ipaadmin_password }}" idview: "Default Trust View" anchor: aduser@addomain.comUse another playbook task in the same playbook to add the group audio to IdM with the
GIDof 63. Add the aduser idoverrideuser to the group:- name: Add the audio group with the aduser member and GID of 63 ipagroup: ipaadmin_password: "{{ ipaadmin_password }}" name: audio idoverrideuser: - aduser@addomain.com gidnumber: 63- Save the file.
Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
$ ansible-playbook --vault-password-file=password_file -v -i inventory add-aduser-to-audio-group.yml
Verification
Log in to the IdM client as the AD user:
$ ssh aduser@addomain.com@client.idm.example.comVerify the group membership of the AD user:
$ id aduser@addomain.com uid=702801456(aduser@addomain.com) gid=63(audio) groups=63(audio)
35.13. Using Ansible to ensure an IdM user is present in an ID view with a specific UID Link kopierenLink in die Zwischenablage kopiert!
Use the idoverrideuser Ansible module to assign a specific UID to an Identity Management (IdM) user in an ID view so that both IdM and local users can share the same files.
If you are working in a lab where you have your own computer but your /home/ directory is in a shared drive exported by a server, you can have two users:
- One that is system-wide user, stored centrally in Identity Management (IdM).
- One whose account is local, that is stored on the system in question.
Complete this procedure to use the ansible-freeipa idoverrideuser module to:
- Apply an ID view to host01 named idview_for_host01.
-
Ensure, in idview_for_host01, the presence of a user ID override for idm_user with the
UIDof 20001.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Create an Ansible playbook file named
ensure-idmuser-and-local-user-have-access-to-same-files.ymlwith the following content:--- - name: Ensure both local user and IdM user have access to same files hosts: ipaserver become: false gather_facts: false tasks: - name: Ensure idview_for_host1 is applied to host1.idm.example.com ipaidview: ipaadmin_password: "{{ ipaadmin_password }}" name: idview_for_host01 host: host1.idm.example.com - name: Ensure idmuser is present in idview_for_host01 with the UID of 20001 ipaidoverrideuser: ipaadmin_password: "{{ ipaadmin_password }}" idview: idview_for_host01 anchor: idm_user UID: 20001- Save the file.
Run the playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
$ ansible-playbook --vault-password-file=password_file -v -i inventory ensure-idmuser-and-local-user-have-access-to-same-files.yml
35.14. Using Ansible to ensure an IdM user can log in to an IdM client with two certificates Link kopierenLink in die Zwischenablage kopiert!
Use the idoverrideuser Ansible module to require smart card authentication for an Identity Management (IdM) user on a specific client.
Complete this procedure to use the ansible-freeipa idoverrideuser module to:
- Apply an ID view to host01 named idview_for_host01.
- Ensure, in idview_for_host01, the presence of a user ID override for idm_user with two certificates.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Create your Ansible playbook file
ensure-idmuser-present-in-idview-with-certificates.ymlwith the following content:--- - name: Ensure both local user and IdM user have access to same files hosts: ipaserver become: false gather_facts: false tasks: - name: Ensure idview_for_host1 is applied to host01.idm.example.com ipaidview: ipaadmin_password: "{{ ipaadmin_password }}" name: idview_for_host01 host: host01.idm.example.com - name: Ensure an IdM user is present in ID view with two certificates ipaidoverrideuser: ipaadmin_password: "{{ ipaadmin_password }}" idview: idview_for_host01 anchor: idm_user certificate: - "{{ lookup('file', 'cert1.b64', rstrip=False) }}" - "{{ lookup('file', 'cert2.b64', rstrip=False) }}"The
rstrip=Falsedirective causes the white space not to be removed from the end of the looked-up file.- Save the file.
Run the playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
$ ansible-playbook --vault-password-file=password_file -v -i inventory ensure-idmuser-present-in-idview-with-certificates.yml
35.15. Using Ansible to give an IdM group access to the sound card on an IdM client Link kopierenLink in die Zwischenablage kopiert!
Use the ansible-freeipa idview and idoverridegroup modules to grant Identity Management (IdM) or AD groups access to the sound card on an IdM client by mapping them to the local audio group.
The procedure uses the example of the idview_for_host01 ID view to which the audio group ID override is added with the GID of 63, which corresponds to the GID of local audio groups on RHEL hosts. The idview_for_host01 ID view is applied to an IdM client named host01.idm.example.com.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Create an Ansible playbook file named
give-idm-group-access-to-sound-card-on-idm-client.ymlwith the following content:$ getent group audio --------------------- audio:x:63On your Ansible control node, create an give-idm-group-access-to-sound-card-on-idm-client.yml playbook with the following tasks:
--- - name: Playbook to give IdM group access to sound card on IdM client hosts: ipaserver become: false tasks: - name: Ensure the audio group exists in IdM ipagroup: ipaadmin_password: "{{ ipaadmin_password }}" name: audio - name: Ensure idview_for_host01 exists and is applied to host01.idm.example.com ipaidview: ipaadmin_password: "{{ ipaadmin_password }}" name: idview_for_host01 host: host01.idm.example.com - name: Add an override for the IdM audio group with GID 63 to idview_for_host01 ipaidoverridegroup: ipaadmin_password: "{{ ipaadmin_password }}" idview: idview_for_host01 anchor: audio GID: 63- Save the file.
Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
$ ansible-playbook --vault-password-file=password_file -v -i inventory give-idm-group-access-to-sound-card-on-idm-client.yml
Verification
On an IdM client, obtain IdM administrator’s credentials:
$ kinit admin Password:Create a test IdM user:
$ ipa user-add testuser --first test --last user --password User login [tuser]: Password: Enter Password again to verify: ------------------ Added user "tuser" ------------------Add the user to the IdM audio group:
$ ipa group-add-member --tuser audioLog in to host01.idm.example.com as tuser:
$ ssh tuser@host01.idm.example.comVerify the group membership of the user:
$ id tuser uid=702801456(tuser) gid=63(audio) groups=63(audio)