On Fri, 18 Mar 2011, Michael B Allen wrote:
Hi John, Actually I think this practice is now considered poor behavior. I look at a lot of packet captures and I don't recall seeing PTR lookups. At least not from Windows clients. Also I recall there was a discussion about this on the Kerberos list and the verdict from one of the MIT chaps was that it was actually not desirable to use PTR lookups.
And I think you've probably nailed my slightly blinkered view of all this. I'm too used to dealing with MIT kerberos linux clients interacting with a 2003/2008 windows AD domain. It'll be client requirements for the PTR records that I'm affected by, not anything that's part of the AD side.
True. You cannot have multiple PTR records for an IP. I did not mean to suggest that you could.
You can, but it's a bad idea.
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.
I think it's just in the multi-record case this becomes a bit grim, as your PTR record can only sanely return a single A record. Not that I guess that /really/ matters.
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.
I guess. But then in some ways it's only the same as if you'd changed your web servers and created a new subdomain to handle ssl request. Clients shouldn't get hung up on details.
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.
Sure, it's time fussy. But all in, large Active Directory domains tick along pretty well. Anything that encourages proper ntp usage is a good thing. It's the sort of thing the windows world seems somewhat well adapted to. Machine doesn't think you're a member of a group you've been recently added to? Log out and log back in again and it'll be fine...
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.
I see. I think my focus was more on getting the kerberos clients that are out there working as happily as possible with what we've got, so I've got a slightly different angle.
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.
Two A records, with PTR record pointing to the A record that didn't have a service principal defined. MIT client tries to use valid A record, MIT client rejects the connection as it can't get a service principal for the PTR directed A record. I'm not saying it *should* do this... In AD, the machine's only going to have service principals for the FQDN that matches the machine name it was joined to the domain with. Creating these additionaly service principals I think is something you can't trivially do without being a domain admin, or perhaps creating dummy machine records. If you're using AD for DNS as well, I think that could end up being a bit exciting. jh
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
