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

"Henry B. Hotz" <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Message-ID <[email protected]>
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]
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.