When migrating between major versions of IPA or an operating system, say RHEL 7 to RHEL 8, this is generally done by creating a new master using the latest version of IPA on the latest distro release. Then slowly migrating the old to new, eventually ending up with all new.
We often get asked what the downside of moving slowly is. Generally we give an answer like “objects created in the newer server(s) should still work fine on the older ones, but new objects created in the older servers will lack new features.”
Here is a specific answer.
I’ve been looking at extending password policy. This is going to require extending the schema in some way with new attributes to hold the new configuration values. This isn’t a problem with mixing old and new versions as the schema is replicated to all servers.
But what would be missing would be policy enforcement! For argument’s sake let’s say the new policy has cracklib integration, so passwords are checked against the dictionary among other checks.
What this means in practice is that only those passwords changed on the newer servers with this integration will actually have the policy applied. Not good.
The moral of the story is: yes, there is a window of opportunity for these types of issues in the middle of a migration between versions. Understand it and plan around it. If it is unacceptable then migrate faster. If the risk is acceptable, migrate more slowly. Either way still only migrate one server at a time to avoid replication issues as the new changes get rolled out.