fbsd8_stable nfsv3 sys=krb5 issue [resolved]
George Mamalakis
mamalos at eng.auth.gr
Fri Sep 17 08:49:23 UTC 2010
On 16/09/2010 16:44, George Mamalakis wrote:
> Hi all,
>
> I re-decided to move my nfs server from solaris to fbsd. So I am using
> test machines to see if it works. I have my kerberos realm configured,
> and seems to work fine, both nfsserver and nfsclient have their host
> and nfs keytabs stored in /etc/krb5.keytab files, and I am following
> the configuration instructions from
> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that
> rick was kind enough to write (thanx rick!). Before analyzing my
> problem and configuration steps further, let me state the reason for
> this email: I am not able to access an nfsv3 mounted filesystem when
> mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's
> instructions, whereas in the past I had no such problem.
>
> To be more specific:
> Last time I was playing with the configuration most things worked fine
> (Feb 2010), but now things seem a bit different, and I am not sure
> whether I have forgotten something fundamental on my configuration or
> something has changed since I updated both my machines (client and
> server) to the latest sources:
>
> nfs-server:
> # uname -a
> FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed
> Sep 15 17:07:13 EEST 2010
> root at fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER i386
>
> nfs-client:
> # uname -a
> FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep
> 10 13:08:06 EEST 2010
> root at filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT amd64
>
> I have my two usual test-users on my test-machines, mamalos and
> testakis, who both exist as kerberos principals too; their uids and
> gids are the same on all machines. I am able to kinit to any of them
> on my machines and acquire a valid kerberos ticket, which makes me
> assume that kdc runs nicely.
>
> fbsd-client's /etc/rc.conf reads:
>
> rpcbind_enable="YES"
> mountd_enable="YES"
> mountd_flags="-e"
> nfs_server_enable="YES"
> nfs_client_enable="YES"
> nfsv4_server_enable="YES"
> nfsuserd_enable="YES"
> gssd_enable="YES"
>
> and fbsd-server's /etc/rc.conf reads:
> rpcbind_enable="YES"
> nfs_client_flags="-n 4"
> rpc_statd_enable="YES"
> rpc_lockd_enable="YES"
> #nfsd_flags="-e"
> gssd_enable="YES"
> nfsuserd_enable="YES"
> nfsclient_enable="YES"
> # nfs server
> nfs_server_enable="YES"
> mountd_enable="YES"
> #mountd_flags="-e"
>
>
> Don't get confused that both machines have nfsd enabled (the client is
> used as an experimental nfsv4 server too), and I think that this
> should not be an issue with regard to my problem (on the other hand,
> nobody knows...).
>
> the server's kernel-config reads:
>
> options KGSSAPI
> device crypto
> options NFSCL
>
> and the client's kernel-config reads:
>
> options NFSD #(don't forget that the client works as an
> nfsv4 server too)
> options KGSSAPI
> device crypto
>
> Lastly, the server's /etc/exports reads:
> /exports -alldirs -sec=krb5
>
> on the server:
> # ls -la /exports
> total 10
> drwxr-xr-x 5 root wheel - 512 17 Feb 2010 ./
> drwxr-xr-x 22 root wheel - 512 15 Sep 19:33 ../
> drwxr-xr-x 3 root wheel - 512 5 Feb 2010 m/
> drwxr-xr-x 2 mamalos wheel - 512 16 Sep 15:43 mamalos/
> drwx------ 2 testakis wheel - 512 4 Feb 2010 testakis/
>
>
>
> on the client:
> # klist
> klist: No ticket file: /tmp/krb5cc_0
> # mount mount_nfs -onfsv3,sec=krb5 server:/exports /mnt
> # mount
> /dev/da0s1a on / (ufs, local, soft-updates)
> devfs on /dev (devfs, local, multilabel)
> server:/exports on /mnt (nfs)
> # ls -la /mnt
> total 0
> ls: /mnt: Permission denied
> # exit
> $ id
> uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel)
> $ klist
> klist: No ticket file: /tmp/krb5cc_1001
> $ ls -la /mnt
> total 0
> ls: /mnt: Permission denied
> $ kinit mamalos
> mamalos at EXAMPLE's Password:
> $ klist
> Credentials cache: FILE:/tmp/krb5cc_1001
> Principal: mamalos at EXAMPLE
>
> Issued Expires Principal
> Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/EXAMPLE at EXAMPLE
> $ ls -la /mnt
> total 0
> ls: /mnt: Permission denied
> ...
> (dooea?!?!?!!?)
> ...
> $ klist
> Credentials cache: FILE:/tmp/krb5cc_1001
> Principal: mamalos at EXAMPLE
>
> Issued Expires Principal
> Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/EXAMPLE at EXAMPLE
> Sep 16 16:27:51 Sep 17 02:26:49 nfs/server at EXAMPLE
>
> And this is where I don't understand what I have done wrong...
> If I use sec=krb5:sys in my /etc/exports, and type mount_nfs
> -onsfsv3,sec=krb5 ...blabla... on the client, everything seems to work
> ok, but then again no kerberos "protection" is applicable (I am able
> to rw in /mnt/mamalos folders as mamalos without having obtained any
> ticket).
>
> I assume that I must have forgotten to include something very
> fundamental in my configs, but my head is stuck, so if someone has an
> idea...
>
> Thank you all for your time in advance,
>
> regards,
>
> mamalos
>
Rick, I found the problem once I followed your suggestion to kinit -k
fbsdclient.ee.auth.gr on the server; the output was "wrong password" or
something like that.
On both server and client I have two keys stored in their
/etc/krb5.keytab files: one nfs/blabla and one host/blabla (due to other
services I was testing on them). On the server, the first key stored in
the keytab file was the host/ key and not the nfs/ key. Hence it
wouldn't accept it (even though the kdc.log wouldn't complain...this I
still haven't understood so far). Once I placed a single
/etc/krb5.keytab file containing only the nfs/ key, everything worked as
should.
Which yields the (natural?) question: Why am I unable to kinit to both
keys stored in my keytab (I am able to kinit only to the *first* key
stored in the keytab), even though I have the right to store more than
one keys in a keytab?
Thanx again, Rick.
--
George Mamalakis
IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)
Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki
phone number : +30 (2310) 994379
More information about the freebsd-stable
mailing list