Centralized User Management with Kerberos and LDAP

Travis Crawford

Many computing environments are designed to make network resources available to users from any location, such as personal workstations, public workstations, and the Web. User management is an important part of this type of distributed computing environment because it provides the consistent authentication and authorization service necessary for universal access. Kerberos and LDAP are two protocols that have been designed to solve the distributed authentication and authorization problem.

Centralized management of user accounts solves a major problem in distributed computing environments. Without centralization in an environment with X users, Y computers, and Z services, we have (X*Y)+(X*Z) accounts to manage. With centralization, we have X+Y+Z accounts to manage.

In this article, I will provide an overview of user account management with Kerberos and LDAP. I will describe the protocols and how they work as well as their implementation. Finally, I will discuss how to manage accounts using this new system.

Login Overview

The login process for a Linux system must first be understood before it can be extended. The process begins with a user entering credentials such as username and password into the login program (step 1). Login uses the PAM abstraction layer to authenticate the user (step 2). Typically, the pam_unix module (step 2.1) is used to compare the password entered by the user to the hash stored in the shadow file (2.2). If no entry exists in the shadow file, the normal login process will fail. However, this environment has Kerberos configured, and the pam_krb5 PAM module (2.3) authenticates the user by obtaining a ticket-granting-ticket from the Kerberos server (2.4).

Authentication is only part of the login process. At this point, login has verified that a user is who they claim to be. The authorization phase determines whether the user is allowed to use this resource. Login uses the name service switch (step 3) to look up user information, such as uid number, shell, and home directory. Typically, the nss_files module (3.1) looks up this information in the passwd file (3.2). If the user information is not found locally, this environment uses the nss_ldap module (3.3) to look up the user information from the LDAP server (3.4). The success or failure of this login attempt is reported to the system logger (4), and finally, if steps 2 and 3 are completed successfully, the user is granted access (5) (see Figure 1).

Kerberos

The Kerberos protocol is designed to securely authenticate users over an insecure network and to enable single sign-on. A trusted third party and strong cryptography are used to meet these goals.

Passwords are never sent over the network while using Kerberos. Additionally, mutual authentication verifies the identity of both parties involved in any communication. Finally, single sign-on securely authenticates users automatically after they have logged into the realm.

Kerberos tickets are analogous to a weekend pass at a ski resort. Upon arrival, one obtains a passcard that is valid for a limited period of time. At each mountain, the passcard can be used to obtain a lift ticket. At the end of the weekend, the passcard expires as well as all lift tickets. Kerberos calls its weekend passcard a Ticket Granting Ticket (TGT), which is by default valid for the length of a typical work day. TGTs are used to obtain service tickets that grant access to a specific service, such as LDAP. Additional service tickets must be obtained for additional services.

While this method was first implemented at MIT, Roger Needham and Michael Schroeder designed much of the original protocol at the Xerox Palo Alto Research Center. Their research included both public and private key cryptography and compared the strengths and weaknesses of each method. They concluded that private key cryptography was superior for a network authentication system because it required fewer protocol operations per transaction while remaining equally secure.

Kerberos was first released to the public as Kerberos-4, with the first three releases used internally at MIT; the current release is Kerberos-5. Because of the export controls on strong encryption technologies, an independent Kerberos implementation called Heimdal has been developed at the Center for Parallel Computers in Sweden. Both implementations are well supported and are functionally the same.

Kerberos is an Internet standards track protocol defined in RFC 1510: The Kerberos Network Authentication Service (V5).

Protocol

The Kerberos protocol is designed to securely authenticate users over an insecure network and to enable single sign-on. With these goals in mind, we define two major modes of operation. Initial sign-on (ISO) describes the mode in which a user authenticates as a principal in a Kerberos realm, a concept similar to logging in as a user to a Windows domain. Successful completion of ISO provides the user with a ticket-granting ticket, an electronic ID card that verifies the identity of its owner. Single sign-on (SSO) describes the mode in which a user authenticates to an application in the Kerberos realm; this authentication is automatically performed for the user by the Kerberos client. SSO enables users to enter their username and password just once per computing session.

Initial Sign-On

Initial sign-on describes the following Kerberos Authentication Service protocol exchange:

1. Client to Kerberos: Authentication service request (KRB_AS_REQ)

2. Kerberos to Client: Authentication service reply (KRB_AS_REP) or Error (KRB_ERROR)

