On Fri, 18 Mar 2011, Michael B Allen wrote: > Hi John, > > Arguably it's not the end-of-the-world to go though CNAMEs. If it > works for you, then don't let me deter you. Indeed it does, and it was the only way I could see you /could/ do this. Especially if you're not a domain admin. I'm still not clear your method /can/ work. Are you saying you've done it this way and it does? With multiple A records if I do: ssh 10.0.0.1 Which kerberos credential will the remote side use? With the CNAME approach, there's no ambiguity. > But you do realize that it requires the client to have logic to see > "ah, the record returned is a CNAME so let's use this name to build > the principal instead"? MIT kerberos suggests it uses this to figure out the SPN: gethostbyaddr(gethostbyname(host)) Surely that wouldn't care how I'd done it? That requires the PTR record, and that it points back to the name of the pricipal you want to use. With multiple PTR records to the same IP I can't work out how this is going to end. Will it round-robin and simply work because the remote end has all of them? Clearly sometimes there's not even a domain name to start with. You can quite merrily do "ssh 10.0.0.1" and get a kerberised login. With multiple PTRs to a single IP, I can only assume you'll round-robin through the credentials. So when you add an A and PTR record and forget to add the principal, kerberos logins will fail 1/N of the time. > And I would not be surprised to see some scenario where the client actually > tried to get a ticket with the supplied name and than fell-back to using the > CNAME in which case you have extra DNS and Kerberos traffic. If at some > point someone wants to use another HTTP client from a cron job or some Java > app, is that client going to handle the CNAME correctly? As far as I can tell, the client will be blissfully unaware. > What happends if the client application needs the original princpal > name for some reason? It will get what the CNAME points to. That could > be weird for the app or a developer. And then if you move the website > to another server the principal name is now suddenly different? Yes. But why would the developer care about the service principal name? It's not often you're that introspective, you're normally more interested in the client's principal. > CNAMEs in general are dubious. And not just for Kerberos. I think that's a little harsh. CNAMEs seem to be unloved for reasons I'm not fully convinced by. What is so bad about CNAMEs? > Also short names are dubios. Is it a NetBIOS name or does the client > have a proper DNS search suffix configured? And in the later case it > takes extra DNS queries to get the name. AD always creates both short and FQDN forms of principals, I assume it's as you guessed because of a NetBIOSism, or because it's a cruft that can often fix broken setups. I don't know, I only ever use the FQDN form. > Why have all this extra indirection on top of an already fickle protocol? I haven't actually found kerberos to be too fickle at all. > Regarding PTR records, I don't think kerberos would have any problem > without them. As far as I knew MIT kerberos doesn't work at all without them, due to the way it calculates service principals. Certainly if you have a pair of A records for the same IP, and the PTR record points to the name that doesn't match the service principal it all will not work. > Actually I seem to recall that once upon a time old Kerberos clients used to > automatically try PTR lookups to get the primary hostname first but that > practice has long since been ruled bad and clients no longer do it. That > might be what you're thinking of. AD 2003 doesn't work correctly if the PTR record doesn't match the service principal, even if there's also an A record that does. As far as I'm aware the same is true for MIT kerberos. > If you're going to have user's trying to use a site with a certain > hostname, IMO you should just have a proper A and PTR records. Yeah, > it can work without. But not always and it can be a burden for users > to figure out the problem and for admins to add the necessary SPN, A > and PTR records, get rid of the CNAME, wait for the cache to clear, > purge all the old tickets, etc. But are you suggesting multiple PTR records for the same IP? That's normally considered bad DNS practice isn't it, never mind kerberos practice? I'm just not sure I see any advantage in using multiple A and PTR records. Thanks for the discussion though, it's really not something I'd overly thought about before. There never seems to be enough googlable advice on using kerberos out there. jh