Chapter 4. Managing direct connections to AD After you connect your Red Hat Enterprise Linux (RHEL) system to an Active Directory (AD) domain using System Security Services Daemon (SSSD) or Samba Winbind, you can manage key settings such as Kerberos renewals, domain membership, user access permissions, and Group Policy Objects (GPOs). 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: Restart SSSD: To disable the automatic Kerberos host keytab renewal, set ad_maximum_machine_account_password_age = 0 . Additional resources adcli(8) sssd.conf(5) SSSD service is failing with an error 'Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed.' (Red Hat Knowledgebase) 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. Note When 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 the realm 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 called Administrator . If a different user was used to join to the domain, it might be required to perform the removal as that 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: Additional resources realm(8) man page on your system 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. Save and close the file. Restart the SSSD service to load the new configuration settings. Verification Verify you can retrieve user information for a user from the first domain using only a short name. 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. Note 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. You can override this default behavior and configure a RHEL host to enable access for users within an AD domain. Important 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: Grant access to specific users: 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: Use the ssh command a second time to access the same server, this time as the aduser02@example.com user: 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. Note 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 realm(8) man page on your system 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. You can override this default behavior and configure a RHEL host to deny access to users within an AD domain. Important 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: This command prevents realm accounts from logging into the local machine. Use realm permit to restrict login to specific accounts. Verify that the domain user's login-policy is set to deny-any-login : Deny access to specific users by using the -x option: Verification Use SSH to log in to the server as the aduser01@example.net user. Note 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 realm(8) man page on your system 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. 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 or later: SSSD supports users, groups, and hosts in security filters. RHEL versions earlier 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. Table 4.1. GPO access control options retrieved by SSSD GPO option Corresponding sssd.conf option Allow log on locally Deny log on locally ad_gpo_map_interactive Allow log on through Remote Desktop Services Deny log on through Remote Desktop Services ad_gpo_map_remote_interactive Access this computer from the network Deny access to this computer from the network ad_gpo_map_network Allow log on as a batch job Deny log on as a batch job ad_gpo_map_batch Allow log on as a service Deny log on as a service ad_gpo_map_service Additional resources sssd-ad(5) man page on your system 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. Table 4.2. Table of ad_gpo_access_control values Value of ad_gpo_access_control Behavior enforcing GPO-based access control rules are evaluated and enforced. This is the default setting in RHEL 8. permissive GPO-based access control rules are evaluated but not enforced; a syslog message is recorded every time access would be denied. This is the default setting in RHEL 7. This mode is ideal for testing policy adjustments while allowing users to continue logging in. disabled 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 . Table 4.3. Login behavior with ad_gpo_implicit_deny set to False (default) 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 Table 4.4. Login behavior with ad_gpo_implicit_deny set to True 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 Changing the GPO access control mode sssd-ad(5) man page on your system 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. Important If you see the following errors, Active Directory users are unable to log in due to GPO-based access controls: In /var/log/secure : In /var/log/sssd/sssd__example.com_.log : 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 requires root permissions. Procedure Stop the SSSD service. Open the /etc/sssd/sssd.conf file in a text editor. Set ad_gpo_access_control to permissive in the domain section for the AD domain. Save the /etc/sssd/sssd.conf file. Restart the SSSD service to load configuration changes. Additional resources 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 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 . Additional resources Group Policy Objects in Microsoft documentation 4.5.6. Additional resources Connecting RHEL systems directly to AD using SSSD

Commands:
ad_maximum_machine_account_password_age = value_in_days
systemctl restart sssd
realm leave ad.example.com
realm leave [ ad.example.com ] -U [ AD.EXAMPLE.COM\user ]'
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
domain_resolution_order = subdomain2.ad.example.com, subdomain1.ad.example.com, ad.example.com
systemctl restart sssd
id <user_from_subdomain2> uid=1916901142(user_from_subdomain2) gid=1916900513(domain users) groups=1916900513(domain users)
realm permit --all
realm permit aduser01@example.com realm permit 'AD.EXAMPLE.COM\aduser01'
ssh aduser01@example.com@ server_name [aduser01@example.com@ server_name ~]USD
ssh aduser02@example.com@ server_name Authentication failed.
realm deny --all
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
realm permit -x 'AD.EXAMPLE.COM\aduser02'
ssh aduser01@example.net@ server_name Authentication failed.
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]
(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.
systemctl stop sssd
[domain/ example.com ] ad_gpo_access_control= permissive
systemctl restart sssd