Pinning KDC IP addresses.

Jeffrey Altman jaltman at
Fri Feb 16 04:55:48 EST 2007

g.w at wrote:
> Certainly a very valid concern.  I find it an interesting observation
> in the context of previous conversations on this list.
> I remember about two months ago a user showing up and asking questions
> about how to setup KDC's behind a load balancer.  Exactly the type of
> environment which fits your description of being problematic.
> The user was pretty soundly browbeaten about how foolish and
> malfeasant his strategy was.  The recommendations were pretty firm and
> not very subtle that he should simply go off and deploy 'naked' KDC's.
> I take the wisdom on this list pretty seriously.  Based on that
> exchange and others which have gone by the standard of 'best practice'
> appears to be to not NAT, proxy, tunnel, shroud or otherwise obscure
> your KDC's.

You are mis-understanding my concern.  On my network I do not have a
choice but to run my multiple KDCs behind a NAT because I do not have
enough public address space.  My KDCs need to be aware of the internal
networking infrastructure and in fact they are publicly available via
the public NAT'd IP address assigned to them.  There is also the
possibility of VPN'ing into the private network from outside which
gives a third range of addresses for the VPN clients and the resources
they are permitted access to on their VLAN.  The KDCs can therefore
be reached via three IP addresses but they are only aware of one, the
private network interface.

My concern is, how would my KDCs be able to respond to your client
requests that are embedding addresses that the KDCs are not aware of?

In the same train of thought, how would this work with a protocol
that was used to authenticate a mobile client as part of the issuance
of an IP address to the client so that it may be permitted to access
the network in the first place?

>> Many large organizations that I know of are attempting to get the
>> remaining IP address checking removed from the code base.  Adding
>> addition IP address based checks would not be seen as a benefit to
>> them.
> I'm certain large organizations will be extremely persistent about
> violating best practices in deploying security architectures.  There
> seems to be ample historical precedent for that.

IP addresses do not make secure bindings.   Removing the use of
IP addresses is best practice.

Jeffrey Altman

More information about the krbdev mailing list