For various reasons (development realms, separate realms for users and machines), I frequently want to host a Kerberos realm on a system that has some other realm as its default realm. This generally works well if one remembers to add -r flags to krb5kdc, kadmind, and all kadmin and related local commands. However, when trying to also use incremental replication, I ran into several related issues. Not sure if this is all one bug or several bugs, so starting with one bug and letting you clone if desired. All of these problems have the same root cause: realm information given on the command line doesn't propagate into all the places it needs to. 1. kpropd does not use the -r flag when deciding what KDC configuration to read, and therefore does not get the correct stanza in /etc/krb5kdc/kdc.conf. The usual symptom is that it doesn't pick up iprop_enable setting and just listens to normal network connections. Workaround: Create separate krb5.conf file with the default realm set to the served realm and using KRB5_CONFIG to redirect kpropd to that config file. 2. When a new replica needs a full replication, kadmind does not pass the realm information from its command-line -r flag to kdb5_util to generate a dump of the database. kdb5_util therefore fails, and the replica end stalls waiting for a full replication. Workaround: Create a wrapper that sets KRB5_CONFIG as above and then execs kdb5_util, and tell kadmind to use that wrapper with the -p flag. 3. Once you get past kdb5_util, kprop run by kadmind has the same issue. I used the same fix and the -K option, plus disabling normal domain-realm mapping and forcing all hosts into the served realm in that secondary configuration, and then added a host/ keytab in the served realm to /etc/krb5.keytab on the replica. I'm not sure if there's a simpler approach using cross-realm authentication. Incidentally, the error reporting on the kadmind side is horrid. With the kdb5_util problem above, the only error reporting in the logs was: Dec 23 22:34:43 dfw3b-rm1-1a kadmind[70510]: iprop_full_resync_1: pclose(popen) failed: No such file or directory which actually means "kdb5_util died with some error message nothing captured." Once kdb5_util was fixed, failures in kprop resulted in no log messages whatsoever on either side. I had to use strace to figure out what was failing. -- Russ Allbery (eagle@eyrie.org)