The KRB_AS_REQ request message is constructed by a Kerberos client and sent to a Kerberos server. This plain-text message contains the client identity assertion, local time, authentication server principal name, and requested lifetime. The client identity assertion is described as such because a user may attempt to acquire the credentials of a different user; this type of brute force attack is preventable with pre-authentication and will be discussed later. The client's local time is used to ensure reasonably synchronized clocks; although the request message does not rely on synchronized clocks, future protocol operations do, and this helps prevent errors later on. The authentication server principal name is usually krbtgt/INSTANCE@REALM. The requested lifetime is used to request a non-default ticket lifetime.

Pre-authentication is used to prevent the construction of request messages with arbitrary principal names. In response to KRB_AS_REQ request messages for a principal that requires pre-authentication, the Kerberos server returns an encrypted challenge value inside a KRB_ERROR error message. The client must decrypt the challenge value with the user's password and resend the KRB_AS_REQ request message with the appended challenge value. If the server accepts the challenge response, a KRB_AS_REP reply message is constructed and sent to the client. Note that the user has been authenticated without sending his or her password over the network, even in encrypted form.

The KRB_AS_REP reply message is constructed by a Kerberos server and sent to clients in response to KRB_AS_REQ request messages. This message, encrypted with the user's password, contains the user's copy of the unique session key, authentication server principal name, ticket lifetime, and TGT encrypted with the authentication server's password. The encrypted TGT contains the authentication server's copy of the unique session key, client principal name, ticket lifetime, timestamp, and client IP address.

Subsequent communication is encrypted with the session key known only to client and server that is valid for a limited time, for a specific user, from a specific host. These checks ensure that, in the event a KRB_AS_REP reply message is captured and decrypted, the TGT is invalid because either the IP address is incorrect or the ticket lifetime has been exceeded.

The session key contained in a KRB_AS_REP reply message is a private encryption key known only to client and server and is valid only for the current session. Encrypting client to Kerberos server and client to application server communication with unique session keys increases security in several ways. First, every two principals in a Kerberos realm that wish to communicate have a unique session key, thus providing mutual authentication. Second, breaking the encryption on a single session is time sensitive because tickets expire after a period of time.

While confusing at first, the ISO process becomes clear with some inspection. Clients construct a clear-text request message for a TGT that is sent to the server. If pre-authentication is enabled, the server returns an error message that includes a challenge value encrypted with the user's password. The client decrypts the challenge value and appends it to a second TGT request message. The server has now verified the user's identity and sends the client a reply message containing a TGT encrypted with the user's password. The client decrypts the TGT and is authenticated.

Single Sign-On

Single sign-on describes the following Kerberos Authentication Service protocol exchange:

1. Client to Kerberos: Authentication service request (KRB_AS_REQ).

2. Kerberos to Client: Authentication service reply (KRB_AS_REP) or Error (KRB_ERROR).

3. Client to Application server: Application request (KRB_AP_REQ)

4. [Optional] Application server to Client: Application Reply (KRB_AP_REP) or Error (KRB_ERROR).

The KRB_AS_REQ authentication service request message is constructed by a Kerberos client and sent to a server, similar to ISO, except that the authentication server principal name is replaced with the application server principal name. The KRB_AS_REP authentication server reply message contains the user's copy of a unique session key and a service ticket encrypted with the application's password.

After acquiring a service ticket, the client constructs a KRB_AP_REQ application request message and sends it to the application. This message contains the service ticket and authenticator encrypted with the session key; the authenticator contains a timestamp and client principal name. The application decrypts the service key with its password and decrypts the authenticator with the session key. Mutual authentication is achieved because only the appropriate application can decrypt the service ticket, and only the appropriate client has knowledge of the session key to encrypt the authenticator.

Installation and Configuration

Before configuring Kerberos, it is important to decide which implementation to use. Two major Kerberos implementations are freely available for Linux: MIT Kerberos and Heimdal. Both implementations are stable, well supported, and have an active user base. The major difference is that Heimdal is developed outside the United States and therefore is not subject to export control restrictions; many free operating systems use Heimdal for that reason.

The following installation and configuration description is based on MIT Kerberos on Fedora. Begin by downloading the source code from the MIT Web site or installing the krb5-servers and krb5-workstation packages. The default installation path for the source distribution is /usr/local and the packages install to /usr/kerberos.

A new Kerberos server configuration comprises the following steps:

1. The Kerberos configuration file krb5.conf sets defaults used during the configuration process.

2. [libdefaults]

3. default_realm = EXAMPLE.EDU

4.

5. [realms]

