bind KDC to single interface?

[Abe Singer]

I'll give you a reason for why I need it.  I'm trying to fire up
krb5kdbc listening on a virtual interface on a host where there's another
process (not krb5kdc) listening on the same port on other interfaces.
I'm sure that at least some of the other people who ask have some other
valid reason for doing so.

As for binding a socket on each separate address, the syslog messages
from krb5kdc indicate that it is already doing just that for UDP (see below).
There's just no feature to restrict which of those get bound.

Syslog messages (ip addresses changed to protect the innocent):

Feb 25 08:31:39 mykdc krb5kdc[2948](info): setting up network...
Feb 25 08:31:39 mykdc krb5kdc[2948](info): skipping unrecognized local address family 17
Feb 25 08:31:39 mykdc krb5kdc[2948](info): listening on fd 8: udp 10.0.0.1.89
Feb 25 08:31:39 mykdc krb5kdc[2948](info): listening on fd 9: udp 10.0.0.2.89
Feb 25 08:31:39 mykdc krb5kdc[2948](info): listening on fd 10: udp 10.0.0.3.89
Feb 25 08:31:39 mykdc krb5kdc[2948](info): listening on fd 11: udp 10.0.0.4.8.89
Feb 25 08:31:39 mykdc krb5kdc[2948](info): listening on fd 14: tcp 0.0.0.0.89
Feb 25 08:31:39 mykdc krb5kdc[2948](info): listening on fd 13: tcp ::.89
Feb 25 08:31:39 mykdc krb5kdc[2948](info): set up 6 sockets



On Tue, Feb 23, 2010 at 02:17:17AM -0500, Ken Raeburn wrote:
> 
> Sort of... the KDC needs to be able to return a response from the same (KDC-side) address that the client used, so it either needs something like IP(V6)_PKTINFO support, in which case it can use IN(6)ADDR_ANY, or it needs to bind a socket on each local address.  While I've occasionally heard queries about whether it's possible to bind to one address only, and it would probably be good to offer that someday, I've never heard anyone indicate why accepting Kerberos traffic on the other addresses is a problem....  Perhaps if you want to run a KDC for a different realm on a different address on the same machine, but you can serve up multiple realms from one KDC process.  Or maybe they're running the KDC on a machine accessible from both internal and external networks, and have a security policy in place that prohibits the latter because of the offline-password-attack risk?
> 
> But, short answer, yeah, there's no option for that currently.  It's one of a few things I've been thinking about tweaking in the KDC network handling though...