Unable to mount kerberized NFS share on Linux from FreeBSD 10.1 box

[Sascha Frey]

Hi list,

I'm trying to set up a NFS file server for our Linux clients using
FreeBSD 10.1.

Mounting the NFS filesystem exported from the FreeBSD box works well
if using sec=sys, but doesn't work with sec=krb5.

I get 'access denied' on the Linux client (tried both Debian Jessie and
Ubuntu 14.04):

root@penny:~# mount -t nfs -o vers=4,sec=krb5 leonard.fs.cit-ec.net:/export/homes/sfrey /mnt
mount.nfs: access denied by server while mounting leonard.fs.cit-ec.net:/export/homes/sfrey
root@penny:~# mount -t nfs -o vers=3,sec=krb5 leonard.fs.cit-ec.net:/export/homes/sfrey /mnt
mount.nfs: access denied by server while mounting leonard.fs.cit-ec.net:/export/homes/sfrey

Mounting kerberized NFS mounts from our other (Linux based) file servers
is possible without having any problems.

Connectivity to the KDC seems to be OK:
[root@leonard ~]# kinit -k nfs/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE
[root@leonard ~]# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: nfs/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE

Issued Expires Principal
Feb 9 17:51:58 2015 Feb 10 03:51:59 2015 krbtgt/TECHFAK.UNI-...@TECHFAK.UNI-BIELEFELD.DE

I found only one error message in /var/log/messages:
nfsd: can't register svc name


Any idea what may be wrong?





Cheers,
Sascha



The configuration files on the server:

/etc/exports:
V4: / -sec=sys:krb5:krb5i:krb5p
/export/homes/sfrey -sec=sys:krb5 penny.fs.cit-ec.net

/etc/rc.conf:
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfs_server_flags="-u -t -n 6"
nfsuserd_enable="YES"
nfsuserd_flags="-domain TechFak.Uni-Bielefeld.DE"
mountd_enable="YES"
mountd_flags="-r"
gssd_enable="YES"
gssd_flags="-v"

/etc/krb5.conf:
[libdefaults]
default_keytab_name = /etc/krb5.keytab
default_realm = TECHFAK.UNI-BIELEFELD.DE
allow_weak_crypto = true

[realms]
TECHFAK.UNI-BIELEFELD.DE = {
default_domain = techfak.uni-bielefeld.de
}

[domain_realm]
.techfak.uni-bielefeld.de = TECHFAK.UNI-BIELEFELD.DE
techfak.uni-bielefeld.de = TECHFAK.UNI-BIELEFELD.D


/etc/krb5.keytab:
[root@leonard ~]# ktutil list
/etc/krb5.keytab:

Vno Type Principal Aliases
2 des-cbc-crc nfs/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE
2 des3-cbc-sha1 nfs/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE
2 des-cbc-crc host/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE
2 des3-cbc-sha1 host/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE
2 des-cbc-crc root/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE
2 des3-cbc-sha1 root/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE

_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-...@freebsd.org"

[Rick Macklem]

