Can ipropd-master service not do reverse DNS lookups?

Jeffrey Hutzelman jhutz at cmu.edu
Fri Apr 7 21:55:44 CEST 2017


On Fri, 2017-04-07 at 12:31 -0700, Adam Lewenberg wrote:
> I am trying to set up iprop replication for a slave KDC running on a 
> container in an EC2 instance in Amazon Web Services (AWS). We are 
> running Heimdal 1.5.2.
> 
> When the slave ipropd-slave connects to the master, it looks like
> the 
> master is doing a reverse DNS lookup on the slave's IP address and 
> getting one of those long Amazon addresses (e.g., 
> ec2-52-45-91-42.us-west-2.compute.amazonaws.com). It then looks for
> the 
> principal "iprop/ec2-52-45-91-42.us-west-2.compute.amazonaws.com" in
> its 
> database.

Are you sure that's what's happening?  ipropd connections are made by
the slave to the master, and the authentication runs in that direction.
The master can't just make up a principal name; it has to use the one
in the ticket actually presented by the slave.

Looking at (fairly old) code, what appears to be the case is that
ipropd-slave constructs its own client principal name by calling
krb5_sname_to_principal with a NULL hostname (which means to use the
local hostname). Unfortunately, the library persists in taking that as
license to perform forward and reverse DNS name lookups in deriving the
Kerberos principal name, despite over a decade of advice to the
contrary, including RFC4120 which states "Implementations of Kerberos
and protocols based on Kerberos MUST NOT use insecure DNS quereies to
canonicalize the hostname components of service principal names."*


So no, there's no way to avoid using a hostname. However, I believe you
should be able to suppress the reverse DNS resolution step by setting
"rdns=false" in the libdefaults section of krb5.conf. After that, it
should use whatever `hostname` returns (at least, if that's fully
qualified).


-- Jeff


(*) No, I'm not even slightly bitter over this failure of every major
Kerberos implementation to avoid what I consider to be a significant
security issue. After all, it's not like they were all there when
RFC4120 was written...



More information about the Heimdal-discuss mailing list