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 realmsAny ticket is assigned to a unique principal. A Kerberos principal consists of three parts:
- For users, this can be considered to be the same as your SCS Unix userid (e.g. "bovik").
- A way to "qualify" the primary. For example, in SCS common instances are mail, remote, and root.
- 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:
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.
- The password for this instance is used to read mail via the POP3 servers on our UX mail hubs or via our IMAP server.
- The password for this instance is used to gain root access on hosts that one administers. See the Local Unix administrators guide for details.
- This instance and password are needed to use our VPN software.
- This instance is used to be able to file mail directory into directories in AFS.
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, <firstname.lastname@example.org> 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.
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:
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 problemsSome 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.
- SCS Computer Security
- How to compute securely in SCS and protect yourself from break-ins.