[ale] NFSv4, Kerberos, and OpenLDAP

[George Allen]

I've only been a user of a ldap/kerberos type setup before - never got into 
the weeds of setting it up or how it worked - but, I know they had it setup 
with AFS instead of NFS.... http://www.openafs.org ... I believe AFS is built 
around Kerberos anyway.

On Friday 21 March 2008 00:48:21 Michael B. Trausch wrote:
> I keep getting the feeling that there should be something simple and
> obvious that I am missing, and yet I don't get it.
>
> I have several machines on my home network.  At any given point, any one
> of them is likely to be temporarily unavailable for one reason or
> another.  I'd like for such issues to not have a huge impact on me; that
> is, I'd like for my home directory (and everyone else's home
> directories) to be stored on the server, and I would also like the user
> accounts and the information that is associated with them to be stored
> on the server.  The machines involved are all Ubuntu boxes, so this
> should be a bit easier than if the network were hybrid... though in the
> future I would like to add the ability to hook Windows clients into the
> network, too, should the need arise.
>
> To that effect, I have installed support on the server for Kerberos,
> OpenLDAP, and NFSv4.  However, I can't quite get the whole thing to work
> together.
>
> Now, Kerberos works just fine, albeit in a very limited way at the
> moment.  I have it talking to OpenLDAP, too, though the OpenLDAP
> database does not (yet) have anything useful in it, because I'd like to
> get NFS working before I switch the authentication method on my system
> to use everything on the server:
>
> mbt at sage:~$ kinit
> Password for mbt at SPICERACK:
> mbt at sage:~$ ldapwhoami
> SASL/GSSAPI authentication started
> SASL username: mbt at SPICERACK
> SASL SSF: 56
> SASL data security layer installed.
> dn:uid=mbt,ou=people,dc=spicerack
>
> So, OpenLDAP and Kerberos talk fine.  However, NFSv4, which is
> *supposed* to be using Kerberos, doesn't seem to work at all:
>
> mbt at sage:/mounts/mbt$ ls -l *.cs
> -rw-r--r-- 1 nobody nogroup 1090 2008-03-06 04:11 fsw.cs
> -rw-r--r-- 1 nobody nogroup  970 2008-03-07 12:41 threading.cs
> mbt at sage:/mounts/mbt$
>
> For some reason, it is showing the files and directories mounted from
> the NFS server as being owned by nobody:nogroup, which is getting to be
> rather frustrating.  In the system log, I see:
>
> Mar 20 23:50:02 sage rpc.idmapd[4965]: nss_getpwnam: name '1000' domain
> 'spicerack': resulting localname '(null)'
> Mar 20 23:50:02 sage rpc.idmapd[4965]: nss_getpwnam: name '1000' does
> not map into domain 'spicerack'
> Mar 20 23:50:02 sage rpc.idmapd[4965]: Client 0: (user) name "1000" ->
> id "65534"
> Mar 20 23:50:02 sage rpc.idmapd[4965]: Client 0: (group) name "1000" ->
> id "65534"
>
> Well, that's just fine and dandy, but my /etc/idmapd.conf is set to the
> correct domain on both the client and the server, the system domain name
> is the same on both the client and the server (e.g., they are both in
> the domain "spicerack"), and the Kerberos realm is network is SPICERACK,
> which should totally not matter (since the NFSv4 domain is supposed to
> be separate from either the system domain name or the Kerberos realm).
>
> I _must_ be missing something "obvious", but I can't figure out what it
> is.  I have gone over several documents and readmes and manuals on
> setting these things up, and the only thing that I know for _sure_ to be
> true is the that the Kerberos system is working.  Though, at the moment,
> it's not all that useful.
>
> My exports on the server (exportfs -v) look like this:
>
> /srv/exports/pxe
> 10.0.0.0/8(ro,async,wdelay,insecure,no_root_squash,no_subtree_check)
>
> /srv/exports/music
> gss/krb5(rw,wdelay,nohide,insecure,no_root_squash,no_subtree_check)
>
> /srv/exports/home
> gss/krb5(rw,wdelay,nohide,insecure,no_root_squash,no_subtree_check)
>
> /srv/exports/etc
> gss/krb5(rw,wdelay,nohide,insecure,no_root_squash,no_subtree_check)
>
> /srv/exports
> gss/krb5(ro,wdelay,insecure,no_root_squash,no_subtree_check,fsid=0)
>
> (the /etc directory export isn't actually going to replace the
> workstation's /etc, by the way... it's just going to supplement it, and
> that's where I will put a few things that need to be done centrally.)
>
> Has anyone here setup a system similar to this?  Does anything stand out
> as obviously incorrect of the relatively minor amount of detail
> exhibited?  Would there be anything helpful/useful to check that I
> haven't shown?
>
> 	--- Mike