Subject: [nfsv4] NFSv4 Newbie Questions

From: Lesley Kimmel <[email-masked]>
Date: Mon, 23 Nov 2015 11:21:06 -0600

All;

I am new to NFSv4 and am only moderately familiar with Kerberos. I am
working to authenticate NFSv4 mounts on a RHEL6/7 system using Active
Directory and have a few functional and practical questions:

a) Would it be correct to say that a mount would be authenticated as either
the 'nfs' or 'root' principal but user file manipulation requests would
still be done using that user? I mainly aim to use the mount for global
user home directories and want to ensure that user files are still owned by
that user.

b) In relation to 'a', it is my understanding that when using Kerberos the
'service' (in this case NFS server) does not interact with the KDC.
However, if user's file requests are tied to those users and all of my
users exist only in AD (not locally) how does the NFS server determine how
to assign permissions to those files?

c) All of the guides I have seen to setting up NFSv4 describe creating new
user or computer principals to contain the SPN 'nfs/host.fqdn@REALM'. It
appears that the SPN in these cases also gets configured as the UPN and/or
samAccountName so that it is located properly. Is it not possible to
configure a new SPN to the existing host object/principal? It seems
overcomplicated to create a new principal/object that basically just serves
as a UPN to SPN mapping.

Thanks,

-Lesley Kimmel

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 23 Nov 2015 21:11:32 +0000

> On Nov 23, 2015, at 12:21 PM, Lesley Kimmel <[email-masked]> wrote:
> 
> All;
> 
> I am new to NFSv4 and am only moderately familiar with Kerberos. I am working to authenticate NFSv4 mounts on a RHEL6/7 system using Active Directory and have a few functional and practical questions:
> 
> a) Would it be correct to say that a mount would be authenticated as either the 'nfs' or 'root' principal but user file manipulation requests would still be done using that user?

Mostly correct. The typical setup is to have ‘machine’ Kerberos credentials for UID 0 for mount. These credentials use a keytab key on the client of the form “root/fqdn@REALM” or “host/fqdn@REALM or “nfs/fqdn@REALM”, and on the server “nfs/fqdn@REALM”. The keytab keys are used as “passwords” to refreah Kerberos credentials. The client rpc.gssd daemon uses a keytab key to talk to the KDC to obtain first a TGT and then a service ticket for the server. This is what you refer to as the “nfs” principal for mount.

The root user (not recommended) can also be used. Here the admin kinit’s as root to get the kerberos credentials for UID 0. Need to run rpc.gssd with the “-n” option, and setup automated root user Kerberos credential refresh.

Users accessing the kerberized mount need to kinit and get their own set of kerberos credentials as principal@REALM.

rpc.gssd uses service tickets in the NFS NULL RPCSEC_GSS_INIT NULL calls to create a GSS-context.

> I mainly aim to use the mount for global user home directories and want to ensure that user files are still owned by that user.

Yep. After the server successfully processes the RPCSEC_GSS_INIT NULL call from the client, it maps kerberos principal to a UID. If that mapping fails, the GSS context is tossed and the server sends an error to the cleint.

> 
> b) In relation to 'a', it is my understanding that when using Kerberos the 'service' (in this case NFS server) does not interact with the KDC. However, if user's file requests are tied to those users and all of my users exist only in AD (not locally) how does the NFS server determine how to assign permissions to those files?

First off, the service ticket has two parts, a client portion encrypted using client keys and and a server portion encrypted using server keys. The server decrypts it’s portion durring processing of the RPCSEC_GSS_INIT from the client. If said processing is successful, the kerberos portion on the server is done, but the server still needs to map the Kerberos principal to a UID - that mapping is how the server determines permissions (.e.g the UID, and the associated GIDs.)
> 
> c) All of the guides I have seen to setting up NFSv4 describe creating new user or computer principals to contain the SPN 'nfs/host.fqdn@REALM’.

Not user, just computer.

> It appears that the SPN in these cases also gets configured as the UPN and/or samAccountName so that it is located properly. Is it not possible to configure a new SPN to the existing host object/principal? It seems overcomplicated to create a new principal/object that basically just serves as a UPN to SPN mapping.

Note that you are only talking about the mount portion here.The NFSv4 RFCs (7530 and 5661) reqire the server machine (or computer) identity to use “nfs/fqdn@REALM” - as mentioned above the client has a bit more leeway - can use root/ or host/ as the service portion of the machine or computer identity.

Users kinit as principal@REALM.

—>Andy

> 
> Thanks,
> 
> -Lesley Kimmel
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4