Turbo Fredriksson <[EMAIL PROTECTED]> had sent:
...
> Just if it matters, I compared the keyfiles as well.
>
> ----- s n i p -----
> [EMAIL PROTECTED]:/usr/afs/etc# klist -k unixkeytab -t -K
> Keytab name: FILE:unixkeytab
> KVNO Timestamp Principal
> ---- -----------------
> --------------------------------------------------------
> 3 01/01/70 01:00:00 afs/<cell>@<REALM> (0xe9801968ba2aada4)
> [EMAIL PROTECTED]:/usr/afs/etc# klist -k keytab.file -t -K
> Keytab name: FILE:keytab.file
> KVNO Timestamp Principal
> ---- -----------------
> --------------------------------------------------------
> 3 01/09/07 11:14:13 afs/<cell>@<REALM> (0x83dab01c6bb03701)
> [EMAIL PROTECTED]:/usr/afs/etc#
> ----- s n i p -----
>
> They ARE different, but since neither work... ? Did I miss restarting
> something? I'we been waiting for more than the 'AD sync time' so it
> can't be that...
So the situation is you have 2 keytabs, and you don't
know which one is good. The timestamp is no good (it has no
functional significance to the software, and in this case
it isn't useful to you either.) The vno is the same, so we
know at least one of these files is for sure bogus.
Fortunately, it's easy to validate which keytab is good.
For instance, taking an afs keytab I happen to have just lying around:
spam% klist -kte /tmp/afs.kt
Keytab name: FILE:/tmp/afs.kt
KVNO Timestamp Principal
---- -----------------
--------------------------------------------------------
3 05/12/04 17:56:28 [EMAIL PROTECTED] (DES cbc mode with CRC-32)
spam% kinit -kt /tmp/afs.kt [EMAIL PROTECTED]
spam% klist -5fea
Ticket cache: FILE:/tmp/krb5cc_25131_a7CIlU
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
01/09/07 05:57:02 01/10/07 05:57:02 krbtgt/[EMAIL PROTECTED]
Flags: FPI, Etype (skey, tkt): Triple DES cbc mode with
HMAC/sha1, Triple DES cbc mode with HMAC/sha1
Addresses: (none)
spam%
If I can authenticate with the keytab, I've got one that should
also be capable of decrypting service ticket. So, let us first
get a service ticket.
spam% kvno -e des-cbc-crc [EMAIL PROTECTED]
[EMAIL PROTECTED]: kvno = 3
spam% klist -5fea
Ticket cache: FILE:/tmp/krb5cc_25131_a7CIlU
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
01/09/07 05:57:02 01/10/07 05:57:02 krbtgt/[EMAIL PROTECTED]
Flags: FPI, Etype (skey, tkt): Triple DES cbc mode with
HMAC/sha1, Triple DES cbc mode with HMAC/sha1
Addresses: (none)
01/09/07 06:03:11 01/10/07 05:57:02 [EMAIL PROTECTED]
Flags: FPT, Etype (skey, tkt): DES cbc mode with CRC-32, DES
cbc mode with CRC-32
Addresses: (none)
spam%
Now I have a service ticket. I can see that the kdc gave me kvno 3,
which is good, that's what I expect to see. I could just stop here.
But if I want to be really thorough and chase this to the end, I ought
to decrypt the ticket using the keytab. Unfortunately, there's no
handy kerberos utility that will just do that. Fortunately, there are
other ways. If we don't care about bullet-proofness, parsing a keytab can be
real trivial: for this simple case (one des-cbc-crc32 key) the last 8 bytes are
always going to be the key. The ticket file isn't so trivial, but stepping
backwards
from the end looking for the length and appl[3] tag is likely to be effective.
So here's a perl script that makes a few silly assumptions like this
to decrypt the last ticket in the k5 credentials cache using the last key in
the keytab file:
spam% perl /afs/umich.edu/user/m/d/mdw/bin/decst.pl /tmp/afs.kt
/tmp/krb5cc_25131_a7CIlU
Y4GLMIGIoAcDBQBQCAAAoRMwEaADAgEBoQoECB8CZyyD+BzvohAbDkRPR1MuVU1JQ0guRURVoxAw
DqADAgEBoQcwBRsDYWZzpAswCaADAgEBoQIEAKURGA8yMDA3MDEwOTEwNTcwMlqmERgPMjAwNzAx
MDkxMTAzMTFapxEYDzIwMDcwMTEwMTA1NzAyWg==
spam%
Did the decrypt work? Is this really valid? A real kerberos
server would know right here. The perl script isn't that smart.
But, if all went well, that output is the pem-encoded version of the
decrypted ticket. Conveniently, this is exactly what openssl likes to read:
spam% /afs/umich.edu/user/m/d/mdw/bin/decst.pl /tmp/afs.kt
/tmp/krb5cc_25131_a7CIlU | openssl asn1parse -dump -i
0:d=0 hl=3 l= 139 cons: appl [ 3 ]
3:d=1 hl=3 l= 136 cons: SEQUENCE
6:d=2 hl=2 l= 7 cons: cont [ 0 ]
8:d=3 hl=2 l= 5 prim: BIT STRING
0000 - 00 50 08 .P.
0005 - <SPACES/NULS>
15:d=2 hl=2 l= 19 cons: cont [ 1 ]
17:d=3 hl=2 l= 17 cons: SEQUENCE
19:d=4 hl=2 l= 3 cons: cont [ 0 ]
21:d=5 hl=2 l= 1 prim: INTEGER :01
24:d=4 hl=2 l= 10 cons: cont [ 1 ]
26:d=5 hl=2 l= 8 prim: OCTET STRING
0000 - 1f 02 67 2c 83 f8 1c ef- ..g,....
36:d=2 hl=2 l= 16 cons: cont [ 2 ]
38:d=3 hl=2 l= 14 prim: GENERALSTRING
0000 - 44 4f 47 53 2e 55 4d 49-43 48 2e 45 44 55
DOGS.UMICH.EDU
54:d=2 hl=2 l= 16 cons: cont [ 3 ]
56:d=3 hl=2 l= 14 cons: SEQUENCE
58:d=4 hl=2 l= 3 cons: cont [ 0 ]
60:d=5 hl=2 l= 1 prim: INTEGER :01
63:d=4 hl=2 l= 7 cons: cont [ 1 ]
65:d=5 hl=2 l= 5 cons: SEQUENCE
67:d=6 hl=2 l= 3 prim: GENERALSTRING
0000 - 61 66 73 afs
72:d=2 hl=2 l= 11 cons: cont [ 4 ]
74:d=3 hl=2 l= 9 cons: SEQUENCE
76:d=4 hl=2 l= 3 cons: cont [ 0 ]
78:d=5 hl=2 l= 1 prim: INTEGER :01
81:d=4 hl=2 l= 2 cons: cont [ 1 ]
83:d=5 hl=2 l= 0 prim: OCTET STRING
85:d=2 hl=2 l= 17 cons: cont [ 5 ]
87:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20070109105702Z
104:d=2 hl=2 l= 17 cons: cont [ 6 ]
106:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20070109110311Z
123:d=2 hl=2 l= 17 cons: cont [ 7 ]
125:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20070110105702Z
spam%
That's a perfectly good ticket, therefore, unless basic crypto
in the kdc is broken (seems unlikely), we have success.
Note; if the ticket we get here is over about 1400 bytes, it won't
work with afs. There's a trick for that, which other people here
can answer better than I.
...
-Marcus Watts
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
