RHEL IdM servers can be configured in FIPS mode. If there is already an IdM deployment in FIPS mode and a new server is being added, it must also be deployed in FIPS mode. FIPS mode in RHEL 8 allows AES SHA-1 HMAC encryption types while in RHEL 9 it would not allow by default. However, RHEL 8 FIPS mode deployment would also provide AES SHA-2 HMAC encryption types support so there is overlapping encryption types for interoperability purposes. When trust to Active Directory is established from RHEL IdM deployed in FIPS mode on RHEL 8, AES SHA-1 HMAC encryption types would be enabled on the RHEL 8 systems. Adding IdM server as a replica on RHEL 9 in FIPS mode would work but such servers will not be interoperable with Active Directory unless FIPS mode requirements were relaxed before deployment with AD-SUPPORT crypto subpolicy. If RHEL IdM server was deployed in FIPS mode on RHEL 9 initially and later extended to support trust to Active Directory, existing keys for all IdM Kerberos services would not be compatible with encryption types supported by Active Directory and thus those keys will need to be regenerated. There is no ready-made mechanism to safely re-generate keys without causing outage to existing clients. Several additional steps would need to be done: - RHEL system crypto policy would need to be extended with AD-SUPPORT crypto subpolicy - keys for existing Kerberos principals need to be renewed with the help of ipa-getkeytab utility - cross-realm TGT keys need to be renewed - [more work?]
Current findings when attempting to deploy IPA on RHEL 9 in FIPS mode with a test build of krb5: - master key is defaulting to aes256-cts-hmac-sha1-96, needs to be updated to use aes256-cts-hmac-sha384-192 in install/share/kdc.conf.template - install/share/kerberos.ldif needs to be extended to add krbDefaultEncSaltTypes: aes256-sha2:special krbDefaultEncSaltTypes: aes128-sha2:special - even if supported_enctypes is extended to include SHA2-HMAC-based encryption types, somehow those ignored and SHA-1-HMAC based enctypes used: [root@master ~]# kadmin.local -x ipa-setup-override-restrictions Authenticating as principal root/admin with password. kadmin.local: ank -randkey -e aes256-cts-hmac-sha1-96:normal,aes256-cts-hmac-sha1-96:special,aes128-cts-hmac-sha1-96:normal,aes128-cts-hmac-sha1-96:special,aes256-cts-hmac-sha384-192:normal,aes256-cts-hmac-sha384-192:special,aes128-cts-hmac-sha256-128:normal,aes128-cts-hmac-sha256-128:special foobar No policy specified for foobar; defaulting to no policy Principal "foobar" created. kadmin.local: getprinc foobar Principal: foobar Expiration date: [never] Last password change: Thu Feb 24 05:25:08 EST 2022 Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Thu Feb 24 05:25:08 EST 2022 (root/admin) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 4 Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 Key: vno 1, aes256-cts-hmac-sha384-192 Key: vno 1, aes128-cts-hmac-sha256-128 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] kadmin.local: delprinc foobar Are you sure you want to delete the principal "foobar"? (yes/no): yes Principal "foobar" deleted. Make sure that you have removed this principal from all ACLs before reusing. kadmin.local: ank -randkey foobar No policy specified for foobar; defaulting to no policy Principal "foobar" created. kadmin.local: getprinc foobar Principal: foobar Expiration date: [never] Last password change: Thu Feb 24 05:25:39 EST 2022 Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Thu Feb 24 05:25:39 EST 2022 (root/admin) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 2 Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] If both kdc.conf.template and kerberos.ldif updated, creating KDC instance succeeds. However, later we fail when requesting RA certificate from CA because OpenSSL 3.0.0 FIPS crypto provider has no support for PKCS12KDF: https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-FIPS.html [error] CalledProcessError: CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmp8hnp8pj0', '-passin', 'file:/tmp/tmpo9mamzb8'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n') CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmp8hnp8pj0', '-passin', 'file:/tmp/tmpo9mamzb8'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n')
Created attachment 1863149 [details] ipaserver-install.log from successful installation in FIPS mode With openssl 3.0.1-11.el9 I was able to get past RA certificate issuance step and produced working server. Log of installation attached. Additional change I had to do to make it working in install/share/kdc.conf.template: master_key_type = aes256-sha2 supported_enctypes = aes256-cts-hmac-sha1-96:normal aes256-cts-hmac-sha1-96:special aes128-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:special aes256-cts-hmac-sha384-192:normal aes256-cts-hmac-sha384-192:special aes128-cts-hmac-sha256-128:normal aes128-cts-hmac-sha256-128:special This results in using aes256-cts-hmac-sha384 as a master key and issuing keys for all the supported enctypes. This makes it possible to interoperate with RHEL 8 and Active Directory: [root@master ~]# kadmin.local Authenticating as principal admin/admin with password. kadmin.local: getprinc krbtgt/IPA.TEST Principal: krbtgt/IPA.TEST Expiration date: [never] Last password change: [never] Password expiration date: [never] Maximum ticket life: 7 days 00:00:00 Maximum renewable life: 14 days 00:00:00 Last modified: Thu Feb 24 06:19:52 EST 2022 (db_creation) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 4 Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 Key: vno 1, aes256-cts-hmac-sha384-192 Key: vno 1, aes128-cts-hmac-sha256-128 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH LOCKDOWN_KEYS Policy: [none] However, since SHA-1 HMAC-based encryption types aren't enabled by default, they'll be unusable in FIPS mode: [root@master ~]# ipa-getkeytab --permitted-enctypes Supported encryption types: AES-256 CTS mode with 192-bit SHA-384 HMAC AES-128 CTS mode with 128-bit SHA-256 HMAC
Fixed upstream master: https://pagure.io/freeipa/c/d38dd2680fb828da4b36e8eb4ce8dc8b056491ce https://pagure.io/freeipa/c/2eee5931d714ca237290be7dc2fb7233ce747eca https://pagure.io/freeipa/c/985dffe147501e1b9cba3ab0be378115a23c3564 https://pagure.io/freeipa/c/7d25eead994715b98f5dea5679c8fee0db4c4494
Fixed upstream ipa-4-9: https://pagure.io/freeipa/c/a51900819bd5332bc05ec9d513f062844b3a7763 https://pagure.io/freeipa/c/b016683552a58f9cc2a05cf628cc467234eaf599 https://pagure.io/freeipa/c/49d9147e38c5b50c52a1ebc7283753c779c2f81f https://pagure.io/freeipa/c/ee39de46a1c1ea96bbe524f159ae435319b2d072
Moving to POST as the fix is available upstream
Upstream ticket: https://pagure.io/freeipa/issue/9119
Additional fixes. Fixed upstream master: https://pagure.io/freeipa/c/a6030f5f53e077a0443605fba23ef104c797f168 https://pagure.io/freeipa/c/621af275c3564f1d5f1a97c46290b5d166fe8c8a https://pagure.io/freeipa/c/517ae594e1ad80598a154f1dcacf7b303f420fc8
Additional fixes for use of AES in KRA operations Fixed upstream master: https://pagure.io/freeipa/c/40c362e1eeb000867d0e6244ce03b66b6a35e913 https://pagure.io/freeipa/c/b8f45fc68901ae77f250887037b78686c67024b9 === Tickets fixed === https://pagure.io/freeipa/issue/6524
Fixed upstream ipa-4-9: https://pagure.io/freeipa/c/3e54c4362490b4da1b6cb3e141bb6e08fecc58c0 https://pagure.io/freeipa/c/3baae8d1bd0a0c4c707314524289e86e6ecbc0df https://pagure.io/freeipa/c/2e70535f74e7d9dd76e728eca1119ce522fd138a === Tickets fixed === https://pagure.io/freeipa/issue/9119
Fixed upstream ipa-4-9: https://pagure.io/freeipa/c/895e99b6843c2fa2274acab824607c33c1a560a4 https://pagure.io/freeipa/c/984190eea01ac42cd1f97567a67dd9446e5b0bf9 === Tickets fixed === https://pagure.io/freeipa/issue/6524
An additional test fix is required: master: https://pagure.io/freeipa/c/5a42ab115e85698866219e3edc98ceaf439bab55
Additional test fix: ipa-4-9: https://pagure.io/freeipa/c/09481117b58f1a237bb1048d3fe8d44caf9e167f
version: ipa-server-4.9.8-7.el9_0.x86_64 krb5-server-1.19.1-15.el9_0.x86_64 openssl-3.0.1-20.el9_0.x86_64 Automated tests in FIPS mode look promising. Based on the results marking the bug verified.
Additional test fix: master: 27ab216 ipatests: fix check for AD topology being present ipa-4-9: b6b5f60 ipatests: fix check for AD topology being present
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: ipa), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:2387