I just wanted to highlight the fact that for Fedora, CentOS, and RHEL, we try to keep the content of the first krb5 configuration file (/etc/krb5.conf) to the minimum (mainly libdefaults global parameters)[1]. We start the file by including the /etc/krb5.conf.d configuration folder. This allows us to have a more modular configuration system. It is very convenient to delegate realm configuration and domain/realm mapping to application maintainers. We also do so to delegate permitted encryption types configuration to system-wide policy tools. With the points above in mind, I have the following concerns about the current limitations of the profile API for our case: * About profile_add_relation(), the mention "at the end of the first file's values for the relation, but before any values appearing in other files" is confusing me. I was having the impression that relations were added to the tree in the file parsing order. At least I believe that if a value A is set for a certain parameter in a sub-file, before the value B being set to the same parameter in the first file, the list of resolved values will still be "A, B" (in this order). So even if the trees of all files are not merged, it seems the parsing order does still apply somehow. * profile_clear_relation(), profile_update_relation(), and profile_rename_section() will only have effect on the few default settings from /etc/krb5.conf. In our case most of these relations are single value parameters. If there are multiple values set for this kind of parameters the first one is selected. This tends to confuse users a lot, because it seems the norm for configuration files is the variable assignment logic (the last assignment of a given parameter in the parsing order is the one that is actually applied), which is the complete opposite of the present approach. Hence if some /etc/krb5.conf parameters are overridden in /etc/krb5.conf.d/*, these 3 functions won't have any effect on these parameters, since the relations they will modify in /etc/krb5.conf are not the ones that are resolved first. If I got it right, the FreeRDP use case is to export a modified version of the tree where the list of KDC addresses for a given realm is replaced by another address. I believe the reason why they use such an approach is because of the "*" marker limitation for relations in subsections[2]. If this was supported, they could simply configure KRB5_CONFIG with a generated file such as: [realms] EXAMPLE.COM = { kdc* = kdc.example.com } include /etc/krb5.conf This would completely override any /realms/EXAMPLE.COM/kdc relations, while still applying the rest of the system configuration. [1] https://src.fedoraproject.org/rpms/krb5/blob/rawhide/f/krb5.conf [2] https://github.com/krb5/krb5/blob/krb5-1.21.2-final/src/util/profile/final2.ini#L1-L3