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...
