Chapter 5. Ensuring support for common encryption types in AD and RHEL
By default, Identity Management establishes a cross-realm trust with support for RC4, AES-128, and AES-256 Kerberos encryption types. Additionally, by default SSSD and Samba Winbind support RC4, AES-128, and AES-256 Kerberos encryption types.
RC4 encryption has been deprecated and disabled by default, 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.
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. To enable the use of AES HMAC-SHA1 in RHEL 9, enter # update-crypto-policies --set FIPS:AD-SUPPORT.
IdM does not support the more restrictive FIPS:OSPP crypto policy, which should only be used on Common Criteria evaluated systems.
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
This section describes how to 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 Consoleis installed on the computer.
Procedure
-
Open the
Group Policy Management Console. -
Right-click
Default Domain Policy, and selectEdit. TheGroup Policy Management Editoropens. -
Navigate to
Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options. -
Double-click the
Network security: Configure encryption types allowed for Kerberospolicy. -
Select
AES256_HMAC_SHA1and, optionally,Future encryption types. - Click .
-
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:
C:\> gpupdate /force /target:computer
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-policiescommand to enable theAD-SUPPORT-LEGACYcryptographic subpolicy in addition to theDEFAULTcryptographic policy.[root@host ~]# 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.- Restart the host.
