In“Secure your network with Kerberos: Installing and configuring,” I took a preliminary look at what Kerberos can do for your home or office network in terms of securing it both from within and from the outside. We learned how to build and install Kerberos by downloading the source code, and we configured the master Key Distribution Center (KDC). In this Daily Drill Down, I’ll look at Kerberos principals and show you how to use Kerberos in your day-to-day applications.
Kerberos uses the term principals to identify users or hosts so that Kerberos can properly assign tickets. A principal is typically divided into three parts:
- The primary
- The instance
- The realm
The format for a Kerberos principal is primary/instance@REALM. You can think of principals as advanced usernames for your Kerberos realm.
The primary is the first part of the principal. In the case of a user, the primary is the same as the user's username. In the case of a host, the primary is the word host.
The instance is an optional string that qualifies the primary. The instance is separated from the primary by the slash (/) character. In the case of a user, the instance is usually nonexistent, but it may exist if the user has an additional principal. You may have a user with one principal of his or her username, which is used for everyday operations, and another principal with an instance called admin, which is used to administer a database. For example, the principal joe@EXAMPLE.COM is very different from joe/admin@EXAMPLE.COM. Each has a separate password and separate permissions. In the case of a host, the instance is the fully qualified domain name (FQDN) of the host—for example, zeus.example.com.
Finally, the realm is the defined Kerberos realm. Continuing with our example, the realm would be EXAMPLE.COM. Kerberos realms are typically the network's domain name in uppercase letters.
Two example principals are:
The first is the user root with the instance admin. When you run the /usr/kerberos/kadmin.local program as the user root, you are actually logging in with the principal root/admin@REALM. The second principal is the host zeus.example.com.
Kerberos privileges and access control lists
In the first part of this series, we briefly touched on the access control list (ACL) in Kerberos. The ACL we defined was included in the file /var/kerberos/krb5kdc/kadm5.acl and contained:
This ACL basically granted all privileges to any principal with an instance of admin. This means that anyone, whether named root/admin or joe/admin, will have all privileges where the database is concerned.
You may, however, decide to grant different privileges to various users. Perhaps you want a user to be able to view the principals without changing them, or perhaps you want one user to be able to administer all non-admin instance accounts. Understanding the ACLs is the key to manipulating user access to the Kerberos database. The only place you need to worry about ACLs is in your /var/kerberos/krb5kdc/kadm5.acl file. You can use the following ACLs to specify strict access to your Kerberos database:
- a—Allows the addition of principals or policies in the database
- A—Prohibits the addition of principals or policies
- d—Allows the deletion of principals or policies
- D—Prohibits the deletion of principals or policies
- m—Allows the modification of principals or policies
- M—Prohibits the modification of principals or policies
- c—Allows the changing of passwords for principals
- C—Prohibits the changing of passwords for principals
- i—Allows inquires to the database
- I—Prohibits inquires
- l—Allows the listing of principals and policies
- L—Prohibits the listing of principals and policies
- * all privileges (Uses the admcil arguments from above)
- x all privileges (Uses the admcil arguments from above)
By making good use of ACLs and principals, you can allow some people to manage certain groups of users. For instance, if you were the head administrator of the network and you used the principal fredadmin, you’d give yourself access to all aspects of the database by using:
Now suppose you had a principal, cathy@EXAMPLE.COM, who acted as an administrator in your absence. You trust Cathy to some degree, so you give her access to change principals and policies, but you don't want her to be able to change passwords for principals. Because you also don't want Cathy to be using her cathy@EXAMPLE.COM principal for this, you create a new principal for her called cathy/admin@EXAMPLE.COM. To allow Cathy to do what she may need to do in your absence, you’d add the following to your acl file:
Notice that we have given Cathy an ACL of admil and have omitted the c ACL. You could have easily rewritten the ACL to be more specific and used admilC to explicitly deny her access to change passwords for principals. Now suppose you want to change this even further, and you want Cathy to be able to run those administrative commands only over a certain instance of user. For example, you want her to be able to use those commands only on other instances of admin. This will prevent Cathy from tampering with regular user accounts and allow her to deal only with other administrator accounts like herself. In that case, you’d use:
cathy/admin@EXAMPLE.COM admil */admin@EXAMPLE.COM
Now Cathy can make changes only to principals or policies in the database and only on principals with the instance admin.
Kerberos is pretty straightforward. Because of its transparent nature, using Kerberos should be no more difficult for the end user than using his or her Linux system. The only real drawback to Kerberos is that you must use Kerberos-enabled programs to realize the full effectiveness of the security it provides.
Before you can begin using Kerberos effectively, you must add users to your Kerberos database. Unless you do this, these users will be able to log in to only a local computer and not in to the Kerberos realm, which means that they cannot take advantage of any of Kerberos’ benefits. On the master KDC, load the kadmin program by using these commands:
./kadmin _p admin/admin
You should now add the users on your network to the Kerberos database. Remember, we’re using principals here, so the rules are somewhat different. To add the user joe to the database, at the kadmin: prompt you’d enter:
This is the most generic and default way of adding a new principal. Of course, you can specify many other items when adding a new principal that provide you with more control over your network configuration. You can use these switches to specify when the principal will expire, when the principal’s password will expire, the principal’s maximum ticket life, and so on. For more information on the various switches you can use with the addprinc command, review the Kerberos V5 System Administrator's Guide. Here's one quick example:
addprinc joe _expire "12/25/2001 06:00pm MST"
This would create the principal for the user joe but would also expire the principal on Dec. 25, 2001, at 6:00 P.M. MST.
You can also specify policies with principals. Policies are sets of rules that deal with password management. Policies can dictate both the minimum and maximum lifetime of passwords, the minimum number of characters a password must contain, and how many old passwords are stored in the database to prevent a user from reusing them.
To add a new policy, use the add_policy command in kadmin. This will require the add administrative privilege (which your admin/admin principal will have). For example, you could set up a new policy called fulltime like this:
add_policy —minlife “10 days” —maxlife “60 days” —minlength 8 —history 3 fulltime
What this does is create the fulltime policy with the following options: The minimum lifetime of a password must be 10 days, but the maximum lifetime of a password must be 60 days. The minimum length of passwords allowed is eight characters, and the last three passwords will remain in the database so that the user cannot reuse them. This means that when users change their password, they cannot make another change for at least 10 days, and they will be forced to change their password if they have not done so in 60 days.
Now, if you had defined this policy prior to adding the joe principal, you might have used the addprinc command like this:
add_princ joe —policy fulltime
Remember, all of these commands must be run within the kadmin program itself and not on the Linux command line.
There are a number of different ways you can specify principals, and to detail each of them is beyond the scope of this Daily Drill Down. The Kerberos V5 System Administrator's Guide gives a clear and concise list of the various options you can use when adding or modifying principals.
Kerberos is a single-sign-on system—which means that you have to type your password only once to have access to the network using Kerberos (assuming that you use a Kerberos-aware login program like /usr/kerberos/sbin/login.krb5). If you use your standard Linux login program (typically /bin/login), you’ll have to use the /usr/kerberos/bin/kinit program to log in to the Kerberos realm and obtain your first ticket, which establishes your identity.
The first thing that you need to do as the network administrator is edit the /etc/profile file on each Kerberos system. It may contain a PATH statement similar to:
You’ll want to change this to:
This command places the /usr/kerberos/bin directory at the beginning of your search path, so when you call a program like telnet, you use the Kerberos telnet instead of the non-Kerberos telnet by default. Not only does it make the single-sign-on system more transparent, but it makes it easier to use Kerberos applications instead of their insecure counterparts.
To illustrate this point, a typical login scenario using a non-Kerberos-aware login program might be the following:
zeus login: joe
[joe@zeus /home/joe]$ kinit
Password for joe@EXAMPLE.COM:
Now you are logged in to the Kerberos realm. By using some of the programs that come with Kerberos, namely rlogin, telnet, ftp, rsh, rcp, and ksu, you can remotely connect to another Kerberos host in the realm without retyping your password. These commands take precedence over their corresponding non-Kerberos commands (rlogin, telnet, ftp, rsh, rcp, and su, respectively) because you have placed the /usr/kerberos/bin directory at the beginning of your PATH in /etc/profile.
Now when users telnet into a machine on the network, they will not be prompted for a password provided they have a valid ticket. The ticket granted by logging in with kinit is used to negotiate authentication (instead of a password) and to optionally encrypt the communications with the remote host. The only difference between using the Kerberos telnet versus the non-Kerberos telnet will be that you do not need to enter your password. The same goes for any other Kerberized service.
For more information on the clients that come with Kerberos, be sure to read the Kerberos V5 UNIX User's Guide, which can be found in your /usr/local/src/DIST/krb5_1.2.1/doc directory or in the doc/ directory where you un-archived the copy of Kerberos you downloaded.
System clock synchronization
Kerberos is very sensitive to timing issues. Kerberos systems cannot have a time difference (also called time skew) of greater or less than five minutes. This is done to prevent problems with ticket-granting services. You’ll need to closely synchronize all computers utilizing Kerberos on your network so that they are no farther apart than five minutes. To accomplish this, you may want to look at setting up a Network Time Protocol (NTP) server and have each client machine synchronize their system clocks with the NTP server. A good NTP server is XNTP. Clients would then use a program like rdate to synchronize the time.
Kerberos is an advanced security protocol available for a variety of operating systems. Using Kerberos in a network is desirable—and with good reason. Due to its advanced authentication and encryption schemes, Kerberos can reliably secure your local or wide area networks. And because of the cross-platform capabilities, it can easily be used in heterogeneous networks.
Before deciding whether to use Kerberos in your network, you must be aware of one thing: Kerberos is an all-or-nothing solution. You cannot install and use Kerberos and continue to use insecure applications and expect your network to be secure. For Kerberos to do its job, everything needs to be built with Kerberos support. This can be awkward and time-consuming, especially if the program in question does not have Kerberos support to begin with. Therefore, many system administrators have decided not to use Kerberos at this point. While it provides protection for many frequently used protocols such as ftp, telnet, and the "r" suite of utilities, it isn’t comprehensive enough for some.
Considering that you can protect these services by using the utilities Kerberos comes with, it makes little sense to use an e-mail client or server that does not support Kerberos or any other client/server service you may install. Perhaps you are using ProFTPD for your ftp server and do not want to change it to another ftp server that provides Kerberos support. These are things to consider as well.
There are many options and tools available for securing your network. In this Daily Drill Down, I’ve discussed merely one option—Kerberos—in a list of many similar options. You can easily use SSH for more than a secure login or transfer of files. With SSH's ability to forward ports, perhaps it would be more suited for your particular needs. And, of course, don’t forget SSL. More and more applications are coming out with SSL support to encrypt client/server traffic.
Once again, it all boils down to choice and your specific desires for the network. Where there are few Kerberos-enabled applications available beyond what is provided with Kerberos itself, there is the benefit of single-session authentication. Kerberos provides enough flexibility that, in time and with some effort, more applications can be Kerberized. And because many clients are readily available for most operating systems, it can become a more popular network authentication system than any similar systems currently available.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.