6. EXAMPLE.EDU = {

7. kdc = kerberos.example.edu:88

8. admin_server = kerberos.example.edu:749

9. }

10. Initialize a new Kerberos database using kdb5_util. The -s option is used to create a stash file that includes the master database password for unattended server startup.

11. kdb5_util create -s

12. Create administrative and regular users and policies using kadmin.local.

This administrative interface directly modifies the Kerberos database and must be run as root on the KDC; use this interface because no principals currently exist with which to log in. Use kadmin after creating the administrative principal and setting the appropriate access control list.

Kerberos-5 principals are written in the form username/instance@REALM, where username is a user's unique name, instance is an optional group (such as admin), and realm is the realm name in which this ticket is valid.

Create the administrative and default policies:

# kadmin.local -q "addpol -maxlife \"1 month\" -minlength 8 \
  -minclasses 3 admin"
# kadmin.local -q "addpol -maxlife \"3 months\" -minlength 8 \
  -minclasses 3 default"

# kadmin.local -q "addprinc -policy admin +requires_preauth travis/admin"
Authenticating as principal root/admin@EXAMPLE.EDU with password.
Enter password for principal "travis/admin@EXAMPLE.EDU":
Re-enter password for principal "travis/admin@EXAMPLE.EDU":
Principal "travis/admin@EXAMPLE.EDU created.
# kadmin.local -q "addprinc travis"
Authenticating as principal root/admin@EXAMPLE.EDU with password.
NOTICE: no policy specified for travis@EXAMPLE.EDU; assigning "default"
Enter password for principal "travis@EXAMPLE.EDU":
Re-enter password for principal "travis@EXAMPLE.EDU":
Principal "travis@EXAMPLE.EDU created.

14. a -- [Dis]allows the addition of principals or policies in the database.

15. d -- [Dis]allows the deletion of principals or policies in the database.

16. m -- [Dis]allows the modification of principals or policies in the database.

17. c -- [Dis]allows the changing of passwords for principals in the database.

18. i -- [Dis]allows inquiries to the database.

19. l -- [Dis]allows the listing of principals or policies in the database.

20. x -- Short for admcil.

21. * -- Same as x.

A simple ACL that allows all principals with an administrative instance full control may be sufficient in small environments, while more complex lists may be required in environments with distributed support groups:

*/admin@EXAMPLE.EDU   *

A minimal Kerberos server is now configured and should be adequate for testing purposes. Before using in a production environment, be sure to read the man pages and understand very well what you are doing.

Backup and Restore

Several methods are available for backing up the Kerberos-5 database, including a full filesystem backup and Kerberos database dump. The recommended backup method is to use the dump mode of kdb5_util(8). As root, stop the server process, dump the Kerberos database, and then restart the process:

service krb5kdc stop
kdb5_util dump kerberos-backup.txt
service krb5kdc start

Restore the KDC database using the load mode of kdb5_util. Load creates a new database containing only the principals in the dump file, overwriting any existing principals. Existing principals are kept when using the update option. As root, stop the server process, load the Kerberos database, and then restart the process:

service krb5kdc stop
kdb5_util load kerberos-backup.txt current-database
service krb5kdc start

LDAP

The Lightweight Directory Access Protocol (LDAP) defines a method to search and modify a remote database. Directory services are used to reduce the number of administrative data repositories in an organization.

LDAP has its roots in the X.500 series of specifications, a worldwide directory service complete with protocol, object classes, attribute types, authentication framework, and replication. The directory as defined was so thorough in its design that it became difficult to implement. The complexity of implementation was not limited to servers; clients were difficult to write as well. The University of Michigan recognized this limitation and created LDAP, a gateway to X.500 servers with a simple client interface. By making LDAP clients easier to implement, more applications began to use the directory, thus making it more useful. Eventually the gateway became the first standalone LDAP server.

LDAP is an Internet standards track protocol defined in RFC 2251: Lightweight Directory Access Protocol (v3).

Protocol

LDAP directory access operations describe the following protocol exchange:

1. Client to server: Bind request

2. Server to client: Bind result

3. Client to server: Search request

4. Server to client: Search entry

5. Server to client: Search result

6. Client to server: Unbind request

The bind request message is constructed by an LDAP client and sent to an LDAP server. It indicates the beginning of a new connection and contains the distinguished name and password credentials with which to bind. LDAP supports several authentication methods (specified by the Auth Type), including Kerberos through the GSSAPI, so this data may or may not be encrypted, depending on how the server is configured.

