Basics: UNIX Shared Network Folders and Centrify - Network File System (NFS)

Background

File sharing is a basic capability of all enterprise networks.  As a matter of fact, time-sharing and file/print sharing accelerated the need for local area networks.  In heterogeneous environments it's very common to see Windows Sharing  (Server Message Blocks or SMB, better known as Common Internet File System (CFS)) using Windows Servers or UNIX/Linux via Samba's implementation.  Traditionally in UNIX and Linux the Network File System (NFS) protocol is widely utilized.
Note that the network file sharing protocol is different than the File System.
For example, in Windows an NTFS (or FAT32) file system can be made available over the network using the CIFS network file sharing protocol.  or in UNIX, an ext3 file system can be made available over the network using the Samba or NFS network file sharing protocols.

File Sharing meet Identity / Identity meet File Sharing

In order to assign or determine ownership of files and folders, file sharing protocols may rely on OS system frameworks or on proprietary methods to achieve this goal.  It's very important to understand the separation of functions, from the moment that the identity of the user (and or groups) is determined, the protocols, methods, and any other functions for file/folder access, manipulation, etc. is implemented between the client and the server based on the network file system specifications.

Identification with NFS

NFS leverages operating system calls to determine identities, in the case of users, it relies on the getpwuid() function.  The manual page for states that "the getpwuid() function returns a pointer to a structure containing the broken-out fields of the record in the password database that matches the user ID uid."
For our purposes, the most important detail about this is that getpuid is Name Server Switch-aware and therefore, if the passwd entry in the /etc/nsswitch file looks like this:

passwd:  centrifydc  files

This entry should be familiar, it is a centrified system! and it means that getpwuid will leverage the methods(*) from APIs provided by the centrifydc daemon find the matching UID for the login name, and then it will look at the local file /etc/passwd.
(*)In this case, a mutually authenticated (Kerberos) LDAP connection between the client and a local domain controller.

But what if the system looks like this:

passwd:   files

This means that if a match is not found in the local file (/etc/passwd) and if the user is not found, it will be treated as an anonymous connection  (if the way the NFS share was configured allow such types of connections), regardless on how the share is configured to deal with anonymous connections, the NFS request Remote Procedure Call (RPC) provides a UID and a set of GIDs for the user accessing the share.
Note: there are different versions of NFS, implemented slightly differently by different vendors or distributions, so imagine the combinations here.

NFS Use Cases

So, let's simplify:
Use Case A -  We all know each other:
All computers participate within a directory service (files, NIS, LDAP, etc), therefore, every NFS request should be able to know the UID, GID of the user.  All is nice and dandy here.

Use Case B - There are stand alone computers out there that may be NFS servers or clients
It's possible that here there will be anonymous NFS connections that will be handled accordingly.

Although this last use case does not make a lot of sense, it is quite common due to things like this:

1. Chaos is part of the status quo.
2. Chaos is being used as an abstraction layer for "security" or "control" purposes
3. The infrastructure is going through a migration  (more like it)
4. There are appliances (like filers) that have yet to be configured to participate in the directory services (very common - will be covered in the Cool Projects section)

The first two use cases are human problems that we don't delve into.  Let's talk about case # 3.  In our environment we have 3 systems so far:

CEN1 (database system) - it has been Centrified

SUSE1 (web system) - it has been Centrified

SOL1 (utilities system) - it has not been Centrified.

But SOL1 contains an NFS share:  sol1:/export/my-nfs  configured to treat anonymous connection identity based on the identity provided in the RPC request.   Let's assume the following sequence.

In CEN1, the sol1:/export/my-nfs is mounted in the /mnt/remote folder, and jessie logs and creates a file in the remote share:

[jmatthews@cen1 remote]$ id

uid=1149240406(jmatthews) gid=1149240406(jmatthews) groups=1149240406(jmatthews) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[jmatthews@cen1 remote]$ ls

[jmatthews@cen1 remote]$ touch a.txt

[jmatthews@cen1 remote]$ ls -l

total 0

-rw-rw-r--. 1 jmatthews jmatthews 0 Jan 11 12:59 a.txt

[jmatthews@cen1 remote]$

[jmatthews@cen1 remote]$ getent passwd | grep 1149240406

jmatthews:x:1149240406:1149240406:Jessie Matthews:/home/jmatthews:/bin/bash

Note the sequence of commands, you can see Jessie's UID (1149240406), and note that when we list the file, it correctly displays Jessie's login as the owner of the file a.txt (the system is able to know, yes I know who UID 1149240406 is) and this is confirmed with the getent command searching for that UID.

Now let's look at things from the perspective of the Non-Centrified SOL1 system:

bash-3.2# pwd
/export/my-nfs
bash-3.2# ls -l
total 0
-rw-rw-r--   1 1149240406 1149240406       0 Jan 11 12:59 a.txt
bash-3.2# getent passwd | grep 1149240406
bash-3.2#
bash-3.2# cat /etc/nsswitch.conf | grep passwd

passwd:     files

Looking at this with the root account, the my-nfs folder correctly displays the file a.txt file, however it can't resolve the login for UID 1149240406, and when I issue the getent command there's no result, and this is understandable because the system is not configured with the same directory service.  This is OK as long as the share is accessed remotely, but if Jessie has a local account on SOL1 it's very likely that the UID is different, and to use his files he'd have to elevate to root, use the chown command, do his work, and later, when accessing from the network the process is going to happen again.  Chown-fests are not fun.

What are the options?

The quickest solution is to Centrify the system, that way you turn this use case from B to A and move on.  In our case this is doable.  But what if:

• There are NIS Maps like auto-mounter that depend not only on NFS, but on the presence of a NIS map.
• The system that is hosting the NFS share is an appliance, and it's not possible to install the Centrify client on it.
• There are still applications that use NIS calls like ypcat or perform yp binds.  They may be sunset, but they are critical and there's no short path to decommission. 

The good news is that with Centrify there are ways to solve all these problems.

If the NFS server is an appliance, there are utilities (like the Centrify LDAP and NIS proxies) to provide the appliance with the identity information required to perform the adequate UID/GID assignment. This post covers the implementation of the LDAP proxy on a NetApp appliance.