On Fri, Mar 18, 2011 at 2:36 PM, Michael B Allen <ioplex at gmail.com> wrote: > On Fri, Mar 18, 2011 at 6:25 AM, John Hodrien <J.H.Hodrien at leeds.ac.uk> wrote: >> 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? > > True. You cannot have multiple PTR records for an IP. I did not mean > to suggest that you could. You *shouldn't*. But there's nothing in Bind or ther other common DNS architectures that enforces this practice, and I'm afraid that it's quite common for poorly configured systems that support dynamic DNS to permit this. It's why I give admins of Active Directory based systems such a hard time and try to insist that they allow me at least one location that I can do actual zone transfers, to detect multiple PTR's for one IP address, or the same hostname having multiple PTR's that point to it. The old "mkrdns" tool used to be fabulous for detecting, configuring, and correctly handling multiple A records and notifying you of their existence: I still appreciate its simplicity and robustness. Nico Kadel-Garcia <nkadel at gmail.com> > >> 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. > > Well you should not use an IP at all really because IPs change. But if > the client is remotely sophisticated it should be able to do a PTR > lookup and try that name. > >> >>> 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. > > For very simple scenarios you probably would not care. But here could > be numerous reasons for wanting to know the name of the service you're > talking to. > >>> 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. > > Kerberos requires that clients have access to the KDC, it depends > heavily on DNS, stale tickets can cause cryptic errors until clients > purge credential caches, etc. It's a great protocol conceptually. But > in practice it's not super robust. It can be difficult to track down > the source of issues. We had a customer who couldn't figure a Kerberos > issue for days. They had checked the time on the machine and thought > it was correct but it was actually off by exactly 12 hours. Meaning it > was set to like 2:43 AM when it was really 2:43 PM. > >>> 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. > > My business is all about integrating non-Windows systems into WIndows > environments so I don't look at what MIT is doing much. Windows > clients do not use PTR lookups to build SPNs so our code does not > either. > >>> 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. > > An HTTP client can authenticate with any principal in the service > keytab and only one of their hostnames is going to have a PTR record. > So I'm not sure I understand your claim here. > >> >>> 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. > > True. True. I didn't mean to suggest that you have multiple PTR > records for the same IP. Actually it's impossible because the record > key is like "10.1.168.192.in-addr.arpa" so obviously there can be only > one. > > Mike > > -- > Michael B Allen > Java Active Directory Integration > http://www.ioplex.com/ > >> 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 >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >