Re: [Broken test case] Cryptic error message, fallback handling issue

Stephane LAPIE <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Message-ID <[email protected]>
Thanks for the good practices, I'll admit I sorely lack in that. :)

I am actually already using a dedicated keytab for apache (because yes,
I am fully aware "host" and "HTTP" services are two different things,
and thus require different permissions, enforced by my deployment tools :)).

I am aware most of my woes stem from the non-removable requirement to
have stuff run from AD and a Windows environment, and the fact IE uses
the Windows Unified Authentication mechanism which is far more thorough
than other environments : i.e it will only accept authentication if the
hostname returned by an rDNS lookup matches the principal of the server,
and I wanted to eliminate unknowns.

I ended up forcing the SPN after wasting some time because the server
was advertising "HTTP/<ApacheServerName>" (which is apparently what you
get when using only "KrbServiceName HTTP", and ServerName is acquired
from rDNS of the local IP) which didn't reflect the vhost
"<ApplicationName>", and made authentication fail from IE when it found
out the URL didn't match the SPN.

This actually kind of brings the question : what is the best practice
with apache+vhosts and Kerberos ?

Should I just forget the idea altogether and go with
"http://webserver.domain/application/" instead of
"http://application.domain/" ?

It's really not that much of a problem but users tend to be vocal about
not having "application.domain" in their browser as the visible URL.

Thanks for your time.

On 01/12/2012 03:48 PM, Henry B. Hotz wrote:
> Not saying you're wrong, but my philosophy is that every network service should have its own keytab file, and you should put only that service's keys in the keytab file.  That's a much more fundamental, and secure, way to restrict what keys are used than a configuration parameter.
> 
> While mis-matches between the service principal name and the actual web server name are a concern, there may be more than one "correct" mapping.  The only way to support multiple names is to use "Any" and provide the correct set of entries in the keytab.
> 
> On Jan 11, 2012, at 6:06 PM, Stephane LAPIE wrote:
> 
>> Just making sure it will be using the proper keytab entry, as otherwise
>> Windows/IE "might" throw a fit over the Kerberos principal not being the
>> same as the entered URL.
>>
>> I basically coerce every access to be redirected to
>> http://application.domain/, at which stage I proceed with Kerberos
>> authentication.
>>
>> Also, given I generate & deploy my Apache configuration files, using the
>> application vhost name or Any is not a big change either way. It's just
>> I thought it would be "cleaner" to use key A for application A, and
>> ensure it can only ever be that way.
>>
>> So, no real specific reason, besides having clearly defined things
>> everywhere, which is especially important in a hybrid environment. :)
>>
>> On 01/12/2012 10:31 AM, Henry B. Hotz wrote:
>>> How about "Any"?  Is there an actual reason to restrict functionality that way?  (I'm not saying it ought to blow up of course.)
>>>
>>> On Dec 29, 2011, at 11:09 PM, Stephane LAPIE wrote:
>>>
>>>> -> KrbServiceName set as HTTP/[email protected] (to
>>>> ensure the queried URL matches the used SPN)
> 
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> [email protected], or [email protected]
> 
> 
> 


-- 
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo
signature.asc (application/pgp-signature, 262 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8Oi+kACgkQ24Ql8u6TF2MVigCgzOrzGRj7vO63utWrKGClIY3R
nPoAnjbjrZsxvxoi/oJMQH6OkBNj5M/t
=QnL+
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.