Kerberized NFSv4 problems

Erich Weiler weiler at soe.ucsc.edu
Mon Jun 19 14:41:54 EDT 2006


Hi Kevin,

Aha, I think, if I'm reading this correctly, the version numbers are 
defintely off:

(on KDC)
% klist -e -k -t /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- 
--------------------------------------------------------
    5 05/08/06 10:04:34 nfs/nfsserver at MYREALM.COM (DES cbc mode with CRC-32)

(through kadmin on Solaris client)
kadmin: getprinc nfs/solarisclient.domain.com
Principal: nfs/solarisclient.domain.com at MYREALM.COM
Expiration date: [never]
Last password change: Mon Jun 19 09:32:41 PDT 2006
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Mon Jun 19 09:32:41 PDT 2006 (admin/admin at MYREALM.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 16, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

So it looks like the KDC has KVNO version 5, and the solarisclient has 
KVNO version 16?  Am I reading that right?  And if yes, what can I do to 
fix it?  (I hope there is something, anything, that I can do...  :).

ciao, erich

Kevin Coffman wrote:
> Hi Erich,
> How did you create the keytab for the NFS server?  The key version
> number in that keytab must match the key version number for the server
> principal in the KDC.
> 
> The key version displayed for nfs/fedoraserver.domain.com at REALM with
> "klist -e -k -t /etc/krb5.keytab" should match the key version
> displayed by getprinc for the same principal within kadmin.
> 
> K.C.
> 
> 
> On 6/19/06, Erich Weiler <weiler at soe.ucsc.edu> wrote:
>> Greetings all,
>>
>> We're having some problems getting kerberized NFSv4 working in our
>> environment, was hoping someone would have an idea or two of what's
>> going on.  We've set up our KDC (Fedora Core 5 box) and it's working
>> great, people are logging in and getting tickets, all is well there.
>>
>> What I'm trying to do mount an NFSv4 krb5 shared mount, with sec=krb5,
>> on a Solaris box.  NFS server is the KDC (fedora).  Through kadmin on
>> the Solaris client, I did a:
>>
>> kadmin: ktadd -e des-cbc-crc:normal host/solarisclient.domain.com
>> kadmin: ktadd -e des-cbc-crc:normal nfs/solarisclient.domain.com
>>
>> to create my keytab file on the client.  When I try:
>>
>> % mount -F nfs -o sec=krb5 -o vers=4 nfsserver:/ /mnt
>>
>> It just hangs and the logs on the KDC/nfsserver show:
>>
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: leaving poll
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: handling null request
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: in_handle:
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: length 0
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: in_tok:
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: length 509
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0000: 6082 01f9 0609 2a86
>> 4886 f712 0102 0201  `.....*.H.......
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0010: 006e 8201 e830 8201
>> e4a0 0302 0105 a103  .n...0..........
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0020: 0201 0ea2 0703 0500
>> 2000 0000 a382 010c  ........ .......
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0030: 6182 0108 3082 0104
>> a003 0201 05a1 0e1b  a...0...........
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0040: 0c53 4f45 2e55 4353
>> 432e 4544 55a2 2730  .MYREALM.COM.'0
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0050: 25a0 0302 0103 a11e
>> 301c 1b03 6e66 731b  %.......0...nfs.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0060: 156d 6f6e 6974 6f72
>> 322e 6373 652e 7563  .nfsserver.domain.com
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0080: 01a1 0302 010b a281
>> b304 81b0 176e 5795  .............nW.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0090: 05cf 4963 45ce 8bdc
>> 0dc7 d398 1b8e cd28  ..IcE..........(
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   00a0: 9d83 9650 ca61 9c9e
>> e94a 12b6 165f 127d  ...P.a...J..._.}
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   00b0: 7da2 251b 20c1 514a
>> c918 1eb2 2b75 ae81  }.%. .QJ....+u..
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   00c0: 5544 928c 9304 f4bb
>> e4cc 29c1 04a1 2192  UD........)...!.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   00d0: 16cb d482 4029 c30a
>> b6f8 7c94 fa54 e379  ....@)....|..T.y
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   00e0: 0845 4d3c cfc7 7399
>> 9999 64b4 6f91 f301  .EM<..s...d.o...
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   00f0: 0102 3d9b 4a2e 57f5
>> c8d8 1260 4fe0 89ad  ..=.J.W....`O...
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0100: c00e e15f 5d8a 3e8f
>> 27c0 73d7 789c 4a10  ..._].>.'.s.x.J.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0110: 342e ef99 6f3a 77fb
>> a70c 7181 2604 435a  4...o:w...q.&.CZ
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0120: d190 c139 cdad f83b
>> 15c8 308e 69bc bae2  ...9...;..0.i...
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0130: d825 6f21 9b47 d4e1
>> 294c b0b5 a481 be30  .%o!.G..)L.....0
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0140: 81bb a003 0201 01a2
>> 81b3 0481 b021 a524  .............!.$
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0150: a4cc 502b d06e 1128
>> 2a94 0353 d150 1a20  ..P+.n.(*..S.P.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0160: bccf c86a 9970 d14a
>> e4a4 c709 d149 f729  ...j.p.J.....I.)
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0170: 4b1c 0397 5781 f52e
>> b0d5 0a4b 6428 5051  K...W......Kd(PQ
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0180: 9f9e 091c b922 28d8
>> 5f35 4cd8 88c4 7303  ....."(._5L...s.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   0190: 8ff3 4421 a4fb 74a5
>> 4e66 7ff2 e991 6eaf  ..D!..t.Nf....n.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   01a0: e287 e3d8 355b 38e3
>> aa50 1f43 e6f3 4117  ....5[8..P.C..A.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   01b0: 18fc 9a1f 0751 5391
>> 5875 13e1 2a7e aab9  .....QS.Xu..*~..
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   01c0: f23d 7b8b ed3b edf7
>> ae97 99d7 219a 62da  .={..;......!.b.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   01d0: a438 6a22 aafb 4790
>> 625e ba8c 05a4 9da6  .8j"..G.b^......
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   01e0: c06d 4997 192e c19c
>> 9877 00ab dd33 7a9f  .mI......w...3z.
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:   01f0: f2fa 9cb2 b348 547e
>> 0d80 8ccd f5         .....HT~.....
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: WARNING:
>> gss_accept_sec_context failed
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: ERROR: GSS-API: error in
>> handle_nullreq: gss_accept_sec_context(): Miscellaneous failure - Key
>> version number for principal in key table is incorrect
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: sending null reply
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]:
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: WARNING: failed to write
>> message
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: finished handling null 
>> request
>> Jun 19 10:19:15 nfsserver rpc.svcgssd[1433]: entering poll
>>
>>
>> I'm not sure how to "match" the version number in the principal key
>> table...  Or maybe that's not even my main issue?  Anyone have any clues?
>>
>> Thanks a million in advance!
>>
>> ciao, erich
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>

-- 
===================================
Erich Weiler
UNIX Systems Administrator
School of Engineering
University of California Santa Cruz
weiler at soe.ucsc.edu
===================================



More information about the Kerberos mailing list