Search

Chapter 37. Using an ID view to override a user attribute value on an IdM client

download PDF

If an Identity Management (IdM) user want to override some of their user or group attributes stored in the IdM LDAP server, for example the login name, home directory, certificate used for authentication, or SSH keys, you as IdM administrator can redefine these values on specific IdM clients by using IdM ID views. For example, you can specify a different home directory for a user on the IdM client that the user most commonly uses for logging in to IdM.

This chapter describes how to redefine a POSIX attribute value associated with an IdM user on a host enrolled into IdM as a client.

37.1. ID views

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/username to be this user’s home directory on one IdM client and /dropbox/username on another client. Using ID views in this situation is convenient as alternatively, for example, changing fallback_homedir, override_homedir or other home directory variables in the client’s /etc/sssd/sssd.conf file 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.
Important

You can only apply ID views to IdM clients, not to IdM servers.

37.2. Potential negative impact of ID views on SSSD performance

When you define an ID view, IdM places the desired override value in the IdM server’s System Security Services Daemon (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 System Security Services Daemon (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.

37.3. Attributes an ID view can override

ID views consist of user and group ID overrides. The overrides define the new POSIX attribute values.

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)
Group attributes
  • Group name (cn)
  • Group GID number (gidNumber)

37.4. Getting help for ID view commands

You can get help for commands involving Identity Management (IdM) ID views on the IdM command-line interface (CLI).

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 --help option 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
    [...]

37.5. Using an ID view to override the login name of an IdM user on a specific host

Follow this procedure to create an ID view for a specific IdM client that overrides a POSIX attribute value associated with a specific IdM user. 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 host1 using the user_1234 login name.

Prerequisites

  • You are logged in as IdM administrator.

Procedure

  1. Create a new ID view. For example, to create an ID view named example_for_host1:

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  2. Add a user override to the example_for_host1 ID view. To override the user login:

    • Enter the ipa idoverrideuser-add command
    • Add the name of the ID view
    • Add the user name, also called the anchor
    • Add the --login option:

      $ ipa idoverrideuser-add example_for_host1 idm_user --login=user_1234
      -----------------------------
      Added User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234

      For a list of the available options, run ipa idoverrideuser-add --help.

      Note

      The ipa idoverrideuser-add --certificate command replaces all existing certificates for the account in the specified ID view. To append an additional certificate, use the ipa idoverrideuser-add-cert command instead:

      $ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
  3. Optional: Using the ipa idoverrideuser-mod command, you can specify new attribute values for an existing user override.
  4. Apply example_for_host1 to the host1.idm.example.com host:

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    Note

    The ipa idview-apply command also accepts the --hostgroups option. 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 --hostgroups option expands the members of the specified host group and applies the --hosts option 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.

  5. To apply the new configuration to the host1.idm.example.com system immediately:

    1. SSH to the system as root:

      $ ssh root@host1
      Password:
    2. Clear the SSSD cache:

      root@host1 ~]# sss_cache -E
    3. Restart the SSSD daemon:
    root@host1 ~]# systemctl restart sssd

Verification steps

  • If you have the credentials of user_1234, you can use them to log in to IdM on host1:

    1. SSH to host1 using user_1234 as the login name:

      [root@r8server ~]# ssh user_1234@host1.idm.example.com
      Password:
      
      Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
      [user_1234@host1 ~]$
    2. Display the working directory:

      [user_1234@host1 ~]$ pwd
      /home/idm_user/
  • Alternatively, if you have root credentials on host1, you can use them to check the output of the id command for idm_user and user_1234:

    [root@host1 ~]# id idm_user
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)
    [root@host1 ~]# user_1234
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)

37.6. Modifying an IdM ID view

An ID view in Identity Management (IdM) overrides a POSIX attribute value associated with a specific IdM user. Follow this procedure to modify an existing ID view. Specifically, it describes how to 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 host1.idm.example.com IdM client.

Prerequisites

  • You have root access to host1.idm.example.com.
  • 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 host1 IdM client.

