Searching the archives of this list has revealed that the issue of server name canonicalization has often been brought up, but I have many questions unanswered.
Specifically: what exactly is the advantage, in terms of either security or efficiency, of necessitating the use of canonical names over aliases? I cannot find answers to this question in the documentation, and only unclear references to advantages among the developers. It seems that the ability to refer to aliased names would simply facilitate reconfiguration (i.e., have clients connect to a GSSAPI-authenticated LDAP server ldap.brudenell.name, which may be an alias for anything at all). It also seems that the argument that relying on insecure (or incorrect, or "creatively administered") DNS for the integrity of the system is not a good idea. If not for reasons of security, then surely for reasons of having authentication at all _work_ in the face of reverse DNS being broken -- this is a link in the functionality chain which is broken all too often. In particular, I am trying to run a KDC (and other servers) from behind a NAT firewall on a dynamic-IP cable connection. This may seem silly, but so is using Linux. I have, of course, no control over whether my KDC's canonical name (w.r.t. the outside world, of course -- my internal network can be configured in any way at all) changes, even assuming the IP stays the same. It seems that the current philosophy has no answer for my configuration other than to create different service principal for every service running on every host, every time the IP changes, which is clearly unacceptable. Assuming there is a very good reason for host canonicalization to stay, does anyone have any advice for making my configuration work? I would wager that changing service principal lookup mechanisms in the already widely-deployed kerberos is hard and would upset people. Is there any chance, therefore, of making this a feature I can turn off, and forsake the security? Thanks in advance ... ~Steve ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
