Computing Facilities    links to the SCS and CMU home pages Carnegie Mellon School of Computer Science Carnegie Mellon University
 
Advanced search tips 
 
 » Introduction to Facilities 
 » Accounts & passwords 
 » AFS 
 » Application software 
 » AV help 
 » Backups & restores 
 » Calendaring 
 » E-mail 
 » Networking 
 » Printing 
 » Purchasing 
 » Resource management 
 » Security 
 » Software licensing 
 » Support charges 
 » Web publishing 
 » Mac support 
 » Linux support 
 » Windows PC support 

Kerberos

Kerberos is a network-based authentication system that is used by many SCS programs (login, ssh, rsh, our POP3 mail daemons, and others) to provide secure authentication. We use Kerberos because it provides a degree of protection against network snooping and other attacks, and allows one to use a single password for logging in to multiple hosts (and instance passwords for other tasks).

Authentication & tickets

When you type your password at a service that uses Kerberos (for example, you login to a Facilitized Unix host), your password is used to verify to the Kerberos server that you are who you say you are. This is done in a way that does not send your password over the network. Once your identity is verified (i.e. you typed in the correct password), the Kerberos server sends back a ticket. Tickets have limited lifetimes and are used as credentials to obtain services or additional tickets.

Kerberos principals, instances, and realms

Any ticket is assigned to a unique principal. A Kerberos principal consists of three parts:
primary
For users, this can be considered to be the same as your SCS Unix userid (e.g. "bovik").
instance
A way to "qualify" the primary. For example, in SCS common instances are mail, remote, and root.
realm
A Kerberos realm corresponds to an organizational unit and associated Kerberos database. It is usually written in uppercase (and is case sensitive). The SCS Kerberos realm is CS.CMU.EDU.

Principals are written in full as:

   primary/instance@REALM
For example:
   bovik/mail@CS.CMU.EDU

In some cases, one might see them written with a "." instead of a "/"; this was the syntax for the the previous version of Kerberos (note that the AFS fs will only accept instance names that use a "." when adding such instances to AFS ACLs). In many cases the realm is omitted, since it defaults to the realm that the machine you are using belongs to.

Security & Kerberos

One way Kerberos adds to security is that the process of getting a ticket from the Kerberos server does not send your password over the network. However, Kerberos does not protect against other forms of attack, such as somebody sniffing your keystrokes or snooping non-encrypted traffic between you and the process that you are authenticating to.

For example: Suppose your e-mail gets delivered to UX1 and you use Netscape on your PC to read it, giving your /mail Kerberos instance password as your password. In that case:

  • The /mail instance password is sent over the network in the clear by Netscape, and can be snooped.
  • Once the password gets to UX1, UX1 uses Kerberos to verify the password using Kerberos, and this traffic between UX1 and the Kerberos server is not vulnerable to getting snooped.

One reason we make use of different Kerberos instances, such as /mail, is to minimize the your risk in case your /mail instance password gets snooped from the network.

Types of Kerberos instances

The following Kerberos instances are commonly used in SCS. Each instance has it's own password. It is important that the passwords for these instances be different from the password for one's main Kerberos principal.
mail
The password for this instance is used to read mail via the POP3 servers on our UX mail hubs or via our IMAP server.
root
The password for this instance is used to gain root access on hosts that one administers. See the Local Unix administrators guide for details.
remote
This instance and password are needed to use our VPN software.
maildelivery
This instance is used to be able to file mail directory into directories in AFS.

How to create Kerberos instances and change their passwords

Note: The primary SCS interface for managing Kerberos instances is the interactive, Web-based instance manager. If you prefer a command-line interface, you can run remctl on any Facilitized Unix host.

Use the web-based Kerberos Password Change interface to change the password of your Kerberos null instance: https://webiso.cs.cmu.edu/password

Use the web-based Instance Manager interface to manage/change passwords on your Kerberos instances: https://webiso.cs.cmu.edu/instance

Note: See the Instance Manager help pages for more information on this interface and its functionality. If you need other instances created for some special use, contact the SCS HelpDesk, <help@cs.cmu.edu> or x8-4231.

If you have forgotton your primary Kerberos password or your /root instance password, you must stop by the SCS HelpDesk with a photo ID to have them changed.

How to authenticate to Kerberos

When you authenticate to the Kerberos server, you receive limited-lifetime credentials that programs then use to prove your identity when you request services.

To authenticate on Facilitized Unix hosts

The kinit command, located in /usr/local/bin is used to authenticate to Kerberos on Facilitized Unix hosts. For example, the command:

   kinit bovik

would prompt you for the SCS Kerberos password for the userid "bovik" and authenticate you if you give the correct password. You can use the same command to authenticate as a Kerberos instance, for example: "bovik/root". The klist command is used to list the Kerberos tickets that one has.

To authenticate on a Windows PC

Kclient is the Kerberos authentication program on Windows. It can be obtained from our software distribution server Monolith in the "pc_dist\mit" folder, and should already be installed on most SCS PCs as part of the Facilities baseline Windows environment.

To use Kclient, select the small key icon on your system tray. If you use a Kerberized telnet client such as NiftyTelnet, you will automatically be prompted to authenticate. Note that you should not use the Kclient "Change Password..." feature in the SCS environment.

How to troubleshoot common Kerberos problems

Some common reasons for Kerberos authentication problems are:
The host cannot reach the Kerberos servers.
Kerberos authentication to the CS.CMU.EDU realm requires that the host be able to communicate over the network with our Kerberos servers, kerberos-1.srv.cs.cmu.edu and kerberos-2.srv.cs.cmu.edu.
The time on the client host is wrong.
To prevent reply attacks, the time on the client must be within a few minutes of the time on the Kerberos server.
The client host is out of disk space on /.
Facilitized Unix hosts use the directory /tkt to store ticket files. If / is full, you will receive an authentication error.
The client host is in the wrong realm.
Client hosts will try to authentication in a default realm, if one is not explicitly given. Try giving an explicit realm when you authenticate, e.g. bovik@CS.CMU.EDU.

If you have trouble accessing a Kerberized service that you had previously authenticated to, you should check to see if your tickets have expired. Kerberos tickets have limited lifetimes for security reasons. You can use the klist program to list your tickets and their expiration dates, and the kinit program to re-authenticate.

Related documentation

SCS Computer Security
How to compute securely in SCS and protect yourself from break-ins.

Additional information

The following off-site links will open in a new browser window:
MIT Kerberos page
Extensive documentation and source code for MIT kerberos.
Heimdal
A free implementation of Kerberos 5.