NFS4 + Kerberos with AD

Thu May 29 16:38:17 EDT 2008

BTW, I just wanted to point out that this is not the same error as
before.  The error before was:

nfsserver rpc.svcgssd[3320]: ERROR: GSS-API: error in handle_nullreq:
gss_accept_sec_context(): A token was invalid - Token header is
malformed or corrupt

After you get this working with your built binaries, I'd like to
verify whether or not the original svcgssd works.

K.C.

On Thu, May 29, 2008 at 4:26 PM, Kevin Coffman <kwc at citi.umich.edu> wrote:
> The client should be trying to talk to
> 'nfs/nfsserver.example.com at EXAMPLE.COM'.  GSS-API knows nothing about
> realms -- the realm for Kerberos is assumed (determined via the
> hostname and the mappings in krb5.conf) -- therefore the gss request
> is for <service>@<hostname>.  So the client should be trying to talk
> to 'nfs at nfsserver.example.com'.  The server should have a keytab entry
> for 'nfs/nfsserver.example.com at EXAMPLE.COM'.
>
> On Thu, May 29, 2008 at 3:57 PM, Grover, Justin N.
> <Justin.Grover at ic.fbi.gov> wrote:
>> Alright, nfs server starts up just fine now, thank you Bruce/Kevin.
>>
>> Still running into the same problem as before though :\
>>
>> With the newest version of nfs-utils, I am still running into the same error message
>> (permission denied by server) on the client, though now we have the added benefit
>> of seeing the debug messages on the server side with the -rrrr option.
>>
>> Here are some relevant logs (with the server side included this time):
>>
>> rpc.gssd[6631]: [token displayed] [length 1281]
>> rpc.gssd[6631]: xdr_rpc_gss_buf: encode success
>> rpc.gssd[6631]: xdr_rpc_gss_init_args: encode success
>> rpc.svcgssd[6764]: leaving poll
>> rpc.svcgssd[6764]: handling null request
>> rpc.svcgssd[6764]: WARNING gss_accept_sec_context failed
>> rpc.svcgssd[6764]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context():
>>  Unspecified GSS failure.  Minor code may provide more information - Key table entry not found
>> rpc.svcgssd[6764]: writing message: \x \x[many hex digits]
>> rpc.gssd[6631]: in authgss_validate()
>> rpc.gssd[6631]: in authgss_unwrap()
>> rpc.gssd[6631]: xdr_rpc_gss_buf: decode success ((nil):0)
>> rpc.gssd[6631]: xdr_rpc_gss_buf: decode success ((nil):0)
>> rpc.gssd[6631]: WARNING: Failed to create krb5 context for user with uid 0 ....
>> rpc.svcgssd[6764]: finished handling null request
>> rpc.svcgssd[6764]: entering poll
>>
>>
>> Still think the problem is with the nfs server?  Or could the problem be elsewhere?
>>
>> One thing I noticed in the token sent to the nfsserver is that the principal name is the one from the original keytab file--not the mapped AD username.
>>
>> Like when you create the keytab file, you say ktpass -princ nfs/fqdn at REALM -mapuser nfsuser ...
>>
>> Shouldn't the token be 'nfsuser at nfsserver.example.com' instead of 'nfs at nfsserver.example.com'?
>>
>> Just a thought anyway...
>>
>> -Justin
>>
>> -----Original Message-----
>> From: J. Bruce Fields [mailto:bfields at fieldses.org]
>> Sent: Wednesday, May 28, 2008 2:39 PM
>> To: Kevin Coffman
>> Cc: Grover, Justin N.; nfsv4
>> Subject: Re: NFS4 + Kerberos with AD
>>
>> On Wed, May 28, 2008 at 02:36:39PM -0400, Kevin Coffman wrote:
>>> The server itself runs in the kernel.  I'm not sure exactly what the
>>> ubuntu script starts.  I'm assuming it starts rpc.svcgssd, rpc.idmapd,
>>> and maybe other things.  As long as you built and installed the
>>> nfs-utils pieces in the normal ubuntu location (/usr/sbin/rpc.* by
>>> default), that script should still be usable (AFAIK).
>>
>> Yup.  Looks like there's also a variable you could set at the top of
>> /etc/init.d/nfs-kernel-server:
>>
>>        ...
>>        #DESC="NFS kernel daemon"
>>        PREFIX=/usr
>>
>> So you could change that to /usr/local/ or whatever, depending on where
>> you installed the locally-built stuff.
>>
>> --b.
>>
>>>
>>> On Wed, May 28, 2008 at 11:21 AM, Grover, Justin N.
>>> <Justin.Grover at ic.fbi.gov> wrote:
>>> > Kevin & all,
>>> >
>>> > Assuming that something was forgotten out of the ubuntu package I was using, I decided to attempt installing the nfs server from source.
>>> >
>>> > I grabbed the latest versions of nfs-utils (1.1.2) and was able to successfully run:
>>> >
>>> > ./configure
>>> > make
>>> > make install
>>> >
>>> > Under the comfort of ubuntu packaging before, I was able to start the server by using /etc/init.d/nfs-kernel-server start.  Now that I've installed from source pkg, I'm a bit unsure of how to start the service.  Any help on how to do this would be appreciated!
>>> >
>>> > Justin
>>> >
>>> >
>>> > ________________________________________
>>> > 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...
>>> >>
>>> >>
>>> >
>>> >
>>
>>
>