Cloned from: https://pagure.io/freeipa/issue/9840

Kerberos multivalued configuration attributes `krbSupportedEncSaltTypes` and `krbDefaultEncSaltTypes` seem to be based on the assumption that the LDAP database preserves values' order. However, it seems values collections in LDAP are sets, not lists. Hence there is no guarantee the order we get from the query to 389ds will reflect the actual configuration. It is actually the case, given the current 389ds implementation, but this may no longer be the case in the future.

Atop of this first problem comes a second one: the semantic [that has been used for updating the list of supported/default encryption types](https://github.com/freeipa/freeipa/blob/release-4-12-4/install/updates/50-krbenctypes.update) (i.e. allowed and used by default for Kerberos keys) is adding the new ones to the current set, but does not reset it. This makes sense because in some gradual upgrade environments, the different versions of IPA may be using a different set of encryption types, hence we don't want to have different replica versions constantly fighting on the supported enctypes list by rewriting their own version list on each update. But the consequence of this update strategy, given the fact that 389ds preserve the order of the attribute values, is that if new encryption types are added, they will become the last elements of the list. This is not the behavior we need, because the new encryption types are likely to be the strongest ones, so we want to prioritize them as often as possible.

The current situation seems to be that the domains that were configured with AES-SHA1 as the strongest enctyption types, and were updated to support AES-SHA2 at some point are probably having misconfigured services. When keys are generated, they follow the same order as the supported enctypes parameter. And when the KDC handles a TGS-REQ, it picks the session key encryption type based on enctypes order in the list provided by the client. But for ticket encryption, the order that matters is the keys order in the service entry. I think this behavior was designed this way in order to allow service administrators to control the encryption types of the tickets their service will receive.

So the main problem at this point is that fixing the supported/default enctypes parameter order problem alone will not be enough to make sure tickets will be generated with the strongest encryption types available. Either we have to force the reordering of keys when queried (at the price of disabling service administrators to configure their own preferred order), or we ask administrators to regenerate their service credentials after the supported/default enctypes list is fixed.