Chapter 4. Managing direct connections to AD
You can use the System Security Services Daemon (SSSD) or Samba Winbind to connect your Red Hat Enterprise Linux (RHEL) system to Active Directory (AD). This section describes how to modify and manage your connection to AD when your RHEL system is already configured as an AD client.
Prerequisites
- You have connected your RHEL system to the Active Directory domain, either with SSSD or Samba Winbind.
4.1. Modifying the default Kerberos host keytab renewal interval
SSSD automatically renews the Kerberos host keytab file in an AD environment if the adcli
package is installed. The daemon checks daily if the machine account password is older than the configured value and renews it if necessary.
The default renewal interval is 30 days. To change the default, follow the steps in this procedure.
Procedure
Add the following parameter to the AD provider in your
/etc/sssd/sssd.conf
file:ad_maximum_machine_account_password_age = value_in_days
Restart SSSD:
# systemctl restart sssd
-
To disable the automatic Kerberos host keytab renewal, set
ad_maximum_machine_account_password_age = 0
.
Additional resources
4.2. Removing a RHEL system from an AD domain
Follow this procedure to remove a Red Hat Enterprise Linux (RHEL) system that is integrated into Active Directory (AD) directly from the AD domain.
Prerequisites
- You have used the System Security Services Daemon (SSSD) or Samba Winbind to connect your RHEL system to AD.
Procedure
Remove a system from an identity domain using the
realm leave
command. The command removes the domain configuration from SSSD and the local system.# realm leave ad.example.com
NoteWhen a client leaves a domain, AD does not delete the account and only removes the local client configuration. To delete the AD account, run the command with the
--remove
option. Initially, an attempt is made to connect without credentials, but you are prompted for your user password if you do not have a valid Kerberos ticket. You must have rights to remove an account from Active Directory.Use the
-U
option with therealm leave
command to specify a different user to remove a system from an identity domain.By default, the
realm leave
command is executed as the default administrator. For AD, the administrator account is calledAdministrator
. If a different user was used to join to the domain, it might be required to perform the removal as that user.# realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'
The command first attempts to connect without credentials, but it prompts for a password if required.
Verification
Verify the domain is no longer configured:
# realm discover [ad.example.com] ad.example.com type: kerberos realm-name: EXAMPLE.COM domain-name: example.com configured: no server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools
Additional resources
-
See the
realm(8)
man page.
4.3. Setting the domain resolution order in SSSD to resolve short AD user names
By default, you must specify fully qualified usernames, like ad_username@ad.example.com
and group@ad.example.com
, to resolve Active Directory (AD) users and groups on a RHEL host connected to AD with the SSSD service.
This procedure sets the domain resolution order in the SSSD configuration so you can resolve AD users and groups using short names, like ad_username
. This example configuration searches for users and groups in the following order:
-
Active Directory (AD) child domain
subdomain2.ad.example.com
-
AD child domain
subdomain1.ad.example.com
-
AD root domain
ad.example.com
Prerequisites
- You have used the SSSD service to connect the RHEL host directly to AD.
Procedure
-
Open the
/etc/sssd/sssd.conf
file in a text editor. Set the
domain_resolution_order
option in the[sssd]
section of the file.domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com
- Save and close the file.
Restart the SSSD service to load the new configuration settings.
[root@ad-client ~]# systemctl restart sssd
Verification
Verify you can retrieve user information for a user from the first domain using only a short name.
[root@ad-client ~]# id <user_from_subdomain2> uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)
4.4. Managing login permissions for domain users
By default, domain-side access control is applied, which means that login policies for Active Directory (AD) users are defined in the AD domain itself. This default behavior can be overridden so that client-side access control is used. With client-side access control, login permission is defined by local policies only.
If a domain applies client-side access control, you can use the realmd
to configure basic allow or deny access rules for users from that domain.
Access rules either allow or deny access to all services on the system. More specific access rules must be set on a specific system resource or in the domain.
4.4.1. Enabling access to users within a domain
By default, login policies for Active Directory (AD) users are defined in the AD domain itself. Follow this procedure to override this default behavior and configure a RHEL host to enable access for users within an AD domain.
It is not recommended to allow access to all by default while only denying it to specific users with realm permit -x
. Instead, Red Hat recommends maintaining a default no access policy for all users and only grant access to selected users using realm permit.
Prerequisites
- Your RHEL system is a member of the Active Directory domain.
Procedure
Grant access to all users:
# realm permit --all
Grant access to specific users:
$ realm permit aduser01@example.com $ realm permit 'AD.EXAMPLE.COM\aduser01'
Currently, you can only allow access to users in primary domains and not to users in trusted domains. This is due to the fact that user login must contain the domain name and SSSD cannot currently provide realmd
with information about available child domains.
Verification
Use SSH to log in to the server as the
aduser01@example.com
user:$ ssh aduser01@example.com@server_name [aduser01@example.com@server_name ~]$
Use the ssh command a second time to access the same server, this time as the
aduser02@example.com
user:$ ssh aduser02@example.com@server_name Authentication failed.
Notice how the aduser02@example.com
user is denied access to the system. You have granted the permission to log in to the system to the aduser01@example.com
user only. All other users from that Active Directory domain are rejected because of the specified login policy.
If you set use_fully_qualified_names
to true in the sssd.conf
file, all requests must use the fully qualified domain name. However, if you set use_fully_qualified_names
to false, it is possible to use the fully-qualified name in the requests, but only the simplified version is displayed in the output.
Additional resources
-
See the
realm(8)
man page.
4.4.2. Denying access to users within a domain
By default, login policies for Active Directory (AD) users are defined in the AD domain itself. Follow this procedure to override this default behavior and configure a RHEL host to deny access to users within an AD domain.
It is safer to only allow access to specific users or groups than to deny access to some, while enabling it to everyone else. Therefore, it is not recommended to allow access to all by default while only denying it to specific users with realm permit -x
. Instead, Red Hat recommends maintaining a default no access policy for all users and only grant access to selected users using realm permit.
Prerequisites
- Your RHEL system is a member of the Active Directory domain.
Procedure
Deny access to all users within the domain:
# realm deny --all
This command prevents
realm
accounts from logging into the local machine. Userealm permit
to restrict login to specific accounts.Verify that the domain user’s
login-policy
is set todeny-any-login
:[root@replica1 ~]# realm list example.net type: kerberos realm-name: EXAMPLE.NET domain-name: example.net configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools login-formats: %U@example.net login-policy: deny-any-login
Deny access to specific users by using the
-x
option:$ realm permit -x 'AD.EXAMPLE.COM\aduser02'
Verification
Use SSH to log in to the server as the
aduser01@example.net
user.$ ssh aduser01@example.net@server_name Authentication failed.
If you set use_fully_qualified_names
to true in the sssd.conf
file, all requests must use the fully qualified domain name. However, if you set use_fully_qualified_names
to false, it is possible to use the fully-qualified name in the requests, but only the simplified version is displayed in the output.
Additional resources
-
See the
realm(8)
man page.
4.5. 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.
The following sections describe how you can manage GPOs in your environment:
4.5.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 hosts
Older versions of SSSD do not evaluate hosts in AD GPO security filters.
- RHEL 8.3.0 and newer: SSSD supports users, groups, and hosts in security filters.
-
RHEL versions older than 8.3.0: SSSD ignores host entries and only supports users and groups in security filters.
To ensure that SSSD applies GPO-based access control to a specific host, create a new Organizational Unit (OU) in the AD domain, move the system to the new OU, and then link the GPO to this OU.
Limitations on filtering by groups
SSSD currently does not support Active Directory’s built-in groups, such as Administrators
with Security Identifier (SID) S-1-5-32-544
. Red Hat recommends against using AD built-in groups in AD GPOs targeting RHEL hosts.
Additional resources
- For a list of Windows GPO options and their corresponding SSSD options, see List of GPO settings that SSSD supports.
4.5.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 |
|
Allow log on through Remote Desktop Services |
|
Access this computer from the network |
|
Allow log on as a batch job |
|
Allow log on as a service |
|
Additional resources
-
For more information about these
sssd.conf
settings, such as the Pluggable Authentication Module (PAM) services that map to GPO options, see thesssd-ad(5)
Manual page entry.
4.5.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_control
option
You can set the ad_gpo_access_control
option in the /etc/sssd/sssd.conf
file 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. |
|
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_deny
option
The ad_gpo_implicit_deny
option is set to False
by default. In this default state, users are allowed access if applicable GPOs are not found. If you set this option to True
, 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 |
Additional resources
- For the procedure to change the GPO enforcement mode in SSSD, see Changing the GPO access control mode.
-
For more details on each of the different GPO modes of operation, see the
ad_gpo_access_control
entry in thesssd-ad(5)
Manual page.
4.5.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.conf
configuration file requiresroot
permissions.
Procedure
Stop the SSSD service.
[root@server ~]# systemctl stop sssd
-
Open the
/etc/sssd/sssd.conf
file in a text editor. Set
ad_gpo_access_control
topermissive
in thedomain
section for the AD domain.[domain/example.com] ad_gpo_access_control=permissive ...
-
Save the
/etc/sssd/sssd.conf
file. Restart the SSSD service to load configuration changes.
[root@server ~]# systemctl restart sssd
Additional resources
- For the list of different GPO access control modes, see List of SSSD options to control GPO enforcement.
4.5.5. Creating and configuring a GPO for a RHEL host in the AD GUI
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 on the domain.
-
Choose
New
. -
Choose
Organizational Unit
.
- Click on 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 on the new OU.
-
Choose
Create a GPO in this domain
.
-
Expand
-
Specify a name for the new GPO, such as
Allow SSH access
orAllow Console/GUI access
and clickOK
. 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
.
-
Select the OU within the
Assign login permissions:
-
Double-Click on
Allow log on locally
to grant local console/GUI access. -
Double-click on
Allow log on through Remote Desktop Services
to grant SSH access.
-
Double-Click on
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
.
-
Click
Additional resources
- For more details on Group Policy Objects, see Group Policy Objects in Microsoft documentation.
4.5.6. Additional resources
- For more information about joining a RHEL host to an Active Directory environment, see Connecting RHEL systems directly to AD using SSSD.