On Fri, Mar 18, 2011 at 2:36 PM, Michael B Allen ioplex@gmail.com wrote:
On Fri, Mar 18, 2011 at 6:25 AM, John Hodrien J.H.Hodrien@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos