Bug 2220834
| Summary: | Migration of a RHEL 8.8+ server to RHEL 9.2 fails in FIPS mode | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Florence Blanc-Renaud <frenaud> |
| Component: | ipa | Assignee: | Julien Rische <jrische> |
| Status: | NEW --- | QA Contact: | ipa-qe |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.9 | CC: | rcritten, tscherf |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2219912 | ||
| Bug Blocks: | |||
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.