[32210] in Kerberos
Re: CANT_FIND_CLIENT_KEY
daemon@ATHENA.MIT.EDU (Matt Zagrabelny)
Tue Mar 30 20:57:06 2010
From: Matt Zagrabelny <mzagrabe@d.umn.edu>
To: Russ Allbery <rra@stanford.edu>
In-Reply-To: <87wrwt8hto.fsf@windlord.stanford.edu>
Date: Tue, 30 Mar 2010 19:54:37 -0500
Message-ID: <1269996877.11234.43.camel@localhost.localdomain>
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
On Tue, 2010-03-30 at 17:18 -0700, Russ Allbery wrote:
> Matt Zagrabelny <mzagrabe@d.umn.edu> writes:
>
> > it looks like the mzagrabe principle is missing the:
>
> > Key: vno 1, DES cbc mode with CRC-32, no salt
>
> > How would I add that key to the principle?
>
> Change the password with an enctype setting that allows DES, basically.
> If you have something like:
>
> supported_enctypes = des3-cbc-sha1:normal des-cbc-crc:normal aes256-cts:normal
>
> or whatever list you want in your kdc.conf file and you restart kadmind,
> that should do it.
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
I mean, the switch cannot handle aes256-cts-hmac-sha1-96 (etype 18).
Does that matter?
Anyhow, thanks again.
Cheers,
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
