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