[CentOS] Apache/Active Directory authentication
J.H.Hodrien at leeds.ac.uk
Sat Mar 19 08:28:46 UTC 2011
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
> 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
More information about the CentOS