NFS4 + Kerberos with AD

Thu May 29 16:26:10 EDT 2008

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...
>> >>
>> >>
>> >
>> >
>
>