Goal	Configure users for authorized access to services and resources.
Objectives	Manage user, group and host accounts, and implement user life cycles by staging, activating, and preserving user accounts. Grant and restrict IdM user access by implementing role-based, host-based, and Sudo access control rules. Manage Kerberos principal keytab files, implement Kerberos ticket policies to set restrictions on ticket access, duration, and renewal, and configure external systems to enable IdM user access using Kerberos credentials. Configure NFS shares, including home directories, to mount automatically for IdM users logged in to IdM clients.
Sections	Managing IdM Users and Hosts (and Guided Exercise) Implementing IdM User Access Control (and Guided Exercise) Managing Kerberos Principals, Policies, and External Authentication (and Guided Exercise) Configuring Network-shared Home Directories (and Guided Exercise)
Lab	Managing Users and Configuring User Access

Managing IdM Users and Hosts

Objectives

Manage user, group, and host accounts, and implement user lifecycles by staging, activating, and preserving user accounts.

Managing User Accounts

User lifecycle management tasks, such as creating users and groups, are typically performed by system administrators. However, these tasks can be delegated to nonadministrative users by defining access controls.

Access controls define who can access certain resources, such as machines or services, and what kinds of operations users are allowed to perform. Identity Management provides several access control areas to define the type of access granted and to whom it is granted. Additionally, IdM draws a distinction between access controls to resources within the domain and access control to the IdM configuration itself.

To delegate specific administrative tasks to a nonadministrative user, a Role-based access control (RBAC) can be defined and assigned to a special access control group that is granted edit, add, and delete rights for user and group attributes.

Creating a Role Using the Command Line

To create a role for allowing basic administrative tasks to modify user account attributes, authenticate as the admin user.

Add a new role using the ipa role-add command. Provide both a description and name for the new role. Use the ipa role-add-privilege command to add the User Administrators privilege for the new role. Use the ipa role-add-member command to add groups of users to the role.

You can view the full list of privileges by using the ipa privilege-find command.

[user@host ~]$ ipa privilege-find
...output omitted...
  Privilege name: ADTrust Agents
  Description: System accounts able to access trust information

  Privilege name: Automember Readers
  Description: Read Automember definitions
...output omitted...

Configuring Automatic Group Membership

You can assign users and hosts to groups automatically, based on their attributes, by using automatic group membership.

Define automember rules to configure automatic group membership. An automember rule applies to a specific user or host group and includes conditions that the user or host must meet to be included or excluded from the group.

Use the ipa automember-add command to add an automember rule, and then define one or more inclusive or exclusive conditions.

Managing User SSH Public Keys

Identity Management allows you to add an SSH public key to a user object by uploading it. The user who has access to the corresponding SSH private key can use the ssh command to log in to a member of the IdM domain without using Kerberos credentials. If the pam_krb5 module is configured correctly, or if SSSD is used as the member server's identity provider, then the user also receives a Kerberos ticket-granting ticket (TGT) after successfully logging in.

Caching and Retrieving SSH Keys Automatically

During an IdM server or client installation, SSSD is automatically configured on the machine to cache and retrieve user and host SSH keys. This allows IdM to serve as a universal and centralized repository of SSH keys.

Generating an SSH Key

The following example generates an SSH key using the OpenSSH ssh-keygen utility:

[idmuser@host ~]$ ssh-keygen -t rsa \
  -C idmuser@lab.example.com
Generating public/private rsa key pair.
Enter file in which to save the key (/home/idmuser/.ssh/id_rsa):
Created directory '/home/idmuser/.ssh'.
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/idmuser/.ssh/id_rsa.
Your public key has been saved in /home/idmuser/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c idmuser@host.lab.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|     + .         |
|    + =   .      |
|     =   +       |
|    . E S..      |
|   .    . .o     |
|    . .  . oo.   |
|   . o .  +.+o   |
|    o  .o..o+o   |
+-----------------+

Uploading User SSH Keys

In the following example, the idmuser adds an SSH key to their IdM account:

[idmuser@host ~]$ ipa user-mod idmuser \
  --sshpubkey="$(cat ~/.ssh/id_rsa.pub)"
-----------------------
Modified user "idmuser"
-----------------------
  User login: idmuser
...output omitted...
  SSH public key fingerprint: SHA256:qlpIHXlyQ2EznBQgCMENsvHF80if/XHLdu7RNoNcrOI
                              idmuser@host.lab.example.com (ssh-rsa)
...output omitted...

Caching and Retrieving SSH Keys Automatically

The System Security Services Daemon (SSSD) can serve as a credentials cache for SSH public keys for servers and users. Only Linux machines in the IdM domain can use SSSD as a key cache for OpenSSH. Other machines such as Windows servers, cannot.

OpenSSH must be configured to use SSSD to fetch cached keys. SSSD must use an IdM domain, and IdM must store public keys and host information.

How SSSD Manages User Keys

SSSD retrieves the user's public key from the user object in the IdM domain, and then stores the key in the ~/.ssh/sss_authorized_keys file in the standard authorized keys format.

Changing and Resetting Passwords

Regular users without permission to change other users' passwords can change only their own password and must adhere to IdM password policies. Administrators and users with password change rights can set initial passwords for new users and reset passwords for existing users, and are not restricted by IdM password policies.

Changing Your Own Password

To change your own password, log in to the IdM web UI. In the upper right corner, choose User name → Change password. In the Reset Password dialog, enter your password information, and then click Reset Password.

Changing Another User's Password

To change another user's password, log in to the IdM web UI as the admin user or an account that has password change rights. Navigate to the Identity → Users → Active users, then click the name of the user that you want to edit. Navigate to Actions → Reset Password, in the Reset Password form, enter the password information, and then click Reset Password.

References

Further information is available in the Managing IdM Users, Groups, Hosts, and Access Control Rules guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_idm_users_groups_hosts_and_access_control_rules/index

Discuss Red Hat Security: Identity Management and Authentication

Go to community

Welcome to the Red Hat Security: Identity Management and Active Directory Integration group!

Syed

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Security: Identity Management and Active Directory Integration! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH362.Read more about Red Hat Security: Identity Management and Active Directory Integration here.

215

Revision: rh362-9.1-4c6fdb8