Procedure

  1. As root, create the directory that you want idm_user to use on host1.idm.example.com as the user home directory:

    [root@host1 /]# mkdir /home/user_1234/
  2. Change the ownership of the directory:

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. Display the ID view, including the hosts to which the ID view is currently applied. To display the ID view named example_for_host1:

    $ 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
      User object override: idm_user
      Hosts the view applies to: host1.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    The output shows that the ID view currently applies to host1.idm.example.com.

  4. Modify the user override of the example_for_host1 ID view. To override the user home directory:

    • Enter the ipa idoverrideuser-add command
    • Add the name of the ID view
    • Add the user name, also called the anchor
    • Add the --homedir option:

      $ ipa idoverrideuser-mod example_for_host1 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.

  5. To apply the new configuration to the host1.idm.example.com system immediately:

    1. SSH to the system as root:

      $ ssh root@host1
      Password:
    2. Clear the SSSD cache:

      root@host1 ~]# sss_cache -E
    3. Restart the SSSD daemon:
    root@host1 ~]# systemctl restart sssd

Verification steps

  1. SSH to host1 as idm_user:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [user_1234@host1 ~]$
  2. Print the working directory:

    [user_1234@host1 ~]$ pwd
    /home/user_1234/

37.7. Adding an ID view to override an IdM user home directory on an IdM client

An ID view in Identity Management (IdM) overrides a POSIX attribute value associated with a specific IdM user. Follow this procedure to create an ID view that applies to idm_user on an IdM client named host1 to enable the user to use the /home/user_1234/ directory as the user home directory instead of /home/idm_user/.

Prerequisites

  • You have root access to host1.idm.example.com.
  • You are logged in as a user with the required privileges, for example admin.

Procedure

  1. As root, create the directory that you want idm_user to use on host1.idm.example.com as the user home directory:

    [root@host1 /]# mkdir /home/user_1234/
  2. Change the ownership of the directory:

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. Create an ID view. For example, to create an ID view named example_for_host1:

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  4. Add a user override to the example_for_host1 ID view. To override the user home directory:

    • Enter the ipa idoverrideuser-add command
    • Add the name of the ID view
    • Add the user name, also called the anchor
    • Add the --homedir option:
    $ ipa idoverrideuser-add example_for_host1 idm_user --homedir=/home/user_1234
    -----------------------------
    Added User ID override "idm_user"
    -----------------------------
      Anchor to override: idm_user
      Home directory: /home/user_1234/
  5. Apply example_for_host1 to the host1.idm.example.com host:

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    Note

    The ipa idview-apply command also accepts the --hostgroups option. 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 --hostgroups option expands the members of the specified host group and applies the --hosts option 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.

  6. To apply the new configuration to the host1.idm.example.com system immediately:

    1. SSH to the system as root:

      $ ssh root@host1
      Password:
    2. Clear the SSSD cache:

      root@host1 ~]# sss_cache -E
    3. Restart the SSSD daemon:
    root@host1 ~]# systemctl restart sssd

Verification steps

  1. SSH to host1 as idm_user:

    [root@r8server ~]# ssh idm_user@host1.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@host1 /]$
  2. Print the working directory:

    [idm_user@host1 /]$ pwd
    /home/user_1234/

37.8. Applying an ID view to an IdM host group

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.

Follow this procedure to achieve the following goals:

  1. How to create a host group and add hosts to it.
  2. How to apply an ID view to the host group.
  3. How to add a new host to the host group and apply the ID view to the new host.

Prerequisites

Procedure

  1. Create a host group and add hosts to it:

    1. 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 hosts
    2. Add 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
      -------------------------
  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
    ---------------------------------------------
  3. Add a new host to the host group and apply the ID view to the new host:

    1. 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
      -------------------------
    2. Optionally, 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, nsContainer

      The output shows that the ID view is not applied to somehost.idm.example.com, the newly-added host in the baltimore host group.

    3. 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 steps

  • 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, nsContainer

    The output shows that ID view is now applied to somehost.idm.example.com, the newly-added host in the baltimore host group.

37.9. Using Ansible to override the login name and home directory of an IdM user on a specific host

Complete this procedure to use the idoverrideuser ansible-freeipa module to create an ID view for a specific Identity Management (IdM) client that overrides a POSIX attribute value associated with a specific IdM user. 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 host1.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 host1, the user home directory is /home/user_1234/.

Prerequisites

  • On the control node:

    • You are using Ansible version 2.14 or later.
    • You have installed the ansible-freeipa package.
    • You have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server in the ~/MyPlaybooks/ directory. You are using RHEL 9.4 or later.
    • You have stored your ipaadmin_password in the secret.yml Ansible vault.
  • The target node, that is the node on which the ansible-freeipa module is executed, is part of the IdM domain as an IdM client, server or replica.

