[31862] in Kerberos
Re: Wrong principal in request
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Tue Jan 5 10:19:49 2010
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Message-ID: <4B435884.7030007@secure-endpoints.com>
Date: Tue, 05 Jan 2010 10:19:32 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <87eim5z5ry.fsf@windlord.stanford.edu>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1488453533=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============1488453533==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms050006050006060209020502"
This is a cryptographically signed message in MIME format.
--------------ms050006050006060209020502
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 1/4/2010 8:42 PM, Russ Allbery wrote:
> Jeff Blaine <jblaine@kickflop.net> writes:
>
>> I happened to notice this (note the missing realm) after a
>> failed GSSAPI attempt to the SSH server (mega):
>
>> [root@mega ~]# klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: jblaine@FOO
>
>> Valid starting Expires Service principal
>> 01/04/10 16:14:51 01/11/10 16:14:51 krbtgt/FOO@FOO
>> renew until 01/18/10 16:14:51
>> 01/04/10 16:15:08 01/11/10 16:14:51 host/mega@
>> renew until 01/18/10 16:14:51
>
> Ah, that means that the client doesn't know what the local realm is and=
is
> therefore trying to ask the server via referrals, but the server isn't
> answering that question.
Unfortunately this is not a correct interpretation of what is happening.
The host/mega@ does indicate that referrals are being used. However,
when referrals are in use the client application has no idea what the
realm should be and so the resulting ticket is stored without the realm
in the name. This was done in order to ensure that the service ticket
could be found in the cache the next time an application seeks a service
ticket for such a service principal via referrals (which is represented
by specifying the NUL realm name.)
What may be going on for the version of Putty that you are using is that
it is calling krb5_get_host_realm in order to try to obtain the realm
name for the server up front. If there is no host to realm mapping in
the krb5 profile then this function will always return the NUL realm
name indicating that referrals will be used. Specifying the host to
realm mapping in the krb5 profile results in the referrals logic being
disabled.
Jeffrey Altman
--------------ms050006050006060209020502--
--===============1488453533==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1488453533==--
