Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use

From WikiContent

Jump to: navigation, search
(Initial conversion from Docbook)
Current revision (23:06, 11 March 2008) (edit) (undo)
(Initial conversion from Docbook)

Current revision

Linux in a Windows World

The Kerberos protocol, the third network authentication tool described in this book, is named after the three-headed dog from Greek mythology, which guarded the entrance to the underworld. Like its mythological namesake, the modern Kerberos is a gatekeeper. Its principles and the problems it solves are different from those of NT domains and LDAP, though, which means that Kerberos's best areas of application are also different. Broadly speaking, Kerberos works best as a way to manage logins to multiple systems using multiple protocols; Kerberos provides single-sign-on capabilities that aren't well matched by competing protocols. As with NT domain configurations, Kerberos requires software on three classes of systems: the main Kerberos server; Kerberos application servers which are servers for other protocols that defer to the Kerberos server for authentication; and clients of the application servers. You can use either Linux or Windows in any of these roles, although not all combinations work equally well. Some Microsoft application servers and clients, in particular, don't work as well with Linux Kerberos servers as with their Microsoft counterparts. This chapter presents Kerberos first from a Linux perspective and concludes with Windows-specific information.


This chapter emphasizes setting up the basic Kerberos environment, using a few Kerberized tools that come with Kerberos, and configuring basic login authentication via Kerberos. It can be used for more protocols, though, such as providing single-sign-on for POP email retrieval. Going beyond the protocols provided with the Kerberos package requires installing additional software.


Kerberos Fundamentals

Kerberos is a centralized login tool. This statement, although true, is deceptively simple. Kerberos was designed to solve certain authentication problems that aren't easily handled by other protocols. Understanding these problems, and how Kerberos solves them, will help you configure a Kerberos server, as well as determine whether you want to do so. You'll also have to decide what Kerberos software you want to run, both in terms of the server itself and the Kerberos application servers and clients you'll run with it. Many of these decisions are likely to be Linux-centric, but depending on your needs, chances are you'll need to make Windows-related Kerberos decisions, as well.

The Problem: Centralized Single-Authentication Logins

Large local networks are likely to host many servers. This arrangement makes centralized authentication tools, such as NT domains and LDAP, desirable. However, centralizing login control in one server is just part of the answer. Kerberos was actually designed to meet three major needs:

Centralize authentication
The most fundamental Kerberos design goal is to centralize authentication. This goal is basically the same as the primary goal of NT domains and is one of the many possible functions of LDAP. Kerberos also gives considerable weight to a sort of reverse authentication: providing an assurance to clients that the servers they connect to are the ones they claim to be. This identity verification helps ensure that, for instance, you're actually saving your departmental budget on your real departmental file server, rather than on the laptop of an industrial spy who's pretending to be a photocopier technician.
Protect passwords
One problem with many network protocols that require authentication is that they're susceptible to password sniffing. To be sure, the last few years have seen great strides in this area, with secure protocols such as SSH largely displacing less secure protocols, such as Telnet. Still, Kerberos was designed with a high degree of attention to password security. It's also designed as a tool that can be used by many protocols, so any Kerberized client and server (that is, programs that have been designed to use Kerberos authentication) can gain the Kerberos password security benefits. Many Kerberized applications also provide encryption of non-password data, although this isn't a necessary feature of such tools.
Provide single-login operation
This is arguably Kerberos's most unusual design feature. The idea is that users frequently log into a computer and proceed to use it to access many other computers. You might retrieve your email from a POP server, use a remote login protocol to run programs on another system, upload files to a third computer using FTP, submit print jobs using a printing protocol, and so on. Typing a password for each access becomes tedious at best. To be sure, some tools save your password on disk to mitigate the problem, but this practice is a potential security risk. Kerberos was designed to solve the problem by enabling single logins: once you've authenticated yourself to the Kerberos server, you don't need to do so again with any Kerberos application server that defers to the main Kerberos server.

