[krbdev.mit.edu #8333] Multiple incremental propagation issues hosting non-default realms

[Russ Allbery via RT]

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 <realm> 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 <realm> 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 <realm> 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/<hostname> 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 at eyrie.org)              <http://www.eyrie.org/~eagle/>