kerberized telnet
Matt Zagrabelny
mzagrabe at d.umn.edu
Fri Apr 2 15:58:02 EDT 2010
Thanks for the quick response Marcus, comments inline.
On Fri, 2010-04-02 at 15:07 -0400, Marcus Watts wrote:
> > Date: Fri, 02 Apr 2010 13:33:26 CDT
> > To: kerberos <kerberos at mit.edu>
> > From: Matt Zagrabelny <mzagrabe at d.umn.edu>
> > Subject: kerberized telnet
> >
> > Greetings,
> >
> > I am trying to debug a Kerberos setup with a MIT KDC/TGS and Cisco
> > Catalyst 3750. Things are progressing, but I've hit a wall.
> >
> > Here is what I perform on my workstation:
> >
> > $ kinit
> > $ telnet kplz354s2
> > Trying 10.25.1.14...
> > Will send login name and/or authentication information.
> > Connected to kplz354s2.d.umn.edu (10.25.1.14).
> > Escape character is '^]'.
> > [ Kerberos V5 accepts you as ``mzagrabe at D.UMN.EDU'' ]
> >
> > % Authentication failed
> > Connection closed by foreign host.
> ...
>
> The message "Kerberos V5 accepts" comes from your local telnet client.
> It means that at some basic level kerberos 5 negotiation succeeded with
> the telnet server.
>
> There's an "authdebug" option you can set.
> You can probably get more debug output using:
> $ telnet
> telnet> set authdebug
> telnet> open kplz354s2
> ...
telnet> set authdebug
auth debugging enabled
telnet> open kplz354s2
Trying 10.25.1.14...
Will send login name and/or authentication information.
Connected to kplz354s2.d.umn.edu (10.25.1.14).
Escape character is '^]'.
>>>TELNET: I support auth type 2 6
>>>TELNET: I support auth type 2 2
>>>TELNET: I support auth type 2 0
>>>TELNET: auth_send got: 02 02 02 00
>>>TELNET: He supports 2
>>>TELNET: Trying 2 2
telnet: calling krb5_sname_to_principal
telnet: done calling
krb5_sname_to_principal
>>>IS:0: [0] (448) 6e 82 01 bc 30 82 01 b8 a0 03 02 01 05 a1 03 02
telnet: Sent Kerberos V5 credentials to server
>>>TELNET: Using type 2
[ Kerberos V5 accepts you as ``mzagrabe at D.UMN.EDU'' ]
% Authentication failed
Connection closed by foreign host.
> use "set ?" to see what else you can do - there are additional debugging
> options. If you have something else for which you can successfully do
> kerberos authentication, you should compare the results.
>
> Off-hand, I wonder what encryption types you have. You might want to
> check encryption types in the kdc logs, & encryption types and flags on
> the various principals involved.
Apr 02 11:33:37 stout krb5kdc[27785](info): no valid preauth type found:
Success
Apr 02 11:33:37 stout krb5kdc[27785](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) 131.212.60.196: PREAUTH_FAILED: mzagrabe at D.UMN.EDU for
krbtgt/D.UMN.EDU at D.UMN.EDU, Preauthentication failed
Apr 02 11:33:37 stout krb5kdc[27785](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) 131.212.60.196: NEEDED_PREAUTH: mzagrabe at D.UMN.EDU for
krbtgt/D.UMN.EDU at D.UMN.EDU, Additional pre-authentication required
Apr 02 11:33:43 stout krb5kdc[27785](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) 131.212.60.196: ISSUE: authtime 1270226023, etypes {rep=1
tkt=18 ses=18}, mzagrabe at D.UMN.EDU for krbtgt/D.UMN.EDU at D.UMN.EDU
Apr 02 11:33:46 stout krb5kdc[27785](info): TGS_REQ (1 etypes {1})
131.212.60.196: ISSUE: authtime 1270226023, etypes {rep=18 tkt=1 ses=1},
mzagrabe at D.UMN.EDU for host/kplz354s2.d.umn.edu at D.UMN.EDU
kadmin.local: getprinc mzagrabe
Principal: mzagrabe at D.UMN.EDU
Expiration date: [never]
Last password change: Tue Mar 30 19:46:41 CDT 2010
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Fri Apr 02 11:15:21 CDT 2010 (root/admin at D.UMN.EDU)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 3, DES cbc mode with CRC-32, no salt
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local: getprinc host/kplz354s2.d.umn.edu at D.UMN.EDU
Principal: host/kplz354s2.d.umn.edu at D.UMN.EDU
Expiration date: [never]
Last password change: Wed Mar 31 14:06:07 CDT 2010
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Fri Apr 02 11:16:49 CDT 2010 (root/admin at D.UMN.EDU)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 3, DES cbc mode with CRC-32, no salt
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
> klist -fea may also be interesting.
$ klist -fea
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: mzagrabe at D.UMN.EDU
Valid starting Expires Service principal
04/02/10 11:33:43 04/02/10 21:33:43 krbtgt/D.UMN.EDU at D.UMN.EDU
renew until 04/03/10 11:33:37, Flags: FPRIA
Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC,
AES-256 CTS mode with 96-bit SHA-1 HMAC
Addresses: (none)
04/02/10 11:33:46 04/02/10 21:33:43 host/kplz354s2.d.umn.edu at D.UMN.EDU
renew until 04/03/10 11:33:37, Flags: FPRAT
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
CRC-32
Addresses: (none)
> If the string you rightfully didn't show us is really a srvtab, the
> service principal you gave to the cisco must not have any non-des key
> types in the kdc.
Why do you say that? (ie. I'm not following this last statement)
--
Matt Zagrabelny - mzagrabe at d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF C899 07E2 BFA8 42A0 0942
He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20100402/18d84a81/attachment.bin
More information about the Kerberos
mailing list