Procedure

  1. 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_host1 is present
        idview:
          ipaadmin_password: ”{{ ipaadmin_password }}"
          name: idview_for_host1
      - name: Ensure idview_for_host1 is applied to host1.idm.example.com
        idview:
          ipaadmin_password: ”{{ ipaadmin_password }}"
          name: idview_for_host1
          host: host1.idm.example.com
          action: member
      - name: Ensure idm_user is present in idview_for_host1 with homedir /home/user_1234 and name user_1234
        ipaidoverrideuser:
          ipaadmin_password: ”{{ ipaadmin_password }}"
          idview: idview_for_host1
          anchor: idm_user
          name: user_1234
          homedir: /home/user_1234
  2. 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 <path_to_inventory_directory>/inventory <path_to_playbooks_directory>/add-idoverrideuser-with-name-and-homedir.yml
  3. [Optional] If you have root credentials, you can apply the new configuration to the host1.idm.example.com system immediately:

    1. SSH to the system as root:

      $ ssh root@host1
      Password:
    2. Clear the SSSD cache:

      root@host1 ~]# sss_cache -E
    3. Restart the SSSD daemon:

      root@host1 ~]# systemctl restart sssd

Verification

  1. SSH to host1 as idm_user:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [user_1234@host1 ~]$
  2. Print the working directory:

    [user_1234@host1 ~]$ pwd
    /home/user_1234/

Additional resources

37.10. Using Ansible to configure an ID view that enables an SSH key login on an IdM client

Complete this procedure to use the idoverrideuser ansible-freeipa module to ensure that an IdM user can use a specific SSH key to log in to 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 host1.idm.example.com with an SSH key.

Note

This ID view can be used to enhance a specific HBAC rule.

Prerequisites

  • On the control node:

    • You are using Ansible version 2.14 or later.
    • You have installed the ansible-freeipa package.
    • You have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server in the ~/MyPlaybooks/ directory. You are using RHEL 9.4 or later.
    • You have stored your ipaadmin_password in the secret.yml Ansible vault.
  • You have access to the idm_user’s SSH public key.
  • The idview_for_host1 ID view exists.
  • The target node, that is the node on which the ansible-freeipa module is executed, is part of the IdM domain as an IdM client, server or replica.

Procedure

  1. 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_host1 with sshpubkey
        ipaidoverrideuser:
          ipaadmin_password: ”{{ ipaadmin_password }}"
          idview: idview_for_host1
          anchor: idm_user
          sshpubkey:
          - ssh-rsa AAAAB3NzaC1yc2EAAADAQABAAABgQCqmVDpEX5gnSjKuv97Ay ...
      - name: Ensure idview_for_host1 is applied to host1.idm.example.com
        ipaidview:
          ipaadmin_password:  ”{{ ipaadmin_password }}"
          name: idview_for_host1
          host: host1.idm.example.com
          action: member
  2. 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 <path_to_inventory_directory>/inventory <path_to_playbooks_directory>/ensure-idoverrideuser-can-login-with-sshkey.yml
  3. [Optional] If you have root credentials, you can apply the new configuration to the host1.idm.example.com system immediately:

    1. SSH to the system as root:

      $ ssh root@host1
      Password:
    2. Clear the SSSD cache:

      root@host1 ~]# sss_cache -E
    3. Restart the SSSD daemon:

      root@host1 ~]# systemctl restart sssd

Verification

  • Use the public key to SSH to host1:

    [root@r8server ~]# ssh -i ~/.ssh/id_rsa.pub idm_user@host1.idm.example.com
    
    Last login: Sun Jun 21 22:34:25 2023 from 192.168.122.229
    [idm_user@host1 ~]$

The output confirms that you have logged in successfully.

Additional resources

37.11. Using Ansible to give a user ID override access to the local sound card on an IdM client

You can use the ansible-freeipa group and idoverrideuser modules to make Identity Management (IdM) or Active Directory (AD) users members of the local audio group on an IdM client. This grants the IdM or AD users privileged access to the sound card on the host. 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 root access 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.14 or later.
    • You have installed the ansible-freeipa package on the Ansible controller.
    • You are using RHEL 9.4 or later.
    • 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_password.
  • The AD forest is in trust with IdM. In the example, the name of the AD domain is addomain.com and the fully-qualified domain name (FQDN) of the AD user whose presence in the local audio group is being ensured is aduser@addomain.com.
  • The target node, that is the node on which the ansible-freeipa module is executed, is part of the IdM domain as an IdM client, server or replica.

