Chapter 5. Ensuring support for common encryption types in AD and RHEL
Chapter 5. Ensuring support for common encryption types in AD and RHEL By default, Identity Management establishes a cross-realm trust with support for AES-128 and AES-256 Kerberos encryption types. Additionally, by default SSSD and Samba Winbind support AES-128 and AES-256 Kerberos encryption types. RC4 encryption is deprecated and disabled by default since RHEL 8.3 and RHEL 9, as it is considered less secure than the newer AES-128 and AES-256 encryption types. In contrast, Active Directory (AD) user credentials and trusts between AD domains support RC4 encryption and they might not support all AES encryption types. Without any common encryption types, communication between RHEL hosts and AD domains might not work, or some AD accounts might not be able to authenticate. To address this situation, perform one of the configurations outlined in the following sections. Important If IdM is in FIPS mode, the IdM-AD integration does not work due to AD only supporting the use of RC4 or AES HMAC-SHA1 encryptions, while RHEL 9 in FIPS mode allows only AES HMAC-SHA2 by default. For more information, see the AD Domain Users unable to login in to the FIPS-compliant environment KCS solution. IdM does not support the more restrictive FIPS:OSPP crypto policy, which should only be used on Common Criteria evaluated systems. Note Establishing a two-way cross-forest trust between AD and Identity Management IdM with FIPS mode enabled fails because the New Technology LAN Manager Security Support Provider (NTLMSSP) authentication is not FIPS-compliant. IdM in FIPS mode does not accept the RC4 NTLM hash that the AD domain controller uses when attempting to authenticate. 5.1. Enabling AES encryption in AD (recommended) To ensure trusts between Active Directory (AD) domains in an AD forest support strong AES encryption types, see the following Microsoft article: AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain 5.2. Enabling the AES encryption type in Active Directory using a GPO Enable the AES encryption type in Active Directory (AD) using a group policy object (GPO). Certain features on RHEL, such as running a Samba server on an IdM client, require this encryption type. Note that RHEL no longer supports the weak DES and RC4 encryption types. Prerequisites You are logged into AD as a user who can edit group policies. The Group Policy Management Console is installed on the computer. Procedure Open the Group Policy Management Console. Right-click Default Domain Policy , and select Edit . The Group Policy Management Editor opens. Navigate to Computer Configuration Policies Windows Settings Security Settings Local Policies Security Options . Double-click the Network security: Configure encryption types allowed for Kerberos policy. Select AES256_HMAC_SHA1 and, optionally, Future encryption types . Click OK . Close the Group Policy Management Editor. Repeat the steps for the Default Domain Controller Policy . Wait until the Windows domain controllers (DC) applied the group policy automatically. Alternatively, to apply the GPO manually on a DC, enter the following command using an account that has administrator permissions: 5.3. Enabling RC4 support in RHEL On every RHEL host where authentication against AD Domain Controllers takes place, complete the steps outlined below. Procedure Use the update-crypto-policies command to enable the AD-SUPPORT-LEGACY cryptographic subpolicy in addition to the DEFAULT cryptographic policy. Restart the host. 5.4. Additional resources Using system-wide cryptographic policies Trust controllers and trust agents
C:\> gpupdate /force /target:computer update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY Setting system policy to LEGACY:AD-SUPPORT-LEGACY Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place.