Servers respond with a bind result message to bind request messages. A result code, such as success, or error message indicates whether the bind was successful and whether the connection should continue.

Once bound, the client sends a search request message that contains a Base DN, scope, and filter. The Base DN, such as ou=people,dc=example,dc=edu, specifies where in the namespace hierarchy to start the search. For example, a search for user accounts might be limited to the user section of the namespace and omit searching application settings.

The scope specifies how deep to look and may be base (base DN only), oneLevel (children of the base DN), or sub (all entries below the base DN). Finally, the search filter specifies what to look for.

Search filters are written in the form attribute=value and may be combined with a subset of boolean operators. To find the entry that represents my user account, I would construct a query such as (&(objectClass=posixAccount)(uid=travis)). Most LDAP-aware applications take care of constructing the search filter; however, the command-line program ldapsearch allows you to specify a custom filter. You might be surprised at how much information can be extracted from public LDAP servers by constructing custom queries because many sites implement access control, not in the LDAP server itself, but in their Web-based front-end.

The search entry message is sent from server to client, with one message per entry matching the search filter. These messages contain the distinguished name and all associated attribute/value pairs. The results are either returned printed to the screen or returned to the application as an array for processing. The Search result message is sent from server to client to indicate a successful operation after all search entry messages have been sent.

Finally, an unbind request message is sent from client to server to indicate no additional search requests will be sent. This implies that multiple search requests may be sent during a single connection, which reduces overhead.

Schema

The LDAP schema defines what data can be stored in the directory. It is the collection of attribute types and object classes that are valid. Attribute types define a specific type of variable for use in the directory. It defines the name, matching rule, and whether the attribute may be defined multiple times for a specific entry. Directory-enabled applications use attribute types to store their data.

RFC2307 defines a schema that enables Linux clients to store user accounts in a directory server. The nis.schema file packaged with OpenLDAP implements RFC2307 and provides the attribute and object class definitions to store the contents of /etc/passwd, /etc/shadow, and /etc/group in a directory. Providing the functionality of these files in the directory allows it to replace local databases throughout an organization.

Structural object classes typically represent real-world objects, such as people or organizations. Every LDAP entry has exactly one structural object class but may have additional auxiliary object classes. For example, the structural object class person represents a person, and the auxiliary object classes posixAccount and shadowAccount represent the person's computer account. Object classes and attributes are defined in the schema files included with directories and directory-enabled applications.

Directory entries with structural object class person represent individual people who may or may not have a computer account:

objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
    DESC 'Abstraction of an account with POSIX attributes'
    MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
    MAY ( userPassword $ loginShell $ gecos $ description ) )

objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY
    DESC 'Additional attributes for shadow passwords'
    MUST uid
    MAY ( userPassword $ shadowLastChange $ shadowMin $
    shadowMax $ shadowWarning $ shadowInactive $
    shadowExpire $ shadowFlag $ description ) )

objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top STRUCTURAL
    DESC 'Abstraction of a group of accounts'
    MUST ( cn $ gidNumber )
    MAY ( userPassword $ memberUid $ description ) )

attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
    DESC 'The absolute path to the home directory'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
	

The OpenLDAP configuration file slapd.conf contains configuration information for the OpenLDAP server. It should not be world-readable because several secret pieces of information must be stored in it, such as the root directory account and password and access control list definitions. Schema files that represent Linux user accounts and groups must be imported and the schema check enabled to ensure the schema are followed:

# Linux user accounts (objectClass posixAccount) are defined in 
# nis.schema
# core.schema and cosine.schema are required by nis.schema
include       /etc/openldap/schema/core.schema
include       /etc/openldap/schema/cosine.schema
include       /etc/openldap/schema/nis.schema
schemacheck   on

# Messages are logged to LOCAL4
# Add "local4.* /var/log/slapd.log" to your syslogd configuration
loglevel    256

# back-end database configuration
database    ldbm
directory   "/var/lib/ldap"
mode    0600
suffix  "dc=example,dc=edu"

