Red Hat Security: Identity Management and Authentication
Grant and restrict IdM user access by implementing role-based, host-based, and Sudo access control rules.
Host-based access control (HBAC) rules define which users or user groups can access specified hosts or host groups by using specified services or services in a service group. HBAC rules provide the following features:
They can limit access to a specified system in your domain to members of a specific user group.
They can allow only a specific service to be used to access systems in your domain.
Administrators configure host-based access control by using a set of rules, called HBAC rules, to allow a specific level of access.
By default, IdM is configured with the allow_all rule, which allows universal access to the IdM domain.
For centralized and simplified access control management, you can apply HBAC rules to users, hosts, or service groups instead of individual users, hosts, or services.
You might want to add or remove rules to match your organization processes or rules.
Make sure you update the rules in the correct order because some actions, such as the removal of the allow_all rule, can lead to undesired conditions.
Important
Do not disable the allow_all rule before creating your custom HBAC rules, or users will not be able to access any hosts.
Review the new set of rules and test them to make sure that the IdM domain has the desired configuration.
Log in to the IdM web UI using the admin user account, and navigate to → → .
Click , enter a name for the rule, and then click to go to the HBAC rule configuration page.
In the area, specify the target users. To apply the HBAC rule to specific users or groups, select and then click to add the users or groups. To apply the HBAC rule to all users, select .
In the area, specify the target hosts. To apply the HBAC rule to specific hosts or groups, select and then click to add the hosts or groups. To apply the HBAC rule to all hosts, select .
In the area, specify the target HBAC services. To apply the HBAC rule to specific services or groups, select and then click to add the services or groups. To apply the HBAC rule to all services, select .
Changing certain settings on the HBAC rule configuration page highlights the button at the top of the page. If this happens, then click the button to confirm the changes.
You can test your HBAC configuration in various situations using simulated scenarios. By performing these simulated runs, you can discover configuration problems or security risks before deploying HBAC rules in production.
Important
IdM does not test the effect of HBAC rules on trusted Active Directory users. Because Active Directory data is not stored in the IdM LDAP directory, IdM cannot resolve group membership of Active Directory users when simulating HBAC scenarios.
Use the following procedure to test your HBAC rules:
Log in to the IdM web UI as the administrative user, and navigate to → → .
On the page, specify the user under whose identity you want to perform the test, and click .
On the page, specify the host that the user should try to access, and click .
On the page, specify the service that the user should try to use, and click .
On the page, select the HBAC rules that you want to test, and click .
If you do not select any rules, all rules are tested. On the page, click .
If you see ACCESS DENIED, then the user is not granted access in the test.
If you see ACCESS GRANTED, then the user can access the host successfully.
Identity Management provides a mechanism for predictably and consistently applying Sudo policies across the IdM domain. Every system in the IdM domain can be configured as a Sudo client.
The Sudo utility gives users permission to run specified commands as the root user.
When users precede a command with sudo, they are prompted for their own password.
After authenticating, the command is executed as the root user if permitted.
IdM has a specialized LDAP schema for Sudo entries. Although the LDAP schema supports both host groups and netgroups, Sudo only supports netgroups. However, Sudo does support command groups, which contain multiple commands.
IdM translates the IdM Sudo configuration into the native Sudo configuration when Sudo rules are created.
For example, IdM creates a corresponding shadow netgroup for every host group.
This allows IdM administrators to create Sudo rules that reference host groups, but the local sudo command uses the corresponding netgroup.
By default, Sudo information is not available anonymously over LDAP.
Therefore, IdM defines a default sudo user as uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX.
You can change this user in the LDAP Sudo /etc/sudo-ldap.conf configuration file.
Network information service (NIS) is a way to centrally manage identities and authentication information, such as users, passwords, hostnames, IP addresses, and POSIX groups.
Although NIS is considered insecure, it can be integrated with other protocols to enhance security. IdM provides a server plug-in to connect clients that cannot be fully migrated to IdM, and integrates netgroups and other NIS data into the IdM domain.
The NIS domain name must be set for netgroups and Sudo to work properly. The Sudo configuration requires NIS-formatted netgroups and a NIS domain name for netgroups. However, IdM does not require that the NIS domain exist; nor is it required to have an NIS server installed.
The ipa-client-install utility sets a NIS domain name automatically to the IdM domain name by default.
By using Sudo rules, you can define who can do what, where, and as whom.
Which users can use Sudo?
Which commands can be used with Sudo?
Which target hosts can Sudo be used with?
Which user accounts can users assume when they use Sudo?
IdM accepts external entities in Sudo rules. External entities are entities that are stored outside the IdM domain, such as users or hosts, that are not part of the IdM domain.
For example, you can use Sudo rules to grant root access to a member of the IT group in IdM, where the root user is not a user defined in the IdM domain.
Alternately, administrators can block access to certain hosts on a network, but that are not part of the IdM domain.
You can use Sudo to give access to user groups in IdM. IdM supports both UNIX and non-POSIX groups. Note that creating non-POSIX groups can cause access problems because any users in a non-POSIX group inherit non-POSIX permissions from the group.
In IdM, a Sudo command is the definition of a command to be run as a privileged user. The command definition can include options and arguments so you can have more control of the privilege granted.
For example, you might want to assign a user the ability to start the SSSD service.
You cannot define the command as /bin/systemctl because this definition grants the user the ability to start, stop, mask any service, and even restart the machine.
You can define the command as /bin/systemctl start sssd.service to limit the privilege correctly.
To create a Sudo command in the IdM web UI, navigate to → → , and then click .
In the dialog box, enter the absolute path to the command, and then click .
You can also use the ipa sudocmd-add command.
You can group Sudo commands into Sudo command groups.
In the same example, you notice that the assigned user sometimes also needs to restart the SSSD service.
In this case, you can create the sssd_service_mgmt Sudo command group and add the start and restart commands to this group.
To create a Sudo command group, navigate to → → and click . Enter the name and the description and click . On the tab, click to add a Sudo command to the group. Select the required commands in the column and move them to the column by using the button. Click when finished.
You can also use the ipa sudocmdgroup-add command to create Sudo command groups and the ipa sudocmdgroup-add-member command to add commands to the group.
You can use Sudo rules to enable an IdM user to run a Sudo command as a privileged user. You can define which users can run which commands in which hosts.
In the same example, you have defined privileges for the SSSD service, but the user might not only need to interact with the service, but also modify configuration files.
In this scenario, you can create the appropriate Sudo commands to edit those files in the sssd_file_mgmt group.
You can then create the manage_sssd rule to define which users can use the commands defined in the sssd_file_mgmt and sssd_service_mgmt groups.
You can also define in which hosts or host groups the user can use the commands.
To create a Sudo rule on the IdM web UI, navigate to → → . Click , enter a name for the rule and then click . And configure the rule with the required users, hosts, and commands.
You can also use the ipa sudorule-add command to create a rule.
Note
The Sudo rules might take some time to propagate to the assigned hosts.
To solve this issue, you can clear the SSSD cache by using the sss_cache -E command.
Different mechanisms for Kerberos authentication in IdM have different strengths. Services that have security-sensitive content can be required to use stronger authentication methods than less critical services.
Authentication using a one-time password (OTP) in combination with a standard password is considered stronger and therefore safer than authentication using only a standard password. This section shows how to limit access to services and hosts based on how the user authenticates.
Examples of controlling user authentication include:
Configure administrative user logins to require a strong authentication method.
Configure regular user logins to allow authentication using a weaker, but more convenient authentication method.
The key distribution center (KDC) can attach additional information to a ticket based on how a principal authenticated, or by an administrator configuring the require_auth attribute on a service principal.
These pieces of additional information are known as authentication indicators.
Indicators included in a service or host entry define what authentication methods the user can use to access that service or host.
Indicators included in the user's ticket-granting ticket (TGT) show what authentication method was used to obtain the ticket.
If the indicator in the principal does not match the indicator in the TGT, the user is denied access.
Access control defines the rights or permissions users have been granted to perform operations on other users or objects.
The IdM access control structure is based on standard LDAP access controls. Access in IdM is based on IdM users stored in the back-end Directory Server instance. The instance is allowed to access other IdM entities, which are also stored as LDAP entries in the Directory Server instance.
An access control instruction (ACI) has three parts:
- Actor
The actor is the entity being granted permission to perform an action. In LDAP access control models, this is called the bind rule, because it defines who the user is. It can optionally require other limits on the bind attempt, such as restricting attempts to a certain time of day or a certain machine.
- Target
The target defines the entry for which the user can perform operations.
- Operation type
The operation type determines the actions that the user is allowed to perform. The most common operations are add, delete, write, read, and search. In Identity Management, all users are implicitly granted read and search rights to all entries in the IdM domain, with restrictions only for sensitive attributes such as passwords and Kerberos keys. Anonymous users cannot view security-related configuration, which includes Sudo rules and host-based access control.
When any operation is attempted, the IdM client first sends user credentials as part of the bind operation. Directory Server tests the user credentials and then verifies the user account to determine whether the user has permission to perform the requested operation.
To make access control rules simple and clear to implement, IdM divides access control definitions into three categories:
- Self-service rules
Self-service rules define what operations a user can perform on their own personal entry. The access control type only allows
writepermissions to attributes within the entry. It does not allowaddordeleteoperations for the entry itself.- Delegation rules
Delegation rules allow a specific user group to perform
write(edit) operations on specific attributes for users in another user group. Like self-service rules, this form of access control rule is limited to editing the values of specific attributes. It does not grant the ability to add or remove whole entries or provide control over unspecified attributes.- Role-based access control
Role-based access control creates special access control groups, which are then granted much broader authority over all types of entities in the IdM domain. Roles can be granted edit, add, and delete rights, meaning they can be granted complete control over entire entries, not just selected attributes.
Some roles are already created and available within IdM. Special roles can be created to manage any type of entry in specific ways, such as hosts, automount configuration, netgroups, DNS settings, and IdM configuration.
Self-service access control rules define the operations that an entity can perform on itself. These rules define only what attributes a user (or other IdM entity) can edit on their own object.
To create self-service rules, log in to the IdM web UI as an administrative user, navigate to → → , and then click .
Enter the name of the rule in the field, select the checkboxes next to the attributes that the access control instruction (ACI) permits users to edit, and then click .
You can use the ipa selfservice-add command to add a new self-service rule.
The following two options are required:
-
--permissions Sets the permissions, such as
write,add, ordelete, for the ACI grants.-
--attrs Specifies the list of attributes that the ACI grants permission to.
[user@host ~]$ipa selfservice-add \"Users can manage their own name details" \--permissions=write --attrs=givenname \--attrs=displayname --attrs=title --attrs=initials----------------------------------------------------------- Added selfservice "Users can manage their own name details" ----------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
Delegation is similar to roles; one group of users is assigned permission to manage the attributes of another group of users. However, the delegated authority is much more similar to self-service rules, because access is granted to specific user attributes rather than to the entire object. Moreover, the groups in the delegated authority are existing IdM user groups instead of roles specifically created for access controls.
To delegate user management, log in to the IdM web UI using an administrative account, navigate to → → , and then click .
In the dialog box, enter a descriptive name for the new access control instruction, and then select the appropriate checkboxes to determine whether users have read, write, or both permissions for the given attributes.
In the list, select the group that you want to grant permissions to. In the list, select the group whose entries you want to be edited by members of the delegation group. In the section, select the checkboxes for the attributes that the delegation group members can edit. Click to save the new delegation ACI.
Use the ipa delegation-add command to create delegation access control rules.
The following three options are required:
-
--group Defines the group being granted permission to the entries in the user group.
-
--membergroup Defines the group whose entries can be edited by members of the delegation group.
-
--attrs Defines the attributes that users in the delegation group can view or edit.
[user@host ~]$ipa delegation-add "basic manager attrs" \--attrs=manager --attrs=title --attrs=employeetype \--attrs=employeenumber --group=engineering_managers \--membergroup=engineering-------------------------------------- Added delegation "basic manager attrs" -------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber Member user group: engineering User group: engineering_managers
Use the ipa delegation-mod command to modify delegation rules.
The --attrs option overwrites any existing supported attributes, so always include the complete list of attributes along with any new attributes.
Role-based access controls consist of three parts: permissions, privileges, and roles. Privileges consists of one or more permissions, and roles consist of one or more privileges.
- permissions
Permissions define a specific operation or set of operations (such as read, write, add, or delete) and the target entries in the IdM LDAP directory to which those operations apply. Permissions are building blocks; they can be assigned to multiple privileges as needed.
You can use IdM permissions to control which users have access to which objects, and even which attributes of such objects. You can allow or deny individual attributes or change the entire visibility of a specific IdM function, such as users, groups, or Sudo, to all anonymous users, all authenticated users, or just a group of privileged users. This flexible approach to permissions is useful in scenarios when, for example, administrators need to limit the access of users or groups to only specific sections, and to completely hide other sections.
- privileges
A privilege is a group of permissions that can be applied to a role. For example, create a permission to add, edit, and delete automount locations. Combine the new permission with another permission relating to managing FTP services, to create a single privilege that relates to managing file systems.
- roles
A role is a set of privileges. You can assign a role to a user to grant the set of privileges defined in the role.
You can create more permissions, and also create more privileges based on new or existing permissions.
To create a role in the web UI, log in as an administrative user, navigate to → → , and then click .
In the dialog box, enter a role name and a description in the appropriate fields. Click or to save the new role.
At the top of the page, on the tab, or on the tab when adding groups, click . Select the users on the left and use the button to move them to the column, then click when finished.
On the tab, click . Select the privileges on the left, use the button to move them to the column, and then click .
You can add a role by using the ipa role-add command:
[user@host ~]$ipa role-add \--desc="------------------------ Added role "role_name" ------------------------ Role name: role_name Description: role_descriptionrole_description"role_name
Add the required privileges to the role:
[user@host ~]$ipa role-privilege \--privileges="Role name: role_name Description: role_description Privileges: privileges ---------------------------- Number of privileges added 1 ----------------------------privilege"role_name
Add the required groups to the role:
[user@host ~]$ipa role-add-member \--groups="Role name: role_name Description: role_description Member groups: group_name Privileges: privileges ------------------------- Number of members added 1 -------------------------group_name"role_name
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
