[CentOS] Apache/Active Directory authentication

John Hodrien 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
/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


More information about the CentOS mailing list