Linux workstation authenticating and sharing home directories using Kerberos and encrypted NFS from Windows 2008 R2 Active Directory server

The goal of this exercise is to use a centrally-administered Windows 2008 R2 Active Directory server as an authentication and home-directory server for satellite Linux workstations with Kerberos providing authentication and encrypted NFS providing home-directories.

Full details are in the attached PDF file.

The story in brief

The environment we're considering here is that the users of the Linux workstations may sometimes have a higher or different level of privilege than the administrators or maintainers of these same Linux workstations. These satellite Linux workstations could be anywhere, nearby on a trusted network, or in remote locations or on insecure networks. This means, amongst other things, that should one of these administrators or maintainers log on to one of the workstations as "root", they should not be able to access the files of any user.

There are a couple of parts to this exercise:

Part One

Linux best uses NFS for file sharing, and Windows can operate as an NFS server (with qualifications. See below). The most common form of NFS security is host-based, where the host asserts to the server the UID of the user requesting access to a file and the server trusts this assertion. This is sometimes referred to as "AUTH_SYS".

The main problem here is that it's easy to breach the security of this. It can be done in at least two simple ways:

1. Log on to the workstation as an administrator and then use the su command to "become" the user whose files want to be read, or
2. When adminstrator access to the workstation is not available, connect a different computer to the network on which administrator access is available, create a new user account with the UID of the desired user, and proceed as above.

In addition, if the network itself is insecure, users on other computers may be able to run packet-sniffing software and capture the unencrypted NFS traffic and reconstruct confidential files.

In the sort of environment we are considering here, the NFS traffic should be secured and encrypted. This points us to "krb5i", which is NFS combined with Kerberos-based encryption and authentication of all NFS traffic. Another Kerberos NFS option is "krb5", but this doesn't provide encryption.

Part Two

krb5i operates at two levels: host and user. The Linux workstation itself must have a Kerberos credential, and the user must have a Kerberos credential.

The host credential allows the workstation to mount an NFS share and is completely separate to user credentials providing access to files and directories in that share. Note that amongst other things, the workstation having its own credential neutralises compromise #2 listed above.

Under the hood, Windows uses Kerberos for authentication of users and hosts and so we can tap into this to solve our problem. However, Kerberos only provides authentication. It can only be used to authoritatively determine if a host or user is who they say they are.

We can configure a Linux workstation to use Kerberos for authentication, and a user can log in to the workstation using their user name and whatever factors authenticate them (password, RSA key, etc.), but this only means that they have a Kerberos credential. It doesn't tell the workstation where to find their home directory or what shell to give them. This information can, however, come from LDAP (Lightweight Directory Access Protocol).

Windows Active Directory will talk the LDAP protocol. Once a user has authenticated via Kerberos, the Linux workstation can interrogate the Active Directory server for such things as home directory path and shell for the user and thus allow them to have a session of some sort.

Because the Kerberos credential is used to authenticate NFS access to the files on the server, and the server itself (or, indeed, another AD server in the same trust domain) has provided the credential, then file access can't be gained by any form of impersonation on the workstation. And because the NFS traffic is encrypted using this same credential, it means that the NFS traffic can't be meaningfully sniffed.

Kerberos, LDAP, and NFS

The keys, therefore, are:

• Configuring the workstation to support Kerberos,
• Creating and installing per-host Kerberos credentials for NFS access,
• Mounting or configuring the auto-mounter to mount Kerberos NFS shares,
• Configuring the workstation for Kerberos-based user authentication,
• Configuring the workstation for LDAP-based user authorisation,
• Configuring user-based Kerberos NFS access on the workstation.

Permissions problems - they don't always map

One potentially-significant problem with using any Windows server to provide secure or insecure NFS access is that the file and directory permission semantics of the underlying NTFS file system don't always map very well to UNIX-like permissions.

In particular, the Linux kernel will cache the permissions it sets on files and directories and used these cached permissions to determine a priori operations it can do to these files and in these directories. In some cases, Windows can report a permission error on operations which Linux thinks it should be able to do based on what it thinks the permissions are, and this will cause unexpected failures, such as "I/O errors" to be reported to the [confused] user.