NFS4 + Kerberos with AD

Kevin Coffman kwc at citi.umich.edu
Thu May 15 11:18:46 EDT 2008


I see that librpcsecgss and libgssglue are not referenced here.

I think this needs to be taken up with the distro maintainers?

On Thu, May 15, 2008 at 9:27 AM, Grover, Justin N.
<Justin.Grover at ic.fbi.gov> wrote:
> Oh, and for 'ldd /usr/sbin/rpc.svcgssd', the following is listed:
>
> linux-gate.so.1 =>
> libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2
> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
> libkrb5.so.3 => /usr/lib/libkrb5.so.3
> libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
> libkrb5support.so.0 => /usr/lib/libkrb5support.so.0
> libcom_err.so.2 => /lib/libc.so.6
> libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2
> libnfsidmap.so.0 => /usr/lib/libnfsidmap.so.0
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6
> /lib/ld-linux.so.2
> libldap.so.2 => /usr/lib/libldap.so.2
> liblber.so.2 => /usr/lib/liblber.so.2
> libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1
> libsasl2.so.2 => /usr/lib/libsasl2
> libgnutls.so.12 => /usr/lib/libgnutls.so.12
> libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0
> libtasn1.so.2 => /usr/lib/libtasn1.so.2
> libz.so.1 => /usr/lib/libz.so.1
> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11
> libgpg-error.so.0 => /usr/lib/libgpg-error.so.0
> libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1
>
> ________________________________________
> From: kwcoffman at gmail.com [kwcoffman at gmail.com] On Behalf Of Kevin Coffman [kwc at citi.umich.edu]
> Sent: Wednesday, May 14, 2008 4:27 PM
> To: Grover, Justin N.
> Cc: J. Bruce Fields; nfsv4
> Subject: Re: NFS4 + Kerberos with AD
>
> Thanks Justin,
> I assume from your email address that is as much as you can share.  It
> appears that the size of the packet from the nfsclient to nfsserver is
> reasonable for a GSS token.  I'm assuming something is getting mixed
> up while sending that token up from the kernel to svcgssd.
>
> Back to the basics.  For the client and server machines:
>
> What kernel version and nfs-utils versions do you have?
> What Kerberos implementaion and version?
> What does "ldd /usr/sbin/rpc.svcgssd" on the server machine show?
>
> K.C.
>
> On Wed, May 14, 2008 at 3:46 PM, Grover, Justin N.
> <Justin.Grover at ic.fbi.gov> wrote:
>> I am now using DES-CBC-CRC, and still running into the same issue.  Figures... :-p
>>
>> I also did a packet trace using tcpdump, and will provide packet header information below (note MAC addresses / IPs are not actual):
>>
>> FROM nfsclient TO ActiveDirectory:
>> 15:05:00 00:11:22:aa:bb:cc, ethertype IPv4 (0x0800), length 1404: (tos 0x0, ttl 64, id 33187, offset 0, flags [DF], proto UDP (17), length 1390) 192.168.1.30.32782 > 192.168.1.200.88: [bad udp cksum c54e!]
>>
>> FROM ActiveDirectory TO nfsclient:
>> 15:05:00 00:11:22:66:77:ee > 00:11:22:aa:bb:cc, ethertype IPv4 (0x0800), length 1384: (tos 0x0, ttl 128, id 8296, offset 0, flags [none], proto UDP (17), length 1370) 192.168.1.200.88 > 192.168.1.30.32782: [udp sum ok]
>>
>> FROM nfsclient TO nfsserver:
>> 15:05:00 00:11:22:aa:bb:cc > 00:22:33:aa:cc:dd , ethertype IPv4 (0x0800), length 1418: (tos: 0x0, ttl 64, id 26804, offset 0, flags [DF], proto TCP (6), length 1404) 192.168.1.30.1193293888 > 192.168.1.100.2049: 1352 null
>>
>> FROM nfsserver TO nfsclient:
>> 15:05:00 00:22:33:aa:cc:dd, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.100.2049 > 192.168.1.30.0: reply ERR 0: RPC Version mismatch (167772160-0)
>>
>>
>> ________________________________________
>> From: kwcoffman at gmail.com [kwcoffman at gmail.com] On Behalf Of Kevin Coffman [kwc at citi.umich.edu]
>> Sent: Wednesday, May 14, 2008 9:42 AM
>> To: Grover, Justin N.
>> Cc: J. Bruce Fields; nfsv4
>> Subject: Re: NFS4 + Kerberos with AD
>>
>> On Tue, May 13, 2008 at 6:42 PM, J. Bruce Fields <bfields at fieldses.org> wrote:
>>> On Tue, May 13, 2008 at 05:35:32PM -0400, Grover, Justin N. wrote:
>>>  > I will try creating the keytabs with des-cbc-crc and report back with findings when I can...
>>>  >
>>>  > Also Kevin, is there a way to specify the svcgssd service to startup last in
>>>  > the nfs-kernel-server startup?  With the -vvvf option, when I do an
>>>  > /etc/init.d/nfs-kernel-server restart, the process hangs in the foreground
>>>  > when svcgssd starts (making it so mountd doesn't get started).
>>>  >
>>>
>>>  Just drop the "f" and it'll put itself in the background and log the
>>>  results as usual.
>>>
>>>  Or you can just kill the rpc.svcgssd that the init scripts started and
>>>  run your own with -vvvf and watch the output in the terminal.
>>
>> Yes, this is what I intended.  However, after looking at the code
>> again, newer versions of svcgssd will only log the token data when
>> running in the foreground in a terminal *and* when compiled with DEBUG
>> defined.
>>
>> Therefore, a packet trace showing the token being sent from the client
>> would be most helpful...
>>
>>
>
>


More information about the NFSv4 mailing list