[32211] in Kerberos
Re: CANT_FIND_CLIENT_KEY
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Mar 30 21:04:06 2010
From: Russ Allbery <rra@stanford.edu>
To: Matt Zagrabelny <mzagrabe@d.umn.edu>
In-Reply-To: <1269996877.11234.43.camel@localhost.localdomain> (Matt
Zagrabelny's message of "Tue, 30 Mar 2010 19:54:37 -0500")
Date: Tue, 30 Mar 2010 18:04:01 -0700
Message-ID: <87hbnx9u9q.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Matt Zagrabelny <mzagrabe@d.umn.edu> writes:
> Thanks again, Russ. Still not getting logged in to the switch, but
> things are looking closer. I don't have console access to the switch
> right now, so I do not see the current error, but the logs from the KDC
> look better:
> Mar 30 19:48:07 stout krb5kdc[27785](info): AS_REQ (1 etypes {1})
> 10.25.1.14: ISSUE: authtime 1269996487, etypes {rep=1 tkt=18 ses=1},
> mzagrabe@D.UMN.EDU for krbtgt/D.UMN.EDU@D.UMN.EDU
> Is it normal to have such drastic different types of encryption for the
> various parts?
> rep=1
> tkt=18
> ses=1
Yes, nothing should care about the ticket enctype except the KDC.
> I mean, the switch cannot handle aes256-cts-hmac-sha1-96 (etype 18).
> Does that matter?
It shouldn't. It would only if the switch's implementation of Kerberos is
completely broken. (Although that's happened before in very old versions
of Java, IIRC.)
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