# root directory user account
rootdn      "cn=Manager,dc=example,dc=edu"
rootpw      {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
SASL AND GSSAPI

LDAP <--> SASL <--> GSSAPI <--> Kerberos

sasl-host      kerberos.example.edu
sasl-realm     EXAMPLE.EDU
sasl-secprops  noplain,noactive,noanonymous

When GSSAPI is used as an authentication source, slapd.conf ACL entries must be modified because GSSAPI-distinguished names end with cn=gssapi,cn=auth. To allow all users who authenticate with GSSAPI to have read access, machines to have read access, and everyone to have no access, use an ACL similar to the following:

access to *
    by dn.children="cn=gssapi,cn=auth" read
    by dn.children="ou=Machines,dc=example,dc=edu"
    by anonymous auth

kadmin -q "addprinc -randkey ldap/ldap.example.edu@EXAMPLE.EDU"
kadmin -q "ktadd ldap/ldap.example.edu@EXAMPLE.EDU"

kinit travis
ldapsearch "(uid=travis)" -Y gssapi

Transport Layer Security (TLS) is the evolution of SSL and is used to encrypt the communication between hosts at the transport layer. Enabling TLS first requires the creation of a digital certificate and key:

/usr/local/ssl/misc/CA -newcert

slapd.conf.
TLSCipherStrength       HIGH
TLSCertificateFile      /etc/openldap/ldap-key-cert.pem
TLSCertificateKeyFile   /etc/openldap/ldap-key-cert.pem

A comprehensive backup strategy will allow the directory to be restored after a disaster, user error, or malicious network attack. Two methods are available for backing up directory data: back up the entire filesystem on which the directory database is stored, or create an LDIF file containing all directory entries. The dump and restore commands are used to back up and restore entire filesystems. The slapcat and slapadd commands are used to create and restore LDIF files.

Creating then archiving an LDIF file is the recommended backup method because the format is server independent and stored as ASCII text rather than in binary format. This allows an administrator to make changes or correct errors before restoring the directory. As root, stop the LDAP server, write the directory contents to a file on disk, and then restart the server:

service ldap stop
slapcat > directory-backup.ldif
service ldap start

The directory-backup.ldif file may be copied to tape or a remote file system for safekeeping. Security of the backup is critical because access control restrictions are implemented in the LDAP server, not the data file itself. This file is organized in superior first order, the same format that slapadd requires. The directory may be restored with:

service ldap stop
slapadd < directory-backup.ldif
service ldap start

Client Configurations

Each Linux client must be configured to authenticate users and look up account information over the network rather than to use the default local databases. These network services should be transparently accessed to make the login process easy for the user. Kerberos and Pluggable Authentication Modules (PAM) implement authentication, while LDAP and the Name Service Switch (NSS) implement look up of user information in the directory.

Kerberos Client Configuration

The Kerberos client configuration file /etc/krb5.conf specifies the local realm name and other parameters needed for authentication. More information is available in krb5.conf(5):

[libdefaults]
    default_realm = EXAMPLE.EDU

[realms]
    EXAMPLE.EDU = {
        kdc = kerberos.example.edu:88
        admin_server = kerberos.example.edu:749
    }

PAM is the Linux subsystem that handles authentication tasks on behalf of applications. It breaks down authentication into four distinct tasks: authentication, account management, session management, and password management. Authentication verifies the user is who he or she claims to be. Account management determines whether the authenticated user is permitted access at this time. Session management functions trigger events at login and logout, such as writing log entries. Password management functions change users' passwords.

PAM-aware applications can be configured globally with /etc/pam.conf or individually with files in /etc/pam.d. The presence of the /etc/pam.d directory causes the global configuration file to be ignored. The pam_stack.so module can be used to include configuration files.

We enable the Kerberos authentication service in PAM by adding the pam_krb5.so module to the appropriate PAM stack, such as the system-auth file that is included in most application configurations. Enable Kerberos for authentication and password tasks:

# /etc/pam.d/system-auth

auth        required    pam_env.so
auth        sufficient  pam_unix.so likeauth nullok
auth        sufficient  pam_krb5.so use_first_pass
auth        required    pam_deny.so

account     required    pam_unix.so

password    required    pam_cracklib.so retry=3 type=
password    sufficient  pam_unix.so nullok use_authtok md5 shadow
password    sufficient  pam_krb5.so use_authtok
password    required    pam_deny.so

session     required    pam_limits.so
session     required    pam_unix.so

LDAP Client Configuration

The LDAP client configuration file /etc/ldap.conf specifies server connection parameters. More information is available in ldap.conf(5):

uri ldaps://ldap.example.edu
base dc=example,dc=edu

The NSS specifies where to look up name information and in what order. Traditionally, names were looked up in the passwd file by each application. The introduction of NSS allowed multiple name services by abstracting the lookup request from the actual lookup. Programs now make a request to NSS for a lookup and the appropriate library is used. Specify LDAP as a source for user account and group information in nsswitch.conf(5):

passwd: files ldap
shadow: files ldap
group: files ldap

Configuration Tools

Most Linux distributions have tools for configuring Kerberos, PAM, LDAP, and NSS. Red Hat and Fedora users have authconfig(8) and the GUI-equivalent, authconfig-gtk, for reconfiguring an existing installation and Kickstart for new installations. Kickstart allows an administrator to automate the installation process by providing an answer file for common configuration questions, such as authentication and user account lookup methods. Check the documentation of your distribution for more information on configuration tools.

Account Management

The creation, modification, and deletion of user accounts on a single Unix system are simple tasks with the user{add|mod|del}, group{add|mod|del} and passwd commands. These commands are not compatible with Kerberos or LDAP, so we must look elsewhere for user management tools.

Administrative Tools

Kadmin is the Kerberos administrative interface for use over a network. It can be used to create, modify, and delete principals and policies. It authenticates using Kerberos and supports both command-line and interactive use. Kadmin replaces the passwd command in this environment.

Change password utility (CPU) is a user and group management tool that supports an LDAP backend. CPU replaces user{add|mod|del}, and group{add|mod|del}, making it a useful tool in our environment, performing most user and group management tasks.

Kadmin uses the main Kerberos configuration file krb5.conf(5). CPU uses the configuration file cpu.conf. Most of the defaults are sensible; however, be sure to change the connection parameters and directory suffix. See cpu.conf(5) for more information.

Password Policies

The policies feature allows an administrator to set password requirements such as length and number of required character classes. Specific policies may be assigned to principals during creation; if it exists, the policy named "default" is used when no policy is specified. See kadmin(8) for more addpol options:

kadmin -q "addpol -maxlife \"90 days\" -minlength 8 -minclasses 3 default"
kadmin -q "addpol -maxlife \"30 days\" -minlength 12 -minclasses 3 admin"

Users, machines, and services are represented as principals in the Kerberos database. Password and account aging similar to chage is supported, along with some Kerberos-specific options such as pre-authentication. It is recommended to assign each user the default policy, as well as to require pre-authentication. See kadmin(8) for more add_principal options.

The workflow for creating a user account in an environment with Kerberos and LDAP is very similar to creating users on a traditional Unix system. Create the user account with an LDAP-aware tool such as cpu, then create the Kerberos principal. These steps are very similar to creating a user with useradd and setting the password with passwd. Principals with an administrative instance typically do not require an LDAP user account because these principals are reserved for Kerberos administrative tasks only:

cpu useradd travis
kadmin -q "addprinc -policy admin travis/admin"
kadmin -q "addprinc travis"

Users come and go, so occasionally user accounts will need to be disabled. The process of disabling an account is similar to the method used with passwd and shadow files. We delete the user's Kerberos principal to prevent password-based authentication and change the user's shell to /sbin/nologin to prevent authentication with SSH keys. This method preserves a record of the user and ensures the uid is not reused. Remember to remove all principals for the users, such as their principal with an administrative instance:

kadmin -q "delprinc travis"
cpu usermod -s /sbin/nologin travis

MIT Kerberos Site -- http://web.mit.edu/kerberos/

RFC 1510 (Kerberos specification) -- http://www.ietf.org/rfc/rfc1510.txt

Kerberos FAQ -- http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

Heimdal -- http://www.pdc.kth.se/heimdal/

Fedora -- http://fedora.redhat.com/

comp.protocols.kerberos -- http://www.google.com/groups?group=comp.protocols.kerberos

Needham, R., and M. Schroeder. "Using Encryption for Authentication in Large Networks of Computers." Communications of the ACM, 21(12):993-999.

Carter, Gerald. 2003. LDAP System Administration. O'Reilly & Associates.

RFC 2251 (LDAP specification) -- http://www.ietf.org/rfc/rfc2251.txt

Linux-PAM System Administrator's Guide -- http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html

Linux-PAM Module Writer's Guide --http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_modules.html

Garman, Jason. 2003. Kerberos: The Definitive Guide. O'Reilly & Associates.

Howes, T., M.G. Smith, and G.S. Good. 2003. Understanding and Deploying LDAP Directory Services, 2nd Ed. Addison-Wesley.

Change Password Utility -- http://cpu.sourceforge.net/

Travis Crawford is a Systems Administrator at Google, where he works with large Linux clusters, and recently a graduate of the Rochester Institute of Technology where he studied Information Technology. He can be reached at traviscrawford@gmail.com.