Background
As well as storing user accounts and their passwords, the Kerberos servers (KDCs) store accounts and keys (similar to passwords) for systems. Those accounts and keys are used as part of the authentication process to verify which user is connecting to a network service. These accounts are generally called service principals.
Every network service to which a user may authenticate needs to have a service principal with a corresponding key. The network service has to have a copy of that key on the system so that it can verify a user's identity. That key is stored in a specially formatted file called a keytab. One keytab file can store multiple keys, either multiple keys for the same service principal or even keys for several different service principals. On a UNIX system, you can view the contents of a keytab with the klist -k command.
Applications that need to authenticate to network services on an automated basis also need to have service principals and keys in a keytab. For example, any process that writes into a protected directory in AFS needs to have a service principal that it can use to authenticate to AFS.
Due to how Kerberos works, a network service needs to have a separate key for every type of encryption that it supports. We currently support 256-bit AES encryption (the strongest and most modern, but not universally supported yet), triple-DES, and (for legacy compatibility, which will be phased out) DES. Most service principals will therefore have three keys, one for each type of encryption. Kerberos automatically selects the strongest key supported by both the client and server, so normally you don't have to worry about this implementation detail.
To recap, a service principal is an account, an identity, stored in Kerberos for a particular application. That service principal has one or more keys, similar to passwords. Those keys are stored on the server on which the service runs in a file called a keytab, which you can view with the klist -k command.
Types of service principals
There are two basic types of service principals in use at Stanford. The first set are called the "host-based" service principals, meaning that they're tied to a network service running on a particular host. Principals of this type will always have a name like:
type/system.stanford.edu@stanford.edu
where type specifies the type of service and system is the system on which that service is running. The most commonly used service types are:
host/*— remote logins via SSH, rlogin, or rsh, and verification of local loginswebauth/*— WebAuth authentication for web servers
To allow remote login to a system using Kerberos authentication, that system must have a host/* service principal. That principal is also used to verify local logins (to the console, for example) if it exists. The keytab for that service principal must be installed locally in the path expected by the login servers (usually /etc/krb5.keytab).
To use WebAuth, the web server must have a webauth/* service principal and its keytab must be installed in the location set in the WebAuth configuration.
Host-based principals should not be shared and should not be reused. Each host providing a service should have a separate host-based principal for that service, and if that host is replaced by another with a new name, a new host-based principal should be obtained. Specifically, even if a set of web servers are part of a pool that uses WebAuth to serve one site, each server should have a separate host-based WebAuth principal and not share the same one. The principal name is independent of the URL of the web site being served and should match the system's primary name in NetDB.
Other supported but less-often-used services are:
HTTP/*— HTTP Negotiate-Authafpserver/*— Mac OS file sharingcifs/*— CIFS (primarily Windows file sharing)ftp/*— FTP file transferimap/*— IMAP mail accessldap/*— LDAP directorieslpr/*— printingnfs/*— NFSv3 and later file servicespop/*— POP mail accesssieve/*— Sieve mail filter editing on Cyrus IMAPsmtp/*— authenticated SMTPxmpp/*— Jabber
In order to use Kerberos authentication with the corresponding network service, you must have the appropriate service principal and install the keytab in a location used by that network service.
The second type of service principal is a principal used by an application to authenticate to other network services. The most common network services to which automated processes want to authenticate is the campus LDAP directory service and campus-wide AFS file system, but some applications may need access to other services as well. These types of service principals are associated with an application rather than a particular system and would move to a different system if that application were moved. At Stanford, these principals are named:
service/application@stanford.edu
where application is some concise but meaningful designator for the application that will use this service principal.
Creating service principals
Stanford uses a system called the wallet for managing nearly all service principals and setting permissions on those principals so that campus system administrators can download and install keytabs for the appropriate service principals. For information about that process, see Downloading Keytabs with the Wallet.
