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.
Bug 2220834 - Migration of a RHEL 8.8+ server to RHEL 9.2 fails in FIPS mode
Summary: Migration of a RHEL 8.8+ server to RHEL 9.2 fails in FIPS mode
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Julien Rische
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On: 2219912
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-06 08:02 UTC by Florence Blanc-Renaud
Modified: 2023-08-24 15:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-24 15:47:15 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-10114 0 None None None 2023-07-06 08:04:44 UTC
Red Hat Issue Tracker RHELPLAN-161663 0 None None None 2023-07-06 08:04:48 UTC

Description Florence 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.
Comment 2 Julien Rische 2023-07-06 15:33:34 UTC 
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
Comment 3 Julien Rische 2023-08-24 15:47:15 UTC 
I confirm the crypto-policies fix from bug 2219912 now enables to create a RHEL 9.3 IPA replica from a RHEL 8.9 IPA server in FIPS mode.
Note You need to log in before you can comment on or make changes to this bug.