Well, this message indicates it isn't going to work.
(This message means the nfsd couldn't register with the gssd daemon,
so kerberized NFS won't work.) It is generated when the nfsd is
started.

The most common cause would be the gssd daemon not running when the
nfsd daemon is started. If the gssd was running when the nfsd was started
and this message is logged, there is a debug option on gssd that makes
it chatty and that might indicate why it is failing.

Also, there is this wiki. It is somewhat out of date, but I don't think
anything has changed w.r.t. the server side. (I'm not sure what the
current status is w.r.t. keytab entries encrypted in newer ways than
des-cbc-crc is.)
https://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup

Good luck with it, rick

[Rick Macklem]

> Any idea what may be wrong?
>

Oh, and a couple more things...
FreeBSD only supports RPCSEC_GSS_VERSION1. This should be sufficient,
since it is what is required by the NFSv4 RFC. However, I wouldn't be
surprised if recent Linux clients decide it isn't good enough for them.
(Hopefully if this is the case, there is a way to tell Linux to use
version 1.)

If none of the suggestions helps, I'd suggest you capture packets via
something like:
# tcpdump -s 0 -w krbmnt.pcap host <client-host>
running while a mount attempt is done.

You can then look at krbmnt.pcap in wireshark to see what is going
on the wire.

Also, take a look at your KDC logs. That might indicate a problem
with encryption type used or similar.

It has been tested against Linux and Solaris clients, but not for a
couple of years.

Again, good luck with it, rick

[Sascha Frey]

Rick Macklem wrote:

[...]

>> I found only one error message in /var/log/messages:
>> nfsd: can't register svc name
>>

>Well, this message indicates it isn't going to work.
>(This message means the nfsd couldn't register with the gssd daemon,
> so kerberized NFS won't work.) It is generated when the nfsd is
>started.
>
>The most common cause would be the gssd daemon not running when the
>nfsd daemon is started. If the gssd was running when the nfsd was started
>and this message is logged, there is a debug option on gssd that makes
>it chatty and that might indicate why it is failing.

gssd was running before nfsd was started.
This message does not appear if nfsd starts without gssd running,
but it does appear as soon as gssd is started (if nfsd is already running).

I started gssd in foreground mode (via gssd -d -v)
These messages appear when I start nfsd:
gssd_import_name: done major=0x0 minor=0
gssd_acquire_cred: done major=0x70000 minor=0
gssd_release_name: done major=0x0 minor=0
gssd_import_name: done major=0x0 minor=0
gssd_acquire_cred: done major=0x70000 minor=0
gssd_release_name: done major=0x0 minor=0
gssd_import_name: done major=0x0 minor=0
gssd_acquire_cred: done major=0x70000 minor=0
gssd_release_name: done major=0x0 minor=0

No log output when trying to mount NFS share on the Linux machine.


I tried to mount it on the server itself. I'm able
to mount, but I can't access any files...

[root@leonard ~]# mount -o sec=krb5 leonard.fs.cit-ec.net:/export/homes/sfrey /mnt
[root@leonard ~]# su - sfrey
[sfrey@leonard ~]$ kinit
sf...@TECHFAK.UNI-BIELEFELD.DE's Password:
[sfrey@leonard ~]$ ls -lad /mnt
ls: /mnt: Permission denied
[sfrey@leonard ~]$ klist
Credentials cache: FILE:/tmp/krb5cc_21036
Principal: sf...@TECHFAK.UNI-BIELEFELD.DE

Issued Expires Principal
Feb 10 08:54:31 2015 Feb 10 18:54:39 2015 krbtgt/TECHFAK.UNI-...@TECHFAK.UNI-BIELEFELD.DE
Feb 10 08:54:36 2015 Feb 10 18:54:39 2015 nfs/leonard.fs...@TECHFAK.UNI-BIELEFELD.DE

>
>Also, there is this wiki. It is somewhat out of date, but I don't think
>anything has changed w.r.t. the server side. (I'm not sure what the
>current status is w.r.t. keytab entries encrypted in newer ways than
>des-cbc-crc is.)
>https://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup

I'll take a look into it. Maybe I missed something.




Cheers,
Sascha

[Benjamin Kaduk]

0x70000 is GSS_S_NO_CRED.

Maybe you could truss or similar to find out what name it's trying to
acquire credentials for?

-Ben

[Rick Macklem]

Yea, unfortunately I think you'll find that this is the
catch-all when you dig into the Heimdal library. (All the
gssd does is take the upcalled arguments and do the call
against the library. This is the reply the gss_acquire_cred()
library call made. Why isn't it working? I have no idea.
It is strange that "kinit -k ..." works, but this does not.

One thing to check is to see if the keytab entry has multiple
encryption types in it. If it does, you might want to re-create
the keytab entry with only the default encryption type (as set
in the NFS server's /etc/krb.conf). I have seen problems when
the keytab entry has multiple encryption types, but I'm not sure
what was broken.

Another simple thing to check is "# hostname" and make sure it has
"leonard.fs.cit-ec.net" and not "leonard", since it will use
nfs@<hostname> as the host-based name and the <hostname> must
be the fully qualified domain name.

> Maybe you could truss or similar to find out what name it's trying to
> acquire credentials for?
>

It should be n...@leonard.fs.cit-ec.net (or nfs/leonard.fs.cit-ec.net@<default-realm>
if written in the Kerberos mechanism's way).

However, it can't hurt to check and if it isn't the above, that
would explain why it isn't working.

> -Ben
>
> > No log output when trying to mount NFS share on the Linux machine.
> >
> >
> > I tried to mount it on the server itself. I'm able
> > to mount, but I can't access any files...
> >
> > [root@leonard ~]# mount -o sec=krb5
> > leonard.fs.cit-ec.net:/export/homes/sfrey /mnt
> > [root@leonard ~]# su - sfrey
> > [sfrey@leonard ~]$ kinit
> > sf...@TECHFAK.UNI-BIELEFELD.DE's Password:
> > [sfrey@leonard ~]$ ls -lad /mnt
> > ls: /mnt: Permission denied

Yea, the FreeBSD client (I didn't choose to code it this way) falls
back to AUTH_SYS when Kerberos doesn't work. I suspect if you looked
at a packet trace in wireshark, you'd see it trying AUTH_SYS for this.

rick