On 4/7/2017 12:55 PM, Jeffrey Hutzelman wrote:
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).
Changing the hostname on the slave works. The hostname doesn't even have
to be fully-qualified.
If I want to use a non-hostname-based iprop principal I could change
hostname, start ipropd-slave, and change hostname back (this assumes
that ipropd-slave does its hostname lookup only at the start and then
never again). But this approach is very klunky.
It would be nice if I could start ipropd-slave with an option to set the
iprop principal to something other than `hostname`.
Thanks very much!
Adam Lewenberg
-- 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...