Procedure

  1. On client.idm.example.com, add [SUCCESS=merge] to the /etc/nsswitch.conf file:

    [...]
    # Allow initgroups to default to the setting for group.
    initgroups: sss [SUCCESS=merge] files
  2. Identify the GID of the local audio group:

    $ getent group audio
    ---------------------
    audio:x:63
  3. On 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.com
  4. Use another playbook task in the same playbook to add the group audio to IdM with the GID of 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
  5. Save the file.
  6. 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

  1. Log in to the IdM client as the AD user:

    $ ssh aduser@addomain.com@client.idm.example.com
  2. Verify the group membership of the AD user:

    $ id aduser@addomain.com
    uid=702801456(aduser@addomain.com) gid=63(audio) groups=63(audio)

Additional resources

37.12. Using Ansible to ensure an IdM user is present in an ID view with a specific UID

If you are working in a lab where you have our 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.

If you need to have full access to your files whether you are logged in as an IdM user or as a local user, you can do so by giving both users the same UID.

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 UID of 20001.

Prerequisites

  • You have configured your Ansible control node to meet the following requirements:

    • You are using Ansible version 2.14 or later.
    • You have installed the ansible-freeipa package on the Ansible controller.
    • You are using RHEL 9.4 or later.
    • 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_password.
  • The idview_for_host1 ID view exists.

Procedure

  1. On your Ansible control node, create an ensure-idmuser-and-local-user-have-access-to-same-files.yml playbook with 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
  2. Save the file.
  3. 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

Additional resources

37.13. Using Ansible to ensure an IdM user can log in to an IdM client with two certificates

If you want an Identity Management (IdM) user that normally logs in to IdM with a password to authenticate to a specific IdM client by using a smart card only, you can create an ID view that requires certification for the user on that 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.14 or later.
    • You have installed the ansible-freeipa package on the Ansible controller.
    • You are using RHEL 9.4 or later.
    • 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_password.
    • The example assumes that cert1.b64 and cert2.b64 certificates are located in the same directory in which you are executing the playbook.
  • The idview_for_host01 ID view exists.

Procedure

  1. On your Ansible control node, create an ensure-idmuser-present-in-idview-with-certificates.yml playbook with 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=False directive causes the white space not to be removed from the end of the looked-up file.

  2. Save the file.
  3. 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

Additional resources

37.14. Using Ansible to give an IdM group access to the sound card on an IdM client

You can use the ansible-freeipa idview and idoverridegroup modules to make Identity Management (IdM) or Active Directory (AD) users members of the local audio group on an IdM client. This grants the IdM or AD users privileged access to the sound card on the host.

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.14 or later.
    • You have installed the ansible-freeipa package on the Ansible controller.
    • You are using RHEL 9.4 or later.
    • 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_password.

Procedure

  1. [Optional] Identify the GID of the local audio group on a RHEL host:

    $ getent group audio
    ---------------------
    audio:x:63
  2. On 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
  3. Save the file.
  4. 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

  1. On an IdM client, obtain IdM administrator’s credentials:

    $ kinit admin
    Password:
  2. 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"
    ------------------
  3. Add the user to the IdM audio group:

    $ ipa group-add-member --tuser audio
  4. Log in to host01.idm.example.com as tuser:

    $ ssh tuser@host01.idm.example.com
  5. Verify the group membership of the user:

    $ id tuser
    uid=702801456(tuser) gid=63(audio) groups=63(audio)

Additional resources

37.15. Migrating NIS domains to Identity Management

You can use ID views to set host specific UIDs and GIDs for existing hosts to prevent changing permissions for files and directories when migrating NIS domains into IdM.

Prerequisites

  • You authenticated yourself as an admin using the kinit admin command.

Procedure

  1. Add users and groups in the IdM domain.

    1. Create users using the ipa user-add command. For more information see: Adding users to IdM.
    2. Create groups using the ipa group-add command. For more information see: Adding groups to IdM.
  2. Override IDs IdM generated during the user creation:

    1. Create a new ID view using ipa idview-add command. For more information see: Getting help for ID view commands.
    2. Add ID overrides for the users and groups to the ID view using ipa idoverrideuser-add and idoverridegroup-add respectively.
  3. Assign the ID view to the specific hosts using ipa idview-apply command.
  4. Decommission the NIS domains.

Verification

  1. To check if all users and groups were added to the ID view correctly, use the ipa idview-show command.

    $ ipa idview-show example-view
      ID View Name: example-view
      User object overrides: example-user1
      Group object overrides: example-group
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.