Kerberized NFSv4 problems

[Erich Weiler]

Never mind, it worked!  The client just needed a reboot.  Thanks again 
for your help!

ciao, erich

Erich Weiler wrote:
> 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.ezproxyberklee.flo.org/mailman/listinfo/kerberos
>>>
>>>
>