Friday, November 06, 2015

Kerberos propagation and unusual networking

My Kerberos servers are scattered around the Internet, behind NAT in some cases, connected with VPNs, etc. As such the hostname or IP that one server might use to connect to another is often different from the actual hostname or default IP of the other server.

For most services this isn't a particular challenge, but Kerberos replication with kprop and kpropd has often been difficult to get working. In moving some of my Kerberos services into Docker I've discovered a few details.

To set the stage, you typically run kprop on your Kerberos master and give it the hostname of a slave to which you are pushing replication.  The slave runs kpropd to accept these connections.

Things I've found:


The hostname you give to kprop must be the actual hostname on the slave. In some ways Docker makes this easier as you can put kpropd in its own container and set the necessary hostname. If the hostnames do not match then kprop will fail with:

kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
Generic remote error: Key table entry not found

The IP address that kprop connects to must be an IP address on the slave. NAT or Docker's default networking, where you expose particular ports with the -p flag and Docker does NAT and PAT, is incompatible with kprop. I got around this by using a VPN and Docker's --net=host style of networking. If the slave doesn't know about the IP address that kprop used then kprop will fail with:

kprop: Incorrect net address signalled from server
Error text from server: while decoding database size