IAM in Service Catalog
There are a few different ways to use UW Kerberos on a Linux system, but the most common is for users to use their UW NetID and password when logging into a server via SSH. Which accounts can login is still defined via /etc/passwd. Key tips for configuration:
To accept kerberos credentials, your server will need a service principal and keytab, which can be requested from firstname.lastname@example.org for each server you would like to kerberize.
NFS4, as well as providing nfs ("network shares") can employ Kerberos for authentication, integrity, and privacy. Authentication is provided via the use of keytab files on the nfs server and clients, integrity checks can be performed on transmitted data, and privacy is done via keys to encrypt data over the network.
What follows is a quick "howto" for users of Debian Linux. It is valid for versions "etch" (or "oldstable"), "lenny" ("stable" as of spring 2009), and "squeeze" ("testing", the next stable version). Basic configuration will be emphasized, so that users may find ways to configure appropriate to other Linux distributions. Warning must be made about differences based on kernel version as well as the version of nfs-utils employed. Note will be made about MIT Kerberos 1.8 which is available as of March 2010, and at least one configuration option that may be required due to use of that version.
For the purposes of this document, it is assumed that the user has servers and clients in part of a single third-level dns domain; here it will be referred to as *.bar.washington.edu . UW Tech Identity management team can allow appropriate people to have limited authority to get keytabs for hosts in their domain.
It will also be assumed that a kernel version >= 2.6.18 is being used.
If one has already installed and tested use of a krb5.conf file for use with ssh and pam, then the same configuration file may be used. Ensure that your domain is part of the domain_realm section:
The NFS4 server and client will need to have several other processes running when using nfs4. For both server and client, ensure that /etc/default/nfs-common has the following enabled:
Other Linux distributions should enable these in the appropriate manner. A "ps" should list the processes:
The NFS4 server should also have the svcgssd service running. The /etc/default/nfs-kernel-server file will have:
and "ps" should display this, as well as mountd:
The nfs4 server will employ use of a special mounted filesystem for exports. Say, for example, that user home directories and a common source code directory are to be exported. First, create a base mountpoint for export, and then points for the directories to be exported:
Then, bind mount the home and code directories:
In order to maintain these, you may edit /etc/fstab:
Once the filesystem has been set up for exporting, one edits the /etc/exports file. Read the man page for options. Some options are necessary when Kerberos is to be used with nfs. It should be noted that kerberos is not required for nfs4, but it is a useful addition .
One example for exporting the filesystem above, using GSS and only authentication is as follows:
The first line is required. The portion gss/krb5 tells the nfs4 service that any clients will need to use some Kerberos method to authenticate, to mount the filesystem. This is where keytab files are needed (see below). The option "fsid=0" is required for kerberos exports;
note: Option "sec=krb5" is not available for some kernels and some versions of nfs-utils.
If one intends to add Kerberos integrity checking, substitute "krb5i" in the entries above. If encryption ("privacy") is desired, change the entries to use "krb5p".
Your system may have the two files (or analogous): /etc/idmapd.conf and /etc/gssapi_mech.conf The default version of the latter file in Debian is adequate. The former, idmapd.conf, should be edited, to have something like the following:
Note that the Domain should match your domain. This is needed so that UID's and GID's will be honored on the client. Otherwise, all files will be mapped to the anonymous or "nobody" ID.
The nfs client may mount the exported filesystem, employing /etc/fstab entries analogous to those in this example:
note: The option "sec=krb5p" must match the option on the server. Thus if the server uses krb5i or krb5, the fstab option must be krb5i or krb5, respectively.
After UW Tech Identity management has confirmed that you have authority to get or create keytab files for your *.bar.washington.edu domain, you use the "keyreq" command-line program to create those keytab files.
One can get a tarfile of the source code here: (also, see attachments link at top of page): https://wiki.cac.washington.edu/download/attachments/15766959/keyreq-3.2.tar.gz (md5sum of the file is 43e7c11849c90a9bde0729badd91bdb9).
Configure and compile the program. Then use kinit with your UWNetid, and create your keytab files:
Examining one of the keytab files, one should observe something like this:
Scp the keytab files to your client and server, respectively. On Debian systems, the default filename is /etc/krb5.keytab
Restart the nfs processes, and try to mount the filesystems on the client.
There are a number of errors one may encounter in trying to use nfs4 with krb. One can start up the "helper" daemons with flags to increase log verbosity, and that can help. Also, manually mounting clients with -vvv options may assist.
There is an error that is reflected with various messages, which are not apparently related to the solution. If you are running a comparatively "new" version of the krb5 packages, you may need to add the following line to your /etc/krb5.conf file, in the [libdefaults] section:
allow_weak_crypto = true
MIT Kerberos 1.8 employs, by default, AES. Older versions employ DES. This line allows the different versions to play together nicely.