Upstream ticket:
https://pagure.io/freeipa/issue/7090

No, it is *not* possible to migrate an existing IDM installation from a non-FIPS environment to a FIPS compliant installation. This is not a technical problem but a legal and regulatory restriction.

I discussed the matter internally with our FIPS expert. He confirmed what I already suspected. It's not permitted to enable FIPS mode on a non-FIPS machine and then claim to be FIPS compliant. To be FIPS compliant any and all cryptographic key material *must* be created in FIPS mode. Further more this cryptographic key material must never leave FIPS environment unless it's securely wrapped and never unwrapped in non-FIPS environments.

Simply speaking: as soon as a key is created or comes in contact with a non-FIPS environment, it becomes tainted and violates FIPS compliance.

The best we could do is:

* create a new IPA realm in FIPS mode
* perform a data migration from non-FIPS realm to new FIPS realm with a filter to block all key material

The migration must block:
* KDC master key, keytabs, and all related Kerberos key material
* user passwords
* all certificates including CA, service, and user certificates
* OTP tokens
* SSH keys and fingerprints
* DNSSEC KSK and ZSK
* all vault entries
* AD trust-related key material

Effectively the new FIPS installation is a different installation. You'd have to replace all host keytabs, service keytabs, service certs, and CA cert on all clients. Any trust with AD realms have to be re-established, too.

Even with rigorous filtering we aren't sure if this migration is going to pass FIPS muster. Your FIPS auditor may flag this migration.

Based on https://bugzilla.redhat.com/show_bug.cgi?id=1475085#c10 we closed this RFE as WONTFIX.

What about a new feature added to the ipa-backup that will allow you to backup everything that is *NOT* affected by a change to FIPS like users, groups, DNS, etc. so then you are still essentially starting over with a new install BUT you can restore at least some things.

Another other option is add a feature to the installer that reads everything it can from one master in the post install process of a new IPA server and creates everything it can to match the old system into the new system.

Or a really good option is a tool that just reads the configuration (This could be done in Ansible fairly easily) and creates a list of ipa commands or an ansible yaml file that can be used to create/recreate the same setup similar to how a DB does a dump of SQL commands that can be replayed on a DBV to restore it.

In all 3 methods you are essentially starting over BUT you are GREATLY limiting the amount of loss!  The added benefit of this is it can be used to solve *MANY* issues like:

1. perform in-place upgrades like from CentOS to RHEL
2. Migrate from non-FIPS to FIPS
3. fixing a corrupted IPA install
4. install a new system that does not have certain things like ad trusts
5. install a new system that is for testing, replicating issues, or a new environment that must match an existing environment

In all these cases any of these methods are basically starting over on a new install and would NOT interfere with FIPS in ANY way.  There would be some loss like user passwords, certs, etc. but that is a FAR better fate than loosing EVERYTHING and starting over!

We have a plan for IPA-IPA migration: https://freeipa.readthedocs.io/en/latest/designs/ipa_to_ipa_migration.html

This is not implemented yet, but it is pretty much along the same lines.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days