Docbook2Wiki: Initial conversion from Docbook

2008-03-11T21:46:06Z

Initial conversion from Docbook

New page

{{Linux in a Windows World/TOC}}
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.

<div class="tip">
'''Tip'''

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.
</div>

== 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.

<div class="tip">
'''Tip'''

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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Windows and Kerberos|Section 9.1.4]] and [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Windows Kerberos Tools|Section 9.5]].
</div>

=== 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.

;KDC
: 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.
;Kerberized
: 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.
;Realm
: 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 ''example.com'' 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
: 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.
;TGT
: 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.
;TGS
: The ticket-granting service is the KDC subsystem that's responsible for granting TGTs.
;Principals
: A Kerberos principal is a user or server identification. Principals take the form <tt>''primary''</tt>/<tt>''instance''</tt>@<tt>''REALM''</tt>, where <tt>''primary''</tt> is a name (frequently a username), <tt>''instance''</tt> is an optional expansion that enables one user to have multiple principals, and <tt>''REALM''</tt> 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/mandragora.example.com@EXAMPLE.COM'' for the Telnet server on ''mandragora.example.com''. Computers that run application servers also require principals, on which the primary name is ''host'', as in ''host/mandragora.example.com@EXAMPLE.COM''. 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.)

<div class="warning">
'''Warning'''

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. [[Linux in a Windows World/Additional Server Programs/Managing a Network with Linux|Chapter 15]] describes one tool you can use for this purpose, the Network Time Protocol.
</div>

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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Using Kerberized Clients|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, ''http://web.mit.edu/kerberos/www/'', 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.
;Heimdal
: This version of the Kerberos V5 protocol is hosted in Sweden, at ''http://www.pdc.kth.se/heimdal/''. 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.
;eBones
: This package, headquartered at ''http://www.pdc.kth.se/kth-krb/'', 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.

<div class="tip">
'''Tip'''

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.
</div>

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.
;The PAC
: 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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Windows Kerberized Clients|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.

<div class="tip">
'''Tip'''

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.
</div>

==== 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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-1|Example 9-1]].

<div id="linuxwinworld-CHP-9-EX-1">
'''Example 9-1. Sample krb5.conf listing'''

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

[libdefaults]
ticket_lifetime = 28800
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false

[realms]
EXAMPLE.COM = {
kdc = kdc.example.com:88
admin_server = kdc.example.com:749
default_domain = example.com
}

[domain_realm]
.example.com = EXAMPLE.COM
tropical.pangaea.edu = EXAMPLE.COM
</div>

This file is broken into sections, with each section denoted by a section name within square brackets (<tt>[ ]</tt>). 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 (<tt>{ }</tt>), as in the <tt>EXAMPLE.COM</tt> item within the <tt>[realms]</tt> section. Many of the ''krb5.conf'' parameters are self-explanatory, but some deserve additional elaboration:

;Logging options
: The options in the <tt>[logging]</tt> 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 <tt>ticket_lifetime</tt> option sets the default lifetime for most tickets issued by the KDC, in seconds. The value of <tt>28800</tt> shown in [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-1|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 <tt>default_realm</tt> 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 <tt>dns_lookup_realm</tt> and <tt>dns_lookup_kdc</tt> options tell Kerberos to use DNS to help locate systems.
;Realm definitions
: The <tt>[realms]</tt> section defines realms. In [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-1|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 <tt>kdc</tt> 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 <tt>default_domain</tt> 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 <tt>[realms]</tt> section.
;Domain/realm mapping
: The <tt>[domain_realm]</tt> section specifies a mapping of computers to realms. In [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-1|Example 9-1]], all computers in the ''example.com'' domain and the computer ''tropical.pangaea.edu'' 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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-1|Example 9-1]], MIT Kerberos is likely to have an additional section that points to the ''kdc.conf'' file:

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

You may also see a section called <tt>[appdefaults]</tt> 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 <tt>profile</tt> option in the <tt>[kdc]</tt> section of ''krb5.conf''. [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-2|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 <tt>[realms]</tt> section to match your needs. The <tt>master_key_type</tt> and <tt>supported_enctypes</tt> options relate to the encryption methods that Kerberos supports.

<div id="linuxwinworld-CHP-9-EX-2">
'''Example 9-2. Sample kdc.conf listing'''

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

[realms]
EXAMPLE.COM = {
master_key_type = des-cbc-crc
supported_enctypes = arcfour-hmac:normal arcfour-hmac:norealm
arcfour-hmac:onlyrealm
des3-hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal
des-cbc-crc:normal des-cbc-
crc:v4 des-cbc-crc:afs3
}
</div>

=== 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:

<div class="warning">
'''Warning'''

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.
</div>

=== 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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Preparing Application Server Principals|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 <tt>admin_server</tt> 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 <tt>-l</tt> 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.

<div class="tip">
'''Tip'''

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.
</div>

==== 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 <tt>acl_file</tt> entry in ''kdc.conf''. (You can specify the same parameter in a <tt>[kdc]</tt> 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, <tt>''Kerberos-Principal''</tt>, is the principal to which the ACL applies—that is, the user whose permissions are being defined. The <tt>''Permissions''</tt> string is a collection of one or more letters (in MIT Kerberos) or a comma-separated list of codes (in Heimdal), as summarized in [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-TABLE-1|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.

<div id="linuxwinworld-CHP-9-TABLE-1">
'''Table 9-1. Kerberos ACL permission codes'''

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

In the case of both principal specifications, an asterisk (<tt>*</tt>) 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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Editing krb5.conf|Section 9.2.1.1]]. You can, however, omit some sections from this file, namely the <tt>[logging]</tt> and <tt>[kdc]</tt> 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 <tt>-r</tt> (in Heimdal) or <tt>-randkey</tt> (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 <tt>host</tt> (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 ''gingko.example.com'' to function as a Kerberized Telnet server, you can type (using Heimdal's ''kadmin'') the following:

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

<div class="tip">
'''Tip'''

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.
</div>

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/gingko.example.com telnet/gingko.example.com'''

The <tt>-k</tt> 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, [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-EX-3|Example 9-3]] shows a file, stored in ''/etc/xinetd.d'', that will launch the Kerberized Telnet server (''ktelnetd'') that ships with MIT Kerberos.

<div id="linuxwinworld-CHP-9-EX-3">
'''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
}
</div>

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

;''klogind''
: This program works in conjunction with the ''rlogin'' command. You'll ordinarily use the options <tt>-k</tt> (enable Kerberos authentication), <tt>-e</tt> (enable encryption), and <tt>-c</tt> (require a cryptographic checksum from the client, which improves security).
;''kshd''
: This remote shell server is used with ''rsh'' to enable remote program execution. You'll probably use the same <tt>-k</tt>, <tt>-e</tt>, and <tt>-c</tt> parameters described for ''klogind''.
;''kftp''
: This program is a Kerberized FTP server. With some versions of this program, you'll probably use it with the <tt>-a valid</tt> 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.
;''ktelnetd''
: This server provides Kerberized Telnet access to a computer. Like ''kftpd'', it may require a <tt>-a valid</tt> option to enable Kerberos authentication.

<div class="warning">
'''Warning'''

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.
</div>

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.)

<div class="tip">
'''Tip'''

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.
</div>

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 <tt>[logging]</tt> or <tt>[kdc]</tt> section, and, consequently, no need for a ''kdc.conf'' file—even if you're using MIT Kerberos.

<div class="tip">
'''Tip'''

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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Windows Kerberos Tools|Section 9.5]], still other Kerberos implementations can interact with these common Linux Kerberos tools.
</div>

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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Running the Servers|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 (''http://www.washington.edu/pine/''). As with matching Kerberized servers, tracking these down can be tricky. A web search on appropriate terms, such as ''Kerberos IMAP'', may help.

<div class="tip">
'''Tip'''

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.
</div>

=== 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:

;''kinit''
: 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 <tt>'''kinit'''</tt> <tt>'''linnaeus/admin@EXAMPLE.COM'''</tt>. This is handy if you have multiple principals, such as one for regular use and another for administrative functions.
;''klist''
: 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.
;''kpasswd''
: 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.
;''kdestroy''
: 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'''<nowiki>
Trying 192.168.1.3...
Connected to mandragora (192.168.1.3).
Escape character is '^]'.
[ Kerberos V5 accepts you as ``fluffy@EXAMPLE.COM'' ]
Last login: Wed Jun 23 19:24:25 from halrloprillalar
fluffly@mandragora> </nowiki>'''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/mandragora.example.com@EXAMPLE.COM

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 <tt>-a</tt> and <tt>-f</tt> 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 <tt>PATH</tt> 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/mandragora.example.com@EXAMPLE.COM'', 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.

<div class="tip">
'''Tip'''

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.
</div>

Many of the stock Kerberos client programs (''telnet'', ''rlogin'', and so on) require the <tt>-a</tt> and/or <tt>-f</tt> 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'''

<div class="warning">
'''Warning'''

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.
</div>

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.

<div class="tip">
'''Tip'''

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''.
</div>

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''.

<div class="tip">
'''Tip'''

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.
</div>

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 ''http://sourceforge.net/projects/pam-krb5/'', 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/pam_krb5.so''. Some versions also install a variant known as ''pam_krb5afs.so'', which also supports logins via Andrew File System (AFS) authentication.

You can configure the Kerberos PAM modules by adding references to ''pam_krb5.so'' for the <tt>auth</tt> and <tt>account</tt> 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 [[Linux in a Windows World/Appendixes/Configuring PAM|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 [[Linux in a Windows World/Centralized Authentication Tools/Using NT Domains for Linux Authentication|Chapter 7]] or [[Linux in a Windows World/Centralized Authentication Tools/Using LDAP|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.

<div class="tip">
'''Tip'''

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 [[Linux in a Windows World/Centralized Authentication Tools/Using NT Domains for Linux Authentication|Chapter 7]], the Linux system will maintain Linux user accounts automatically.
</div>

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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Windows and Kerberos|Section 9.1.4]], Microsoft's Kerberos implementation deviates from others, which can make using it with a non-Microsoft KDC tricky. In the [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#Windows Kerberized Clients|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 (''http://web.mit.edu/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 (''http://www.stacken.kth.se/~thn/ktelnet/''), 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.

<div class="tip">
'''Tip'''

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.
</div>

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:

<ol>
<li><div>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 <tt>-e</tt> option to ''addprinc'', as in <tt>'''addprinc'''</tt> <tt>'''-e'''</tt> <tt>'''des:normal'''</tt> <tt>'''host/mimbulus.example.com@EXAMPLE.COM'''</tt> to add a principal for the Windows system ''mimbulus.example.com''. Don't randomize the password when you create this principal, as you do when creating a principal for a Linux application server.
</div></li>

<li><div>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 kdc.example.com'''
C:\>'''ksetup /addkpasswd EXAMPLE.COM kdc.example.com'''
C:\>'''ksetup /setmachpasswd '''
''password''

</div></li>

<li><div>Use the Windows ''ksetup'' tool to map a Kerberos principal name to a local username. For instance, typing <tt>'''ksetup /mapuser fluffy@EXAMPLE.COM Cerberus'''</tt> maps the Kerberos principal name ''fluffy@EXAMPLE.COM'' to the local account ''Cerberus''. As a shortcut, you can type <tt>'''ksetup'''</tt> <tt>'''/mapuser'''</tt> <tt>'''*'''</tt> <tt>'''*'''</tt>. This command maps local users to like-named Kerberos principals; for instance, the local user ''fluffy'' maps to the ''fluffy@EXAMPLE.COM'' principal.
</div></li>

</ol>

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 (''http://www.stacken.kth.se/~thn/ktelnet/'') may be just what you need. This program, shown in [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-FIG-1|Figure 9-1]], is a Kerberized POP proxy, FTP, and Telnet implementation for Windows that doesn't rely on any other local Kerberos tools.

<div id="linuxwinworld-CHP-9-FIG-1">
'''Figure 9-1. Kerberos Telnet provides an all-in-one Kerberos client tool for Windows'''

[[Image:Linux in a Windows World_I_3_tt137.png|Kerberos Telnet provides an all-in-one Kerberos client tool for Windows]]
</div>

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 [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-FIG-1|Figure 9-1]]. Thereafter, you won't have to type your password again. Kerberos Telnet provides integrated ticket management tools (also shown in [[Linux in a Windows World/Centralized Authentication Tools/Kerberos Configuration and Use#linuxwinworld-CHP-9-FIG-1|Figure 9-1]]), so you can check on tickets' expiration dates, destroy them, and so on.

== Summary ==

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.

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

Docbook2Wiki: Initial conversion from Docbook

Docbook2Wiki: Initial conversion from Docbook