Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionFlorence Blanc-Renaud
2023-07-06 08:02:14 UTC
Description of problem:
The installation of a RHEL 9.2 replica using a RHEL 8.8 server in FIPS mode fails.
Version-Release number of selected component (if applicable):
On the RHEL 8.8 machine:
# rpm -qa ipa-server krb5-server
ipa-server-4.9.11-6.module+el8.8.0+19022+e8902f4b.x86_64
krb5-server-1.18.2-25.el8_8.x86_64
On the RHEL 9.2 machine:
# rpm -qa ipa-server krb5-server
krb5-server-1.20.1-9.el9_2.x86_64
ipa-server-4.10.1-7.el9_2.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Install a RHEL 8.8 server in FIPS mode
fips-mode-setup --enable
reboot
dnf module enable -y idm:DL1 && dnf module install -y idm:DL1/dns
ipa-server-install [...]
2. Install a RHEL 9.2 replica in FIPS mode
fips-mode-setup --enable
reboot
dnf install -y ipa-server-dns
ipa-replica-install --server server88.ipa.test [...]
Actual results:
The ipa-replica-install command fails in the step initializing the replication. The server initiates a connection to the LDAP server on the replica using gssapi with the principal ldap/server88.ipa.test, but the BIND fails with err=49.
If the replica error log has been set to 4 (connection debugging), the error log shows:
[05/Jul/2023:10:58:43.241529318 -0400] - DEBUG - ids_sasl_server_start - => (conn=14 mech=GSSAPI)
[05/Jul/2023:10:58:43.245416892 -0400] - DEBUG - ids_sasl_log - (2): GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Encryption type aes256-cts-hmac-sha1-96 not permitted)
[05/Jul/2023:10:58:43.248702006 -0400] - DEBUG - ids_sasl_log - (5): GSSAPI server step failed: 1
[05/Jul/2023:10:58:43.251618279 -0400] - DEBUG - ids_sasl_server_start - <= (conn=14 rc=authentication failure)
Expected results:
The replica install should succeed.
Additional info:
The server obtains a TGT using the keytab /etc/dirsrv/ds.keytab. This keytab contains the following encryption types:
# klist -kte /etc/dirsrv/ds.keytab
Keytab name: FILE:/etc/dirsrv/ds.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes256-cts-hmac-sha1-96)
2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes128-cts-hmac-sha1-96)
2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes128-cts-hmac-sha256-128)
2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes256-cts-hmac-sha384-192)
After kinit using this keytab, we can see that the following encryption types are used:
# kinit -kt /etc/dirsrv/ds.keytab ldap/`hostname`
# klist -e
Ticket cache: KCM:0
Default principal: ldap/server88.ipa.test
Valid starting Expires Service principal
07/06/2023 03:50:57 07/07/2023 03:18:34 krbtgt/IPA.TEST
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192
^^^^^^^^^^^^^^^^^^^^^^^
This session key is encrypted with a type that is not supported on RHEL 9 in FIPS mode.
Changing the ordering of the "permitted_enctypes" set by the crypto-policy (bug 2219912) should be enough to fix this issue.
I was worried it may have interoperability impact with Active Directory, because it would result in AES HMAC-SHA2-encrypted tickets to be send to AD. However, this case is already handled because AES HMAC-SHA2 keys are not created for the AD cross-realm TGT principal in case of a two-way trust:
kadmin.local: getprinc krbtgt/AD-G229.TEST
Principal: krbtgt/AD-G229.TEST
Expiration date: [never]
Last password change: Thu Jul 06 10:56:55 EDT 2023
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Jul 06 10:56:55 EDT 2023 (krbtgt/AD-G229.TEST)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 3
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
Key: vno 1, DEPRECATED:arcfour-hmac
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
Hence, AES HMAC-SHA2 will be used for local services, and AES HMAC-SHA1 will be used for AD services:
# klist -e
Ticket cache: KCM:0
Default principal: admin
Valid starting Expires Service principal
07/06/2023 11:31:04 07/06/2023 21:31:04 cifs/dc-g229.ad-g229.test
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
07/06/2023 11:30:59 07/07/2023 11:17:33 krbtgt/IPA.TEST
Etype (skey, tkt): aes256-cts-hmac-sha384-192, aes256-cts-hmac-sha384-192
07/06/2023 11:31:04 07/07/2023 11:17:33 krbtgt/AD-G229.TEST
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
07/06/2023 11:31:15 07/07/2023 11:17:33 ldap/master.ipa.test
Etype (skey, tkt): aes256-cts-hmac-sha384-192, aes256-cts-hmac-sha1-96
Description of problem: The installation of a RHEL 9.2 replica using a RHEL 8.8 server in FIPS mode fails. Version-Release number of selected component (if applicable): On the RHEL 8.8 machine: # rpm -qa ipa-server krb5-server ipa-server-4.9.11-6.module+el8.8.0+19022+e8902f4b.x86_64 krb5-server-1.18.2-25.el8_8.x86_64 On the RHEL 9.2 machine: # rpm -qa ipa-server krb5-server krb5-server-1.20.1-9.el9_2.x86_64 ipa-server-4.10.1-7.el9_2.x86_64 How reproducible: Always Steps to Reproduce: 1. Install a RHEL 8.8 server in FIPS mode fips-mode-setup --enable reboot dnf module enable -y idm:DL1 && dnf module install -y idm:DL1/dns ipa-server-install [...] 2. Install a RHEL 9.2 replica in FIPS mode fips-mode-setup --enable reboot dnf install -y ipa-server-dns ipa-replica-install --server server88.ipa.test [...] Actual results: The ipa-replica-install command fails in the step initializing the replication. The server initiates a connection to the LDAP server on the replica using gssapi with the principal ldap/server88.ipa.test, but the BIND fails with err=49. If the replica error log has been set to 4 (connection debugging), the error log shows: [05/Jul/2023:10:58:43.241529318 -0400] - DEBUG - ids_sasl_server_start - => (conn=14 mech=GSSAPI) [05/Jul/2023:10:58:43.245416892 -0400] - DEBUG - ids_sasl_log - (2): GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Encryption type aes256-cts-hmac-sha1-96 not permitted) [05/Jul/2023:10:58:43.248702006 -0400] - DEBUG - ids_sasl_log - (5): GSSAPI server step failed: 1 [05/Jul/2023:10:58:43.251618279 -0400] - DEBUG - ids_sasl_server_start - <= (conn=14 rc=authentication failure) Expected results: The replica install should succeed. Additional info: The server obtains a TGT using the keytab /etc/dirsrv/ds.keytab. This keytab contains the following encryption types: # klist -kte /etc/dirsrv/ds.keytab Keytab name: FILE:/etc/dirsrv/ds.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes256-cts-hmac-sha1-96) 2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes128-cts-hmac-sha1-96) 2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes128-cts-hmac-sha256-128) 2 07/06/2023 02:14:31 ldap/server88.ipa.test (aes256-cts-hmac-sha384-192) After kinit using this keytab, we can see that the following encryption types are used: # kinit -kt /etc/dirsrv/ds.keytab ldap/`hostname` # klist -e Ticket cache: KCM:0 Default principal: ldap/server88.ipa.test Valid starting Expires Service principal 07/06/2023 03:50:57 07/07/2023 03:18:34 krbtgt/IPA.TEST Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192 ^^^^^^^^^^^^^^^^^^^^^^^ This session key is encrypted with a type that is not supported on RHEL 9 in FIPS mode.