[130] in athena10
Re: Missing pieces in Athena 10
daemon@ATHENA.MIT.EDU (Nelson Elhage)
Wed Mar 19 12:11:18 2008
Date: Wed, 19 Mar 2008 12:10:31 -0400
From: Nelson Elhage <nelhage@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
Cc: Evan Broder <broder@mit.edu>, Timothy G Abbott <tabbott@mit.edu>,
athena10@mit.edu
Message-ID: <20080319161031.GE13267@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1205942638.5882.5.camel@error-messages.mit.edu>
They are resolving CNAME's; the problem isn't the lack of keytab for
$USERNAME.mail.mit.edu; the problem is that they resolve to
poNN.*mail*.mit.edu, and they only have keytabs for poNN.mit.edu
Compare the results of:
[nelhage@lunatique:~]$ hesinfo nelhage pobox
POP PO10.MIT.EDU nelhage
[nelhage@lunatique:~]$ host -t CNAME nelhage.mail.mit.edu
nelhage.mail.mit.edu is an alias for PO10.mail.mit.edu.
- Nelson
On Wed, Mar 19, 2008 at 12:03:58PM -0400, Greg Hudson wrote:
>
> On Wed, 2008-03-19 at 03:41 -0400, Evan Broder wrote:
> > If you're planning to actually push the username.mail.mit.edu in the
> > official Athena release, you should talk with Network. Currently, it's
> > not possible to do Kerberos authentication to username.mail.mit.edu,
> > because they're CNAMEs for poN.mail.mit.edu, and the servers only have
> > keytabs for poN.mit.edu.
>
> Huh, I can verify this in practice, but it's not what I would expect.
> Normally krb4 and krb5 libraries will resolve cnames before selecting a
> principal to use. I'm not sure why this is an exception, or whether it
> would be an exception for krb5 auth if we could do it.
>
> I doubt Network can do much about that; installing keytabs for every
> username.mail.mit.edu hostname would seem prohibitive.
>
>
