Acceptor names

[Roland C. Dowdeswell]

On Fri, Jan 28, 2011 at 04:39:28PM -0500, ghudson at MIT.EDU wrote:
>

> Before I get into implementation design, I want to resolve these
> questions:
> 
> * The above changes have the effect of disregarding the profile
>   domain_realm map and the default realm in the acceptor.  Is that
>   okay?  Can people imagine cases where a keytab contains
>   service/hostname at REALM for multiple realms and it's important to
>   accept only a particular realm based on the domain_realm map?
> 
> * The new ignore_acceptor_hostname profile setting is a bludgeon to
>   make apps work even if they import service at gethostname() (like
>   unpatched SSH).  Unfortunately, admins will have to know about the
>   krb5 setting in order to avoid the usual canonicalization-related
>   failures setting up sshd.  Should we go further, at the risk of
>   damaging the security of (for example) hypothetical virtual hosting
>   apps?  Is it worth implementing the bludgeon at all if it has to be
>   off by default?

I have locally patched the MIT Kerberos libraries to have such a
bludgeon at my place of work and we find it quite valuble.  In
examples such as SSH, it is easy enough to simply modify the code
and recompile and so the bludgeon is not necessary.  However, when
we are integrating vendor products, we have no such option of just
modifying a few lines of code and recompiling because we do not
have the source code.  In this case, before we implemented the
bludgeon, we needed to formally submit a request to the vendor
which would then be reviewed by their product management team,
their relationship manager, maybe their sales engineer and finally
it might make it to their engineering team.  Conference calls were
required at each stage of the process, generally where little
progress was made.  The request was frequently denied.  And even
in the cases where the request was accepted, it was normally at
least six months before delivery of a patched application with the
desired behaviour.

Our implementation provides for both a krb5.conf setting and an
environment variable.  We actually use the environment variable
because we decided that we only wanted to enable the behaviour on
applications that require it and the environment variable turns
out to have significant advantages for that in our environment.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/