The problem that I see when having two KDC masters with the same realm name is that there are two different kerberos databases per master, which means that they have different data, encrypt with different master keys, use different salt, and they may even use different encryption types (if installed from different distributions, for example).
For instance, you can make sure that the data is different by executing the following command on both of your masters and then compare the output:
kdb5_util tabdump keydata
The correct case for the cross-realm authentication is when there are two or at least two KDC masters responsible for different realms in different domains and you still want users from one realm to authenticate in another realm:
https://web.mit.edu/KERBEROS/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Cross_002drealm-Authentication.html
When there are two KDCs in one realm and domain it would make sense to make one of them a master KDC and another one - slave. Which leads me to a question - what was the reason for having the second KDC master in the first place?
- Was it HA concerns? Then indeed one of the KDC masters needs to be made a slave KDC.
- Were the both
app-cluster and data-cluster in different domains? Then it would make sense to have different realms.
If there are no high availability concerns so far (e.g. these two clusters are both still on the stage of development), another option could be to use just one KDC master without any slaves and configure nodes in all clusters to talk to this KDC.
General recommendations on the configuration of a realm:
https://web.mit.edu/kerberos/krb5-1.12/doc/admin/realm_config.html
