Skip to content

Setting up a file server

Jump to bottom
Charles Hedrick edited this page Feb 8, 2018 · 1 revision

Return to main: Kerberos

This is documentation for how edinburgh is set up. It is an Aberdeen file server. It currently uses a slightly tailored Centos 6 system. Centos 6 is new enough to support NFS 4 with Kerberos. It does not support two factor authentication, but it doesn't need to, since users will authenticate on a client system. Once you've authenticated with 2FA, your ticket is like any other Kerberos ticket, so you can ssh and use NFS whether the other machine understands 2FA or not.

Table of Contents

NFS protocol options

NFS v3 without Kerberos sends the user's current uid, gid, and list of groups. The server checks whether a file is accessible, but it believes that data. So the server doesn't need any knowledge of its own about the user. Everything it needs to check permission is in uid, gid, grouplist.

In addition, clients send the server uid and gid info when creating a file or doing chgrp, and the server sends info for "ls -l" and other purpose. That info is exchanged as numerical group and user ids.

Kerberos and NFS v4 change both of these. Kerberos sends the Kerberos principal, but not the current uid, gid and grouplist. To check accessibility, the server must be able to translate the principal to a uid, and must be able to find what groups that user is a member of.

Kerberos and NFS v4 also translate uid and gid to strings and back, in both directions, for file create, chgrp, and ls -l. That means that the server must know all uids and groups in use on the file system.

However NFS v4 also permit the user and group strings to be numerical identifiers passed as strings. That's a later addition to v4. Initially, names were used even without Kerberos. However that created inconsistencies. Without Kerberos, v4 was sending uid, gid and group list as numbers for access checking, but expecting translation to names for ls -l and setting user/group at file creation. In a later addition to the protocol, v4 when Kerberos is not used may pass users and groups as numbers. There's a kernel parameters in the Linux kernel to control whether numbers or names are sent for V4 without Kerberos. With Kerberos, the protocol requires names to be used. I believe the default setting for recent kernels is to use numbers without Kerberos.

Here are the combinations:

  • v3, no Kerberos: access checking based on uid, gid, group list; user and group passed as numbers
  • v3, Kerberos: access checking based on Kerberos principal, user and group passed as numbers
  • v4, no Kerberos, original: access checking based on uid, gid, group list; user and group passed as names
  • v4, no Kerberos, revised: access checking based on uid, gid, group list; user and group passed as numbers in string form
  • v4, Kerberos: access checking based on Kerberos principal, user and group passed as names
It does not appear to be possible to pass users and groups as numbers in V4 with Kerberos.

enable Kerberos and NFSv4

  • in /etc/sysconfig/nfs, set secure NFS, comment -N 4, which disables NFSv4
However until we get our groups consistent, I'm going to use V3. Thus for the moment I'm uncommenting the -N 4, though leaving secure. Note that with Kerberized v3, the server still checks permissions, so we still need access to user and group information via LDAP.
  • in /etc/idmapd.conf, put cs.rutgers.edu as domain [note:]
  • add /etc/krb5.keytab. This must have entries for both host/FQDN and nfs/FQDN
  • put our verson of /etc/krb5.conf
Note that you can still use NFSv3 with Kerberos. It’s just as secure. The only difference is that it sends UID and GID rather than translating to names. V4.1 is supposed to have better performance than V3, because it has more parallelism. So I’m doing all my work with V4. But I did test V3 to Edinburgh and it works. The id / name mappings are cached by the kernel, so they don’t seem to create a performance issue. Kerberos shouldn’t cause performance issues either with recent CPU chips. Unless you enable encryption of content.

to give it access to users and groups via LDAP

/etc/ipa-ca.crt is a copy of the cert for the incommon CA 

 ca cert for kdc in /etc/ipa-ca.crt
 /etc/nslcd.conf — see below

 service nslcd start
 chkconfig nslcd on
 service nscd start
 chkconfig nscd on

Here nslcd.conf: 

uri ldap://krb1.cs.rutgers.edu
uri ldap://krb2.cs.rutgers.edu
# this is what we should use but I haven't tested it
#base cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu
base dc=cs,dc=rutgers,dc=edu
scope sub
ssl start_tls
tls_cacertfile /etc/ipa-ca.crt
comment out the default settings at the end

If the primary is down, there will be a pause of over 10 sec the first time a user needs to be looked up. It appears to switch over after that.

ldap client setup

To help you debug user issues, I created an ldap.conf that has all the right magic argument to access the LDAP server. Without that you need a ton of command-line arguments to specify the location of the server and how to get SSL to work. With this file the only argument you need is x. E.g. “ldapsearch -x uid=hedrick” willl find my entries.

Here's /etc/openldap/ldap.conf: 

TLS_CACERTDIR /etc/openldap/cacerts
URI ldaps://krb1.cs.rutgers.edu
BASE dc=cs,dc=rutgers,dc=edu
TLS_CACERT /etc/ipa-ca.crt
Clone this wiki locally