Of these features, the first two are handled reasonably well by both NT domains and LDAP, although neither really addresses the issue of server authentication for clients. (The NT domain controller and LDAP servers' identities may be authenticated, but other servers are not.) The single-login feature of Kerberos isn't well addressed by either of these alternatives. (Windows caches passwords for file server access, which presents the illusion of a single logon to the NT domain. This caching only helps with certain protocols, though.)

On the flip side, Kerberos wasn't designed with account management at the forefront. In particular, tools for delivering full account information to Linux clients—the tasks performed by NSS in Linux—are lacking in Kerberos. Although you can use Kerberos as part of a workstation login procedure, you need to maintain local accounts using local databases, LDAP, or some other tool.


Microsoft's Active Directory uses LDAP in conjunction with Kerberos. These two tools provide some overlap in function, but they also complement each other very well. Unfortunately, Microsoft's Kerberos implementation is a bit odd and doesn't interact well with some non-Microsoft versions. These matters are described in Section 9.1.4 and Section 9.5.

An Overview of Kerberos Operation

Discussions of Kerberos, like those of LDAP and NT domains, tend to be filled with lots of jargon. Understanding these terms is necessary for understanding how Kerberos works and how to configure it.

The key distribution center is the heart of Kerberos; it's the system that manages Kerberos logins. In other words, it's the Kerberos server. Some networks host multiple KDCs, in which case one is a master KDC, and the others are slave KDCs. For brevity's sake, this chapter describes only master KDC configuration. Slave KDCs are configured in much the same way as their masters, but both master and slave require additional components to propagate the password database to all KDCs.
This adjective describes server or client programs that support the Kerberos protocols. They rely on the KDC for authentication, albeit in an indirect way, as described shortly. They can often also authenticate users in more conventional ways as a backup to their Kerberos functionality.
Kerberos application server
An application server runs Kerberized servers.
Kerberos client
This term refers to any computer that obtains a ticket (described shortly) from a KDC. Normally, the Kerberos client is a client program run by a user.
A Kerberos realm is the range of the KDC's responsibility. Kerberos realms are often named after DNS domains or subdomains, but realm names are case-sensitive and are conventionally uppercase. For instance, if you're configuring a Kerberos system for the domain, you'd probably call the realm EXAMPLE.COM. The realm need not correspond exactly to the domain, though; it can include or exclude specific computers, as you see fit.
Tickets are at the heart of Kerberos authentication. A ticket is an encrypted hunk of data that's passed between systems as a mode of authentication. Most tickets are encrypted using a password, meaning that proper encryption of the ticket is proof of the ticket's validity.
A ticket-granting ticket is a special type of ticket that can obtain additional tickets. The KDC delivers a TGT to a user; the Kerberos client tools use the TGT to request tickets for accessing specific servers.
The ticket-granting service is the KDC subsystem that's responsible for granting TGTs.
A Kerberos principal is a user or server identification. Principals take the form primary/instance@REALM, where primary is a name (frequently a username), instance is an optional expansion that enables one user to have multiple principals, and REALM is the realm name. For instance, fluffy@EXAMPLE.COM is a possible principal for the user fluffy on the EXAMPLE.COM realm. Administrators frequently have a secondary principal with the instance name of admin, so if fluffy were an administrator, the account's administrative instance would be fluffy/admin@EXAMPLE.COM. Principals for application servers are named after the server, as in telnet/ for the Telnet server on Computers that run application servers also require principals, on which the primary name is host, as in host/ Much of the administrative work of running Kerberos involves managing principals.

The fact that Kerberos is reliant on tickets makes its operation a bit different from that of most other network authentication tools, although many details can be hidden from users. In broad strokes, the system works like this: the user requests a TGT from the KDC, which delivers the TGT to the Kerberos tools on the user's system. When the user then initiates a connection to an application server, the Kerberos utilities on the client pass the TGT back to the KDC along with information on the server the user wants to connect to. The KDC replies with a new ticket, which is encrypted with the application server's password. This ticket includes the username and other relevant information. The user's system then forwards this ticket to the application server, which knows the ticket is valid because it's been encrypted with its own password (which is known only to the application server and the KDC). At this point, the user is authenticated to use the application server, and the session can proceed much as it would with a more direct username/password exchange. (The application server can, of course, apply its own local security rules to limit access on a user-by-user basis, up to and including denying specific users access even if they've been authenticated by the KDC.)


Kerberos tickets include time stamps, and they expire after a limited period of time, which varies depending on your Kerberos options and the type of ticket. Thus, if a computer's clock is set incorrectly, it may not be able to authenticate on a Kerberos network. For this reason, if you use Kerberos, you should also use a network clock-setting tool to ensure that your systems' clocks are all set correctly. Chapter 15 describes one tool you can use for this purpose, the Network Time Protocol.

In practice, and from a user's point of view, using Kerberos involves two operations: authentication with the KDC and accessing servers. Tools for the former, and for managing Kerberos sessions, are described in Section 9.4.3. Some tools can integrate KDC authentication with a desktop system's basic login, so the process can be quite seamless from a user's perspective. Still, the focus for Kerberos is on providing centralized network accesses, whereas the focus for LDAP, and to a lesser extent NT domains, is in providing centralized authentication for desktop logins. This distinction can be subtle, but is important in understanding when and how to deploy Kerberos, as opposed to other tools. Kerberos is best suited to environments in which users must frequently access a variety of password-protected servers for which Kerberized variants are available. Kerberos is less useful in environments in which users log into their desktop systems and then seldom need to access other password-protected computers. For desktop authentication alone, LDAP or NT domains do a better job. (NT domain logins, particularly for Windows desktop systems, also provide the illusion of password-less access to file and printer shares, but not to most other types of servers.)

Kerberos Tools for Linux

One of the difficulties with Kerberos is in deciding which Kerberos to use. Broadly speaking, Kerberos packages can be classified as V4 or V5, V5 being the latest. Linux implementations of both versions include:

MIT Kerberos
Kerberos originated at MIT, and so many people consider the original MIT Kerberos to be the standard. You can peruse its official web site,, and download it from there. Kerberos is available in source code form and as binary packages for several OSs, including Linux, Windows, and Mac OS (both pre-X and X versions). MIT's Linux binaries, though, are available only in the form of a tarball. The latest version, 1.3.5, is a Kerberos V5 implementation.
This version of the Kerberos V5 protocol is hosted in Sweden, at This site hosts source code and some binary packages, including versions for Linux, Solaris, DEC Unix, and Mac OS X. Version 0.6.3 is the latest as I write.
This package, headquartered at, is a Kerberos V4 implementation. It's sometimes released with Linux distributions under a package name such as krb4. As a Kerberos V4 implementation, it's a bit dated, but if your site uses Kerberos V4, you might consider using it. The latest version as I write is Version 1.2.2.

Many distributions ship with one or more of these implementations in binary form. Typically, MIT Kerberos is available under the package name mit-krb5 or krb5, whereas Heimdal is available as heimdal or something similar. Some distributions split the Kerberos package into parts, separating base tools, application servers, and clients. In theory, you should be able to mix and match Kerberos V5 implementations (MIT Kerberos and Heimdal, for instance); however, in practice you may find it easier to stick to a single product whenever possible. Problems are most likely to crop up in administrative tools and trying to mix master and slave KDCs of different types; problems between clients and KDCs or application servers are less common. Likewise, cross-OS mixes (using Linux MIT Kerberos clients and a MacOS MIT Kerberos KDC, for instance) should work, although problems sometimes crop up. Because Kerberos V4 is becoming rather elderly and has some protocol security bugs, this chapter describes V5 exclusively.


This chapter uses Heimdal and MIT Kerberos V5 implementations as references. The reference realm's primary KDC runs Heimdal 0.6 on SuSE 9.1, but this chapter describes both Heimdal and MIT Kerberos tools and commands for most tasks.

Linux Kerberos packages ship with several Kerberized servers and clients, including Telnet, rlogin, FTP, rsh, and rcp programs. Subsequent sections of this chapter describe some of these tools in greater detail.

Kerberos was designed to enable just about any protocol that requires authentication to use it. Thus, the list of Kerberized protocols isn't limited to those that ship with the main Kerberos package. If you want to use Kerberos in conjunction with a protocol that's not supported by a client or server that ships with Kerberos, you should search for support elsewhere. Although Kerberos support is far from universal, many clients and servers do support the protocol. Sometimes this support comes in the form of a compile-time option, so you may need to recompile your software to include the Kerberos features. In other cases, you may need to switch from one client or server package to another one. Unfortunately, Kerberos support, although far from restricted to the clients and servers provided with Kerberos packages, is also far from universal; you may need to search long and hard to find Kerberized tools for a particular task.

Windows and Kerberos

In theory, Windows can fit into a Kerberos realm as easily as Linux. In practice, of course, you'll need to learn to configure both Linux and Windows; configuration file locations and the like will differ between the two platforms. You might also run into compatibility problems related to specific Kerberos implementations.

Of particular note along these lines is the fact that Windows 2000 and later ship with AD support, and AD includes Kerberos as one of its components. Microsoft, however, implemented Kerberos in a slightly different way than did other providers. Some notable areas of divergence include:

Encryption algorithms
For political and technical reasons, Microsoft chose to support a different set of encryption algorithms than did the versions of Kerberos available in 2000. The practical upshot of this decision is that, if you use an AD controller as your KDC, you must either enable Data Encryption Standard (DES) encryption on the KDC and change users' passwords or use a recent version of Kerberos (such as MIT Kerberos 1.3 or later) on the non-Microsoft systems.
Perhaps the biggest Windows/non-Windows Kerberos compatibility issue is the Privilege Access Certificate (PAC). This is an extra field added to tickets returned by a Windows KDC. Microsoft's own Windows clients typically refuse to work with a KDC that doesn't return a PAC, which makes interoperating with a Linux KDC difficult, for example. Microsoft developed the PAC in a proprietary way, but in late 2003 some documentation on the PAC became available, so this problem is also fading in importance. Fortunately, non-Microsoft Kerberos implementations typically ignore the PAC, so Linux Kerberos application servers and clients should be able to operate with a Windows KDC.
Cached credentials
Windows systems cache their login credentials as a way of supporting logins on laptops or in case of a KDC or network failure. Ordinarily, this practice poses no problems, but if a user logs on using a cached credential and a non-Microsoft KDC then becomes available, the system isn't likely to notice the KDC, resulting in an inability to access network resources.

Overall, using Microsoft's own KDC as your network's KDC in conjunction with Linux application servers and clients works well. If you're using older Kerberos implementations, though, you may need to enable DES support and then change users' passwords so that the new password is encoded in DES form. This step shouldn't be necessary with recent Kerberos V5 implementations for Linux, though. (If in doubt, check whether the Kerberos implementation supports the RC4-HMAC encryption algorithm.) For the most part, the details of administering a Windows KDC are beyond the scope of this book.

Using Windows clients with a non-Microsoft KDC is a bit trickier, but it is possible. You must create local Windows accounts on the Windows system for your users and use special tools to configure Windows to use the KDC for authentication. This process is described later in this chapter, in Section 9.5.3. Alternatively, you can install a non-Microsoft Kerberos package and run it without using Kerberos for logon authentication. Instead, you'd use regular Kerberized clients and servers under Windows, much as you would their equivalents under Linux.

Linux Kerberos Server Configuration

The single most complex task when you implement Kerberos on your network is to set up the Kerberos server—the KDC. To do this, you start by editing a server configuration file. This isn't the end of the job, though. You must also create a master key, which is used to encrypt the KDC's communications. Practical use of a Kerberos realm also requires such administrative tasks as creating principals and configuring access control rules. Finally, you must run the Kerberos servers (the main server and, typically, a separate administrative server).

Kerberos Realm Configuration

MIT Kerberos uses two configuration files: krb5.conf and kdc.conf. Heimdal, though, dispenses with the latter file, so you needn't be concerned with kdc.conf if you're configuring Heimdal. The krb5.conf file contains assorted information about your realm and the server's operation, while the kdc.conf file contains KDC-specific information.


Application servers and clients need to know much of the realm information in krb5.conf, and so these systems use this file, as well, although some sections are missing or ignored on these systems.

Editing krb5.conf

The KDC's main configuration file is called krb5.conf. If you install Kerberos from a package, chances are this file will reside in /etc. A sample krb5.conf file appears in Example 9-1.

Example 9-1. Sample krb5.conf listing

 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 ticket_lifetime = 28800
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false

  kdc =
  admin_server =
  default_domain =

[domain_realm] = EXAMPLE.COM = EXAMPLE.COM

This file is broken into sections, with each section denoted by a section name within square brackets ([ ]). Most options span a single line and consist of an option name followed by an equal sign and its value. Some, though, use compound values, which themselves span multiple lines. These are denoted by curly braces ({ }), as in the EXAMPLE.COM item within the [realms] section. Many of the krb5.conf parameters are self-explanatory, but some deserve additional elaboration:

Logging options
The options in the [logging] section tell the server where to log data related to Kerberos operation. This section is not required for application server and client installations, just for KDCs.
Ticket lifetime
The ticket_lifetime option sets the default lifetime for most tickets issued by the KDC, in seconds. The value of 28800 shown in Example 9-1 corresponds to eight hours. A too-long lifetime increases the risk of security breaches caused by stolen tickets, while a too-short lifetime will be inconvenient for users because they have to reinitialize their Kerberos sessions.
Default realm
The default_realm option sets the realm that the KDC is to manage. This is likely to be named after your DNS domain name, but it doesn't have to be.
DNS lookup options
The dns_lookup_realm and dns_lookup_kdc options tell Kerberos to use DNS to help locate systems.
Realm definitions
The [realms] section defines realms. In Example 9-1, one realm is defined: EXAMPLE.COM. This definition includes pointers to a single KDC and one administrative server. (If your realm has slave KDCs, they're defined just like the master, using a kdc line.) The administrative server handles administrative functions, such as adding principals; it's normally the same as the master KDC. These definitions include port numbers—88 for the KDC and 749 for the administrative server. The default_domain option specifies the DNS domain name that's associated with Kerberos principals, when appropriate. A single krb5.conf file may define multiple realms. In such cases, you'd define each in its own set of lines, in a single [realms] section.
Domain/realm mapping
The [domain_realm] section specifies a mapping of computers to realms. In Example 9-1, all computers in the domain and the computer are included in the EXAMPLE.COM realm. Subdomains are indicated by a leading dot (.); entries lacking this dot are interpreted as referring to individual computers.

In addition to the entries shown in Example 9-1, MIT Kerberos is likely to have an additional section that points to the kdc.conf file:

  profile = /var/kerberos/krb5kdc/kdc.conf

You may also see a section called [appdefaults] in sample configuration files. This section modifies settings for individual application servers and clients. For instance, you might increase or decrease a ticket lifetime based on the likely session length for a particular service.

Editing kdc.conf

MIT Kerberos implementations typically place some KDC options in a separate file, called kdc.conf, which are referred to by a profile option in the [kdc] section of krb5.conf. Example 9-2 shows a typical example of this file. You should leave most of these options alone, but you can change the name of the Kerberos realm on the first line of the [realms] section to match your needs. The master_key_type and supported_enctypes options relate to the encryption methods that Kerberos supports.

Example 9-2. Sample kdc.conf listing

 acl_file = /var/kerberos/krb5kdc/kadm5.acl
 dict_file = /usr/share/dict/words
 admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
 v4_mode = nopreauth

  master_key_type = des-cbc-crc
  supported_enctypes = arcfour-hmac:normal arcfour-hmac:norealm 
des3-hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal 
des-cbc-crc:normal des-cbc-
crc:v4 des-cbc-crc:afs3

Creating a Master Key

Because of the high priority Kerberos places on security, it uses a cryptographic master key to control access to itself. Without this key, Kerberos won't start. The key is generated from a password, and it's possible to store this password in a stash file . Using a stash file, Kerberos can start automatically when the computer boots; without a stash file, you must enter a password whenever you start the server.

In Heimdal, the utility to create a master key and a stash file is called kstash . (Heimdal actually creates a single file for both purposes.) To perform this task, type this command:

# kstash
Master key:
Verifying - Master key:
kstash: writing key to `/var/heimdal/m-key'

As with most utilities that ask for passwords, kstash doesn't echo the password you type. MIT Kerberos uses another utility, kdb5_util, to create its master key and stash file:

# kdb5_util create -r EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:


The master key, stash file, and password are all extremely sensitive. The utilities should create files with appropriate permissions to protect them (typically 0600), at least assuming the Kerberos server isn't compromised. You should be extremely careful to both remember the password and not let it fall into unauthorized hands. Pick a password that's as close to a random collection of letters, digits, and punctuation as possible without running the risk of forgetting it, and don't re-use this password for any other account or server.

Realm Administration

At this point, your KDC is nearly ready to be used; however, you must still set up principals and define access control rules. Both tasks are critical for normal Kerberos operations. In fact, you're likely to return to these tasks, and particularly principal creation, many times in the future.

Creating principals

Principals are, essentially, Kerberos accounts. Kerberos requires certain principals in order to function, and you'll presumably want to create principals for your ordinary users. This section describes both tasks. Application servers also require principals, but this task is described in Section 9.3.2.

Kerberos provides a tool called kadmin to manage principals. Ordinarily, this tool connects to the Kerberos administrative server (specified by the admin_server option in krb5.conf) to manage principals. At this point, though, this server isn't running because it's not yet fully configured, so you must create principals without using this server. In Heimdal, this task is accomplished by passing the -l option to kadmin. In MIT Kerberos, you use a variant command, kadmin.local . In Heimdal, the interaction for initializing the realm looks like this:

# kadmin -l
kadmin> init EXAMPLE.COM
Realm max ticket life [unlimited]:
Realm max renewable ticket life [unlimited]:
kadmin> add admin/admin@EXAMPLE.COM
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes [  ]:
admin/admin@EXAMPLE.COM's Password:
Verifying - admin/admin@EXAMPLE.COM's Password:

The init command initializes the Kerberos database; it should be the first command you type when you use this program for the first time. The add command adds a principal for the administrative user. (You can use other primary and instance names if you like, though the principal should be in your realm.) If you're using MIT Kerberos, there's no need to begin with the init command, and the add command is called addprinc . You do, however, need to use the ktadd command to prepare a keytab, which is a special key Kerberos uses to handle administrative principals:

kadmin.local: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab 
kadmin/admin kadmin/changepw

The system should respond with a rather verbose report concerning the creation of the keytab files.

Whether you're using Heimdal or MIT Kerberos, you might want to take the time now to create at least one or two test accounts. These accounts might not have instance names for simplicity's sake. You can also omit the realm name, if you're adding a principal to your default realm:

kadmin> add fluffy

Heimdal is more verbose in the questions it asks at this point, and you can select the default for most of these. Whichever server you're using, though, you'll have to enter a password.


Once you've started the KDC and the kadmind server, you can use kadmin to administer the server remotely, with one caveat: you can't use the kadmin from MIT Kerberos to administer a Heimdal server or vice versa; the administrative protocols aren't compatible.

ACL definitions

Kerberos uses ACLs to determine who may access the server (that is, kadmind, not the KDC as a whole) and in what ways. Kerberos ACLs are conceptually similar to filesystem ACLs, but they're not identical, nor do they rely on filesystem ACLs. Kerberos ACLs are defined in a special ACL file. In Heimdal, this file is normally /var/heimdal/kadmind.acl; in MIT Kerberos, it's the file pointed to by the acl_file entry in kdc.conf. (You can specify the same parameter in a [kdc] section in Heimdal's krb5.conf file, if you want to use another file in Heimdal.) The ACL file consists of a series of lines, each with two or three entries:

                     Kerberos-Principal  Permissions  [Target-Principal]

The first entry, Kerberos-Principal, is the principal to which the ACL applies—that is, the user whose permissions are being defined. The Permissions string is a collection of one or more letters (in MIT Kerberos) or a comma-separated list of codes (in Heimdal), as summarized in Table 9-1, that define the operations the user can perform. If no third option is present, these permissions apply to all other principals. If a third entry is present, however, it refers to the principals that the first principal may modify in the specified ways. For instance, you might want to give some users the ability to modify certain classes of principals but not others.

Table 9-1. Kerberos ACL permission codes

MIT Kerberos code Heimdal code Meaning
a add Principals or policies can be added.
A - Principals or policies can't be added.
d delete Principals or policies can be deleted.
D - Principals or policies can't be deleted.
m modify Principals or policies can be modified.
M - Principals or policies can't be modified.
c cpw or change-password Passwords can be changed.
C - Passwords can't be changed.
i get Database inquiries can be made.
I - Database inquiries can't be made.
l list Principals or policies can be listed.
L - Principals or policies can't be listed.
x or * all Wildcard for all "can" ACLs (admcil).

In the case of both principal specifications, an asterisk (*) can be used as a wildcard for part of the specification. For instance, you can give all users in the admin instance the ability to do anything in MIT Kerberos:

*/admin@EXAMPLE.COM  *

In MIT Kerberos, an entry similar to this is the default, but you should modify it to point to your realm. You might also want to fine-tune the ACLs to suit your own needs—for instance, providing different groups of administrators different levels of access to the server's administrative functions. In Heimdal, the ACL file is absent by default, so you'll probably want to create it. A failure to create this file means that you can't perform administrative tasks from other systems, including adding principals and extracting keytabs—tasks that are required for adding application servers to a Kerberos realm. (You can still perform these tasks from the KDC itself, but then you'll have to move highly sensitive keytab files to the application server in some other way, such as on a floppy disk or via a network file transfer.)

Running the KDC

The KDC must be run in order to be useful. On most Linux distributions, you can do this by running a SysV startup script:

# /etc/init.d/kdc start

Details vary from one distribution to another, though; the script may be called kdc, krb5kdc, mit-krb5kdc, or something else. You may need to use your distribution's package system or simply peruse your SysV startup scripts to locate the correct script.

Some KDC startup scripts start the Kerberos administrative server along with the KDC server. Others, though, provide a separate script to start the administrative server. This second script may be called mit-krb5kadmind, kadmin, or something else. Again, checking the SysV scripts installed with your package or perusing the startup scripts may be necessary. Normally, you'll want to run the administrative server on the master KDC; without it, your ability to administer your realm from anything but the KDC itself will be limited.

Starting the KDC and administrative server manually is fine for testing, but, in operation, you'll probably want to configure your system to start the servers on a regular basis. On many distributions, the chkconfig command can be used to do this:

# chkconfig --add kdc

Other distributions use other tools to do this job. Consult distribution-specific documentation if you need help with this task.

Kerberos Application Server Configuration

Setting up a master KDC is the most involved part of configuring a Kerberos realm; however, by itself, a KDC doesn't do much good. The next step in this process is to configure one or more application servers. Each application server computer must have a basic Kerberos configuration, which is similar in some details to the KDC's configuration. You must also create principals for each application server and set up appropriate keytabs. Once this is done, you can run the server programs to make them available.

Setting Up Kerberos

Any Linux system that runs a Kerberos application server requires certain basic preparation, some of which is the same as that for the KDC. In particular, you must set up the /etc/krb5.conf file in much the same way, as described in Section You can, however, omit some sections from this file, namely the [logging] and [kdc] sections.

Preparing Application Server Principals

Before you can run an application server, you must prepare principals for the server (both the server computer and the individual server programs). Furthermore, you must install keytabs for these principals on the application server computer.

The first step in this process is to create the principals. You do this much as you do for ordinary users, with the help of the kadmin or kadmin.local command. To simplify the procedure, pass the -r (in Heimdal) or -randkey (in MIT Kerberos) option. This assigns a random password to the principal. Because the password need only be "known" to software on the server computer, this practice should work well. Generally speaking, you must create principals with the instance name of the computer's DNS hostname and primary names of host (for the computer as a whole) and named after each server. Some specific servers don't need their own principals, though. For instance, to enable to function as a Kerberized Telnet server, you can type (using Heimdal's kadmin) the following:

kadmin> add -r host/
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes [  ]:
kadmin> add -r telnet/
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes [  ]:


The Kerberized Telnet server doesn't need its own principal. Thus, you can still run it if you omit the second add command in the preceding example.

With the principals created, you must then extract them to a keytab file. You do this with the ext_keytab (Heimdal) or ktadd (MIT Kerberos) command within kadmin:

kadmin> ext_keytab -k gingko.keytab host/ telnet/

The -k option tells the utility what file to use to store the keytab. If you perform this step from the application server itself, you can give the filename /etc/krb5.keytab directly. If you do this job from another computer, such as the KDC, you can store the keytab under any convenient name, but you must then transfer the file to the application server and store it as /etc/krb5.keytab. Be sure this file is readable only by root (or by the account that will be used to run the server). If you add new Kerberized server programs to an application server, you need to add new principals and repeat this step, specifying principals for all of your server programs. Alternatively, you can combine multiple files using cat or similar tools, adding only the new principals, as needed.

Keytab files function as proof of a server's identity. For this reason, they're extremely sensitive. Never transfer them using unencrypted network protocols, such as an unencrypted FTP or NFS server. For network transfers, scp (part of the SSH package) is an acceptable choice. You can also use a floppy disk or other removable media, but when you're done, be sure to do a low-level reformat of a floppy disk or otherwise securely wipe the keytab file from the disk (say, using wipe); don't just delete the file with rm. Also, if you use a KDC to generate the keytabs, delete the keytab file from the KDC's disk, ideally using wipe or another tool that completely destroys the data in a file. The KDC stores a copy in its principals database, and a copy in a disk file might fall into the wrong hands if not given sufficient protection.

Running the Servers

Once the application server's keytab is in place, you can run the server programs. Doing so is much like running non-Kerberos servers. The servers that come standard with Kerberos are typically run from a super server (inetd or xineted). For instance, Example 9-3 shows a file, stored in /etc/xinetd.d, that will launch the Kerberized Telnet server (ktelnetd) that ships with MIT Kerberos.

Example 9-3. Sample xinetd configuration for the Kerberized Telnet server

service telnet
   disable      = no
   socket_type  = stream
   protocol     = tcp
   wait         = no
   user         = root
   group        = root
   server       = /usr/sbin/ktelnetd
   server_args  = -a valid

The standard Kerberos servers support additional options you must use to enable Kerberos authentication:

This program works in conjunction with the rlogin command. You'll ordinarily use the options -k (enable Kerberos authentication), -e (enable encryption), and -c (require a cryptographic checksum from the client, which improves security).
This remote shell server is used with rsh to enable remote program execution. You'll probably use the same -k, -e, and -c parameters described for klogind.
This program is a Kerberized FTP server. With some versions of this program, you'll probably use it with the -a valid option, which enables Kerberos authentication. Other versions of the server don't require this option. Consult your package's documentation to learn which option is required.
This server provides Kerberized Telnet access to a computer. Like kftpd, it may require a -a valid option to enable Kerberos authentication.


These servers support encryption, but only when used with matching Kerberized clients, such as those that ship with Kerberos packages. When used with ordinary non-Kerberized clients, these servers provide no advantages over their non-Kerberized counterparts.

These servers support additional options, too, some of which aren't related to Kerberos operation. Depending on their configuration options, they might or might not accept non-Kerberos logins. If you need more details, consult their manpages or other documentation. (Some packages lack manpages for their servers.)


Some Kerberos packages (notably Heimdal) omit the leading k from the server filenames. In addition, the server files' locations vary depending on the Kerberos package. Check your package's contents to learn the details.

In addition to these basic servers, Kerberized versions of other servers are available. In some, Kerberos support is part of the main server, although it may be a compile-time option. For instance, Samba supports Kerberos authentication, but only if you provide appropriate compile-time options. (The details of Samba's Kerberos features are actually rather complex and are beyond the scope of this book.) For some protocols, Kerberos support is available in some servers but not others. Thus, if you want to support Kerberos for particular protocols, you should check the documentation for your preferred servers. If they don't support Kerberos, try performing a web search. Precisely how you might activate Kerberos support for these tools varies greatly from one server to another, so you'll have to consult your server's documentation.

Linux Kerberos Client Configuration

Kerberized clients are simpler to configure than KDCs or Kerberized application servers. Nonetheless, these tools do require some basic configuration to work. You may even need to track down Kerberized versions of clients for specific protocols, particularly if you want to use tools that aren't provided with Kerberos. Once everything's set up, you should know something about the basic Kerberos user management tools, because they control user access to the realm.

Preparing Kerberos Clients

The main requirement for Kerberos client configuration is to set up the Kerberos configuration file, krb5.conf, as described earlier. Note that there's no need for a [logging] or [kdc] section, and, consequently, no need for a kdc.conf file—even if you're using MIT Kerberos.


You can mix and match an MIT Kerberos KDC with Heimdal clients, or a Heimdal KDC with MIT Kerberos clients. As described in the section Section 9.5, still other Kerberos implementations can interact with these common Linux Kerberos tools.

Because the Kerberos clients don't maintain Kerberos databases, you don't need to use kadmin or kadmin.local to set up local Kerberos databases on the clients. You do, though, need to create principals for your users, as described earlier in this chapter.

Installing Kerberized Clients

Kerberized clients can be classified in two categories: those that ship with the main Kerberos package and third-party tools. The "official" Kerberized clients are those that match the "official" Kerberized servers, as described earlier in Section 9.3.3. If you install Kerberos from source code, these clients install with the main Kerberos package, so the easiest way to install them is to compile the whole Kerberos package. Some Linux distributions, though, split the Kerberos clients into a separate package, such as Fedora's krb5-workstation. (Such tools may depend on others, such as Fedora's krb5-libs.) Other distributions place everything in one huge package.

If you want to use additional protocols, such as POP or IMAP, you need to track down Kerberized clients—in the case of POP or IMAP, this is a Kerberized mail reader, such as Pine ( As with matching Kerberized servers, tracking these down can be tricky. A web search on appropriate terms, such as Kerberos IMAP, may help.


Many clients and servers provide Kerberos support as a compile-time option. If you can't seem to get Kerberos support working, particularly if you're using precompiled binaries and the documentation says that the client supports Kerberos, you can try recompiling the program locally. This may require that you install a Kerberos development package, though.

Using Kerberized Clients

Kerberos is a network login protocol, but Linux Kerberos packages don't automatically enable Kerberized authentication for desktop logins. (This option is described in the next section.) Instead, you can manage a Kerberos session after you've logged into your normal Linux (or other OS) session. Once you've done this, you can use the following four Kerberos client tools to manage your Kerberos session:

This program initializes a Kerberos session. More precisely, it obtains a TGT from the KDC. Once you've acquired a TGT, the Kerberos utilities can easily—and transparently—obtain tickets to specific servers. Thus, kinit manages the "single sign-on" feature of Kerberos. To use the tool, type its name; it will ask you for a password, using your Linux username as the primary of the principal and the default realm defined in krb5.conf. You can obtain a TGT for another principal by passing its name to kinit, as in kinit linnaeus/admin@EXAMPLE.COM. This is handy if you have multiple principals, such as one for regular use and another for administrative functions.
This program displays information on your current tickets, including the TGT. If you can't seem to log in using a Kerberos client, using klist can be a good starting point. You might discover that you're missing a necessary ticket.
This command is the Kerberos equivalent of the Linux passwd command; it changes your Kerberos realm password. You must have a TGT to use it.
This command destroys all your tickets. In theory, you should run this command just before logging out of the computer from which you're managing your Kerberos session. If you fail to do so, the tickets might remain in memory and could, in theory, be misappropriated by somebody with sufficient privilege. Some session management tools destroy tickets automatically, though, so this may not be necessary. You can also use this tool to destroy tickets you no longer need, which enables you to authenticate using a "clean slate" for testing purposes.

Of these commands, only kinit is necessary for using Kerberos as a client, and it can be replaced by other tools, as described later. To illustrate the use of these tools, though, consider the following sequence of commands:

$ kinit
Password for fluffy@EXAMPLE.COM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: fluffy@EXAMPLE.COM

Valid starting     Expires            Service principal
06/23/04 19:24:42  06/24/04 19:24:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
$ kpasswd
Password for fluffy@EXAMPLE.COM:
Enter new password: :
Enter it again: :
Password changed.
$ /usr/lib/heimdal/bin/telnet -af mandragora
Connected to mandragora (
Escape character is '^]'.
[ Kerberos V5 accepts you as ``fluffy@EXAMPLE.COM'' ]
Last login: Wed Jun 23 19:24:25 from halrloprillalar
fluffly@mandragora> logout
Connection closed by foreign host.
$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: fluffy@EXAMPLE.COM

Valid starting     Expires            Service principal
06/23/04 19:24:42  06/24/04 19:24:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
06/23/04 19:26:16  06/24/04 19:24:39  host/

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
$ kdestroy
$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500)

Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached

This example begins with a call to kinit, which obtains the initial TGT (krbtgt/EXAMPLE.COM@EXAMPLE.COM, as revealed by the first call to klist). The call to klist also displays the TGT's starting and ending times—one day apart in this example. The call to kpasswd results in a password-change exchange much like the one that results from the standard Linux passwd command.

The Kerberized telnet command works much like the stock telnet, but passing the -a and -f parameters are necessary to have the client attempt an automatic login and forward its credentials to the server, respectively. Without these options, you'll be prompted for your username and password. Note also that this example includes the complete path to the Kerberized binary. Depending on your PATH environment variable and where your Kerberized and normal telnet binaries are located, this may or may not be necessary to ensure use of the Kerberized tool. After logging out of the remote system, a second call to klist reveals that the system is still holding onto the TGT but has acquired a new ticket, host/, which corresponds to the server system to which you've connected. After using the kdestroy command, klist reveals that no tickets are present. At this point, an attempt to use Kerberized clients will either fail or result in a conventional login prompt, or at least a request for a password. If this happens, Kerberos is not being used for authentication.


Of the clients that ship with Kerberos, ftp provides the most verbose information while connecting to the server. This fact can be useful when you're debugging problems.

Many of the stock Kerberos client programs (telnet, rlogin, and so on) require the -a and/or -f options to enable automatic logins using Kerberos credentials. Some packages use a leading k to differentiate the Kerberized programs from their non-Kerberized counterparts, as in ktelnet. You'll need to consult your local documentation and package information to learn the details for your system.

Using Kerberos for Network Logins

One of the limitations of Kerberos, at least as it's delivered in the main Kerberos package, is that it isn't a very good tool for logging into individual desktop systems. To use Kerberos as just described, you must log into your desktop system, including entering a password, and then use kinit to initialize a Kerberos session. Ideally, you should be able to enter your username and password just once, when you log into the computer. This ideal is achievable using any of several tools; however, some of them require additional configuration to use. Even at their best, though, these tools aren't complete replacements for your local Linux accounts; you must still maintain some information locally or via some other tool, such as LDAP.

Kerberized login tools

Linux requires authentication for many different tools. In terms of local login, two broad classes of tools are most notable: text-mode login, which is handled by the login program, and GUI login, which is handled by an X Display Manager (XDM) program. In addition to these login tools, though, other local authentication tools exist, such as screen-locking programs, which lock the console after a period of activity, much like screen savers, but require a password to unlock the screen.

The stock Heimdal and MIT Kerberos packages ship with a replacement for the standard login tool. This replacement is called login in Heimdal and login.krb5 in MIT Kerberos. It's installed in an out-of-the-way directory or under an unusual name to prevent interference with the standard login program. To use the new tool, you must copy it over the original, which is typically located in /bin, but I recommend you first back up the original in case you run into problems:

# mv /bin/login /bin/login-original
# cp /usr/sbin/login.krb5 /bin/login


Adjusting your system's login tools is potentially risky. You should ensure that you have some alternate way to log in that doesn't use login (such as via an XDM program or an SSH session) when adjusting login. You may also want to leave a root login running in one virtual terminal while you make changes.

Once you make this change, your system should begin using Kerberos for all text-mode console logins, with the caveat that any currently running login processes may need to be restarted first. (Typically, logging in and then logging out should do the job.) The login program is used by some other tools, too, such as non-Kerberized Telnet servers. Using a Kerberized login program, though, doesn't provide you with any extra security; the client still sends the username and password to the server unencrypted, and the resulting session will also be unencrypted.


One good way to test whether you're using the Kerberized login tool is to use klist. If you destroy your tickets, log out, log in, and then find you have a new TGT after logging in, you can be sure you're using the Kerberized login.

After making these changes, you should test all your user accounts, or at least all of those you can test. Be sure to test your root account, too, and if it doesn't work, create an appropriate Kerberos principal for root.


Using PAM for Kerberized logins, as described next, enables you to use a local root account along with Kerberos for other users. This can make the PAM solution a bit safer because you won't be denied root access if a Kerberos problem develops. This solution also lets you set different root passwords for each computer.

Unfortunately, the standard Kerberos packages don't ship with an equivalent to the Kerberized login for GUI logins. To implement Kerberized GUI logins, you must either track down a Kerberized XDM (they're rare) or implement Kerberos via PAM. The latter is a more flexible approach, and it can also be used in place of the explicitly Kerberized login program, but PAM takes more effort to set up.

Kerberos and PAM

Several third-party Kerberos PAM modules exist, but the most popular is the pam_krb5 package, which is available under that name with most distributions. (Debian calls its version libpam-krb5, though.) Its main web site is, should you need to install it from source code.

The Kerberos PAM package installs very few files; aside from documentation files, the only important file is /lib/security/ Some versions also install a variant known as, which also supports logins via Andrew File System (AFS) authentication.

You can configure the Kerberos PAM modules by adding references to for the auth and account items in the files in /etc/pam.d corresponding to the services you want to use Kerberos authentication. This topic is described in more detail in Appendix A, so consult it for details.

The primary advantage of using PAM for local Kerberos authentication is that you can use Kerberos for just about any service that requires authentication. The list of likely services includes login, XDM (or its GNOME or KDE variants, GDM or KDM), su, sudo, passwd, vlock (a text-mode, console-locking program), xlock (an X-based console-locking program), and xscreensaver (another X-based, console locking program). Using the Kerberized PAM modules for these services (and particularly for the login and XDM, GDM, or XDM services) means that users will have TGTs the moment they log in; they won't need to use kinit to obtain them.

In theory, you can use the Kerberized PAM module to support network-accessible login servers, such as POP, IMAP, FTP, and SSH. In practice, though, the advantages to doing so are slim, because the communication between the client and server is still done in whatever way it would be done if you used the normal PAM configuration. In particular, a protocol that delivers the password in unencrypted form will continue to do so. If possible, you should instead replace the client and server programs with explicitly Kerberized versions. This configuration bypasses PAM and uses Kerberos directly, giving you more Kerberos benefits. Alternatively, you can set up an encrypted tunnel to encrypt all data, including passwords. This protects your passwords and enables you to use the Kerberos database, but won't extend the single-sign-on advantages of Kerberos to non-Kerberized clients.

Kerberized account maintenance

If you've read Chapters Chapter 7 or Chapter 8, you may have noticed an omission in the preceding description of Kerberos and PAM: no mention has been made of the Name Service Switch. This Linux component provides account information, such as UID-to-username mapping, to programs that need it. Unfortunately, no Kerberos NSS modules are available, which means that you can't rely on Kerberos to maintain the sort of information NSS normally handles. The practical upshot of this limitation is that you must either maintain local accounts (in /etc/passwd) for your Kerberos-authenticated users, or you must rely on another tool (such as LDAP) to handle this job.

This limitation can be a serious one for many potential uses of Kerberos; if you want to maintain full user account information in a central database, so that you needn't modify desktop systems' configurations when adding or deleting users on your network, Kerberos by itself isn't a complete solution, at least not when you're using Linux desktop systems. Some possible solutions to this problem include:

  • You can maintain a central Kerberos database and deal with conventional Linux /etc/passwd files manually. This approach may be acceptable if users seldom or never use anything but their own desktop systems; you need to update only a user's own desktop system and the Kerberized servers when adding or deleting network users. For instance, when adding the user bbode, you don't need to modify fluffy's desktop system.
  • You can abandon Kerberos entirely, at least as a login tool, and switch to another protocol, or relegate Kerberos to secondary duty (say, for use by just a few users). You can still use Kerberos as a tool for managing server accesses subsequent to desktop logins, but the servers will still need local accounts to match the Kerberos principals.
  • You can use another protocol, such as LDAP, as a supplement to Kerberos. You'd use Kerberos for authentication via PAM but configure NSS to use the other protocol. This approach can be an effective one and can be a useful way to take advantage of Kerberos's single-sign-on capabilities while minimizing account maintenance. Unfortunately, configuring both systems is likely to be tedious in the short term, and this approach also seems to require that you maintain two account databases, at least at first glance—one for Kerberos and one for the secondary system. In practice, you can link LDAP and Kerberos more tightly (much as AD under Windows does), but this topic is well beyond the scope of this chapter.


If your network hosts a Windows 200x AD controller, you can use it as the KDC and configure Linux systems as Kerberos application servers. If you also configure Winbind's NSS features and use the AD controller as a domain controller, as described in Chapter 7, the Linux system will maintain Linux user accounts automatically.

Ultimately, you'll have to decide for yourself just how to balance your priorities: Kerberos's unique features, such as single-sign-on, versus simplified local account information. If the former isn't very important but the latter is, LDAP or NT domains will probably be a better solution than Kerberos; if the former is very important, Kerberos is the better tool in addition to or instead of another one.

Windows Kerberos Tools

Up to now, this chapter has presented Kerberos largely from a Linux perspective. Kerberos, though, is a cross-platform tool, and you can use it to help integrate Linux and Windows systems. You can use Windows in any of the main Kerberos roles (KDC, application server, or client).

Windows Kerberos Implementations

Broadly speaking, three approaches to Kerberos are possible under Windows:

Microsoft's Kerberos implementation
Microsoft provides a Kerberos implementation as part of Windows 200x/XP (but not Windows XP Home). As described in Section 9.1.4, Microsoft's Kerberos implementation deviates from others, which can make using it with a non-Microsoft KDC tricky. In the Section 9.5.3, some pointers for using Microsoft's Kerberos clients with non-Microsoft KDCs are presented.
Conventional non-Microsoft Kerberos implementations
You can obtain non-Microsoft Kerberos implementations for Windows. For instance, a Windows binary version of MIT Kerberos ( is available for all versions of Windows since Windows 98. (Windows 95 and earlier are not supported.) This tool can be configured and used much like Linux versions of Kerberos. The main difference is that configuration file locations differ. Most importantly, instead of editing /etc/krb5.conf, you edit C:\WINDOWS\krb5.ini. (This file may reside in another directory if you installed Windows to a directory other than C:\WINDOWS.) This package also includes a GUI tool called Leash, which manages Kerberos tickets.
Limited non-Microsoft Kerberos implementations
Some tools provide limited Kerberos support—typically, Kerberos-enabled versions of a handful of protocols, with their own Kerberos libraries. One of the more popular of these is Kerberos Telnet (, which provides Kerberized Telnet, FTP, and POP implementations for Windows. Tools like this don't work in conjunction with either Microsoft's Kerberos or broader non-Microsoft Kerberos tools on the same system, although, of course, they can interact with such systems as KDCs and application servers.

Each tool type has its advantages and disadvantages. Broadly speaking, you're most likely to find Kerberized Windows clients and application servers that work with the Windows implementation of Kerberos; however, this implementation is limited to just a few recent versions of Windows, and it doesn't always interoperate well with non-Microsoft KDCs. Kerberized Windows clients and servers can also be very difficult to locate, aside from those provided with Windows. Microsoft's Kerberos implementation can function well as a KDC for non-Microsoft application servers and clients. Full non-Microsoft Kerberos implementations work best with Unix tools ported to Windows (say, running in conjunction with Cygwin) or with Kerberized Windows clients and application servers. These tools interoperate well with Kerberized Linux programs, but the implementation is awkward when it comes to providing single-login authentication for Windows desktop systems. Limited non-Microsoft Kerberos implementations can be handy on desktop systems when you want to use Kerberos authentication for security reasons or to provide single-login authentication but when you're not concerned about Kerberizing the initial logon to Windows.

Windows Kerberized Servers

Windows 200x/XP systems that are members of an AD domain automatically use the AD controller's Kerberos features to authenticate file and printer sharing access. Thus, configuring this aspect of Kerberized server use is relatively straightforward.


By treating the AD controller as an NT domain controller, Linux systems running Samba and older Windows NT servers can authenticate against the AD controller even if these domain member servers don't use Kerberos. Thus, many of the benefits of Kerberos extend even to some non-Kerberos systems.

As with Linux servers, Kerberos support in most third-party servers is a hit-or-miss proposition. Windows doesn't ship with Kerberized Telnet, FTP, or other servers, and these servers are lacking even in some third-party Kerberos packages.

Windows Kerberized Clients

In principle, Windows Kerberos clients can be as varied as Linux Kerberos clients. If you have specific needs, you may need to consult the documentation for the Kerberized clients you've selected. It's even possible that your choice of client programs will dictate your choice of overall Windows Kerberos implementation (Microsoft's, a third party's, or Kerberos integrated into a server). As a couple of examples, I present information on using Microsoft's Kerberos to authenticate against a non-Windows KDC and using the Kerberos Telnet package.

Using Windows' Kerberos

Microsoft supports Kerberos as part of its Active Directory domain authentication. If you're using an AD domain controller, Windows clients automatically use the AD controller's KDC features when they're configured as members of the domain. This support also extends to use of Windows file and printer shares offered by domain members.

You can use a non-Windows Kerberos KDC as a way to authenticate Windows 200x/XP users' initial sign-ons, but the process is awkward. One way to do it is to establish a cross-realm trust relationship between a Windows AD controller and the non-Windows KDC. This procedure is quite advanced, though, and is beyond the scope of this book. A somewhat simpler, but more limited, approach is to configure local user accounts on the Windows desktop system and tell it to use the KDC, thus centralizing the password database. The following list shows you how:

  1. Create a host key for the Windows client using kadmin on the KDC. This key must use DES encryption. In MIT Kerberos, you can do this with the -e option to addprinc, as in addprinc -e des:normal host/ to add a principal for the Windows system Don't randomize the password when you create this principal, as you do when creating a principal for a Linux application server.
  2. Run the ksetup program on the Windows client, and tell it how to locate the KDC. In the last step, you'll need to enter the password you used when you created the host key for the Windows system:
    C:\>ksetup /setdomain EXAMPLE.COM
    C:\>ksetup /addkdc EXAMPLE.COM
    C:\>ksetup /addkpasswd EXAMPLE.COM
    C:\>ksetup /setmachpasswd 
  3. Use the Windows ksetup tool to map a Kerberos principal name to a local username. For instance, typing ksetup /mapuser fluffy@EXAMPLE.COM Cerberus maps the Kerberos principal name fluffy@EXAMPLE.COM to the local account Cerberus. As a shortcut, you can type ksetup /mapuser * *. This command maps local users to like-named Kerberos principals; for instance, the local user fluffy maps to the fluffy@EXAMPLE.COM principal.

Once this is done, you should be able to log on and have the Windows desktop system use the KDC for authentication. You will, however, have to maintain local accounts corresponding to those on the KDC, or at least mapped to it using ksetup /mapuser.

Using Kerberos Telnet

If you want to use Kerberos only for Telnet, FTP, or POP access, Kerberos Telnet ( may be just what you need. This program, shown in Figure 9-1, is a Kerberized POP proxy, FTP, and Telnet implementation for Windows that doesn't rely on any other local Kerberos tools.

Figure 9-1. Kerberos Telnet provides an all-in-one Kerberos client tool for Windows

Kerberos Telnet provides an all-in-one Kerberos client tool for Windows

When you install Kerberos Telnet, you'll be asked for basic information, such as your realm name. The tool then uses that information when you request a connection to a server. The first time you do this, you'll be asked for principal information (in the "User data" dialog box shown in Figure 9-1. Thereafter, you won't have to type your password again. Kerberos Telnet provides integrated ticket management tools (also shown in Figure 9-1), so you can check on tickets' expiration dates, destroy them, and so on.


Compared to other remote authentication tools, Kerberos is unusual; it's designed to manage entire network logins, rather than desktop computer logins. As such, it's best suited for environments in which users frequently use multiple servers, with protocols such as Telnet or FTP. Kerberos configuration requires configuring three computer classes: the KDC, the application servers, and the clients. All have certain commonalities, such as the krb5.conf file, but each has its unique features, as well. Considered as a cross-platform tool, Kerberos can be an integrative tool, but Microsoft's non-standard Kerberos implementation throws a monkey wrench into the equation. Cross-platform Kerberos use works best with a Microsoft KDC (in the form of an AD controller) and non-Microsoft application servers or clients; using Microsoft application servers or clients with a non-Microsoft KDC is trickier, although it's still possible, and sometimes worthwhile, for some purposes.

Personal tools