4.6. Applying Group Policy Object access control in RHEL
A Group Policy Object (GPO) is a collection of access control settings stored in Microsoft Active Directory (AD) that can apply to computers and users in an AD environment. By specifying GPOs in AD, administrators can define login policies honored by both Windows clients and Red Hat Enterprise Linux (RHEL) hosts joined to AD.
4.6.1. How SSSD interprets GPO access control rules 复制链接链接已复制到粘贴板!
By default, SSSD retrieves Group Policy Objects (GPOs) from Active Directory (AD) domain controllers and evaluates them to determine if a user is allowed to log in to a particular RHEL host joined to AD.
SSSD maps AD Windows Logon Rights to Pluggable Authentication Module (PAM) service names to enforce those permissions in a GNU/Linux environment.
As an AD Administrator, you can limit the scope of GPO rules to specific users, groups, or hosts by listing them in a security filter.
- Limitations on filtering by groups
-
SSSD currently does not support Active Directory’s built-in groups, such as
Administratorswith Security Identifier (SID)S-1-5-32-544. Red Hat recommends against using AD built-in groups in AD GPOs targeting RHEL hosts.
4.6.2. List of GPO settings that SSSD supports 复制链接链接已复制到粘贴板!
The following table shows the SSSD options that correspond to Active Directory GPO options as specified in the Group Policy Management Editor on Windows.
| GPO option | Corresponding sssd.conf option |
|---|---|
| Allow log on locally Deny log on locally |
|
| Allow log on through Remote Desktop Services Deny log on through Remote Desktop Services |
|
| Access this computer from the network Deny access to this computer from the network |
|
| Allow log on as a batch job Deny log on as a batch job |
|
| Allow log on as a service Deny log on as a service |
|
4.6.3. List of SSSD options to control GPO enforcement 复制链接链接已复制到粘贴板!
You can set the following SSSD options to limit the scope of GPO rules.
- The
ad_gpo_access_controloption -
You can set the
ad_gpo_access_controloption in the/etc/sssd/sssd.conffile to choose between three different modes in which GPO-based access control operates.
| Value of ad_gpo_access_control | Behavior |
|---|---|
|
| GPO-based access control rules are evaluated and enforced. This is the default setting in RHEL 8. |
|
|
GPO-based access control rules are evaluated but not enforced; a |
|
| GPO-based access control rules are neither evaluated nor enforced. |
- The
ad_gpo_implicit_denyoption -
The
ad_gpo_implicit_denyoption is set toFalseby default. In this default state, users are allowed access if applicable GPOs are not found. If you set this option toTrue, you must explicitly allow users access with a GPO rule.
You can use this feature to harden security, but be careful not to deny access unintentionally. Red Hat recommends testing this feature while ad_gpo_access_control is set to permissive.
The following two tables illustrate when a user is allowed or rejected access based on the allow and deny login rights defined on the AD server-side and the value of ad_gpo_implicit_deny.
| allow-rules | deny-rules | result |
|---|---|---|
| missing | missing | all users are allowed |
| missing | present | only users not in deny-rules are allowed |
| present | missing | only users in allow-rules are allowed |
| present | present | only users in allow-rules and not in deny-rules are allowed |
| allow-rules | deny-rules | result |
|---|---|---|
| missing | missing | no users are allowed |
| missing | present | no users are allowed |
| present | missing | only users in allow-rules are allowed |
| present | present | only users in allow-rules and not in deny-rules are allowed |
4.6.4. Changing the GPO access control mode 复制链接链接已复制到粘贴板!
This procedure changes how GPO-based access control rules are evaluated and enforced on a RHEL host joined to an Active Directory (AD) environment.
In this example, you will change the GPO operation mode from enforcing (the default) to permissive for testing purposes.
If you see the following errors, Active Directory users are unable to log in due to GPO-based access controls:
In
/var/log/secure:Oct 31 03:00:13 client1 sshd[124914]: pam_sss(sshd:account): Access denied for user aduser1: 6 (Permission denied) Oct 31 03:00:13 client1 sshd[124914]: Failed password for aduser1 from 127.0.0.1 port 60509 ssh2 Oct 31 03:00:13 client1 sshd[124914]: fatal: Access denied for user aduser1 by PAM account configuration [preauth]In
/var/log/sssd/sssd__example.com_.log:(Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158236](Host Access Denied) (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158236](Host Access Denied} (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
If this is undesired behavior, you can temporarily set ad_gpo_access_control to permissive as described in this procedure while you troubleshoot proper GPO settings in AD.
Prerequisites
- You have joined a RHEL host to an AD environment using SSSD.
-
Editing the
/etc/sssd/sssd.confconfiguration file requiresrootpermissions.
Procedure
Stop the SSSD service.
[root@server ~]# systemctl stop sssd-
Open the
/etc/sssd/sssd.conffile in a text editor. Set
ad_gpo_access_controltopermissivein thedomainsection for the AD domain.[domain/example.com] ad_gpo_access_control=permissive ...-
Save the
/etc/sssd/sssd.conffile. Restart the SSSD service to load configuration changes.
[root@server ~]# systemctl restart sssd
A Group Policy Object (GPO) is a collection of access control settings stored in Microsoft Active Directory (AD) that can apply to computers and users in an AD environment. The following procedure creates a GPO in the AD graphical user interface (GUI) to control logon access to a RHEL host that is integrated directly to the AD domain.
Prerequisites
- You have joined a RHEL host to an AD environment using SSSD.
- You have AD Administrator privileges to make changes in AD using the GUI.
Procedure
Within Active Directory Users and Computers, create an Organizational Unit (OU) to associate with the new GPO:
- Right-click the domain.
- Choose New.
- Choose Organizational Unit.
- Click the name of the Computer Object that represents the RHEL host (created when it joined Active Directory) and drag it into the new OU. By having the RHEL host in its own OU, the GPO targets this host.
Within the Group Policy Management Editor, create a new GPO for the OU you created:
- Expand Forest.
- Expand Domains.
- Expand your domain.
- Right-click the new OU.
- Choose Create a GPO in this domain.
- Specify a name for the new GPO, such as Allow SSH access or Allow Console/GUI access and click OK.
Edit the new GPO:
- Select the OU within the Group Policy Management Editor.
- Right-click and choose Edit.
- Select User Rights Assignment.
- Select Computer Configuration.
- Select Policies.
- Select Windows Settings.
- Select Security Settings.
- Select Local Policies.
- Select User Rights Assignment.
Assign login permissions:
- Double-Click Allow log on locally to grant local console/GUI access.
- Double-click Allow log on through Remote Desktop Services to grant SSH access.
Add the user(s) you want to access either of these policies to the policies themselves:
- Click Add User or Group.
- Enter the username within the blank field.
- Click OK.