لطفا منتظر باشید ...
Configuring a
Kerberos Client
The first step to using Kerberos as a user is
to create a Kerberos principal for that user. This process was described
earlier, in the section "
servers using matched Kerberos-enabled clients. This means you must install
these clients and make them accessible to users. You can install clients by
installing the entire Kerberos package, or sometimes just by installing a
Kerberos base or library package along with a Kerberos workstation or clients
package. Users may also need to use some Kerberos housekeeping utilities to
obtain and manage TGTs. If you want to use Kerberos to control user logins to
individual workstations, you need to modify the usual login authentication
tools on the workstations.
Accessing Kerberos Servers
In broad strokes, users may access Kerberos
application servers by running an appropriate client program. Unfortunately,
the reality is a bit more complex than this simple explanation implies. For one
thing, there are several user-level utilities that come into playusers must
have some way to obtain a TGT, and must be able to perform routine maintenance
such as changing their Kerberos passwords. Second, the Kerberized clients
themselves sometimes pose unique challenges. For instance, many require options
to enable critical Kerberos features; without these options, the Kerberized
clients may behave like ordinary non-Kerberized clients.
Using Kerberos Network Utilities
The Kerberos package includes a number of
utilities that manage Kerberos passwords and tickets, including the
all-important ticket-granting ticket (TGT). The most important of these
tools are the following: kinit This program obtains a TGT. You can think of it as a program that
"logs you into" a Kerberos realm; before running kinit (or
using equivalent functionality, as described in the upcoming section, "
program contacts the KDC to obtain a TGT. Thereafter, Kerberized applications
use the TGT to obtain authorization to use Kerberos application servers, as
described earlier in this chapter. When you run kinit , you'll be asked
for a password. By default, kinit uses your username as the primary of the principal, in the default
realm. You can override this behavior by appending the principal name to the
command, as in kinit
minerva@PANGAEA.EDU . The program also accepts
several other options that modify its behavior. Consult the kinit man page for details. klist This program lists the tickets (including the TGT) that you
currently have, including some information such as their expiration dates. Before
running kinit , klist will show no tickets. kpasswd This program doesn't help manage a single Kerberos session;
instead, it's used to change the password for a principal in the Kerberos
database. It's the Kerberos equivalent of passwd , and works in much
the same way. You must have a TGT to use kpasswd . kdestroy This program destroys all the tickets in a given user's ticket
cache. You'd normally run this program just prior to logging off the computer,
or when you know you won't be using Kerberized servers in the near future. Although
Kerberos tickets expire if unused for a while, it's best to destroy them after
they've served their purpose, since this reduces the risk that they might be
abused in the event of a security breach.TIP
align=left border=0> You might want to add a call to kdestroy to
all users' .logout files, to the ends of their .xinitrc files, or to
other standard files such that the program will run when the user logs out. If
you use a Kerberos PAM module, as described later in this chapter, this
functionality may be handled automatically.
How do these tools work, in practice? Most
sessions will use just the kinit and kdestroy programs at the beginning and end of the session, respectively. You
can use the klist utility to see what happens with tickets, though. For instance,
consider the following exchange: $ kinit Password for fluffy@THREEROOMCO.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: fluffy@THREEROOMCO.COM Valid starting Expires Service principal 10/09/02 14:38:57 10/10/02 00:38:57 krbtgt/THREEROOMCO.COM@\ THREEROOMCO.COM Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached $ kpasswd Password for fluffy@THREEROOMCO.COM: Enter new password: Enter it again: Password changed. $ kdestroy $ klist klist: No credentials cache file found (ticket cache FILE:/tmp/krb5cc_500) Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached
The initial kinit command retrieved
the TGT, which appears as the krbtgt service in the subsequent call to klist . As you
can see from the start and expiration times, this ticket is good for ten hours
(a figure that can be adjusted on a system-by-system basis). If a Kerberized
client were used and klist run again, another ticket would appear for that service. Changing a
password with kpasswd requires entering the original password as a precaution, then
entering the new password twice. As with the password entry with kinit , none of
the passwords echo to the screen. After running kdestroy , all the tickets
are cleared.
Using Kerberized Clients
Kerberos client programs work much like their
conventional equivalents. In most cases, you type the program name followed by
the name of the server to which you want to connect. Unfortunately, many require
additional parameters to take full advantage of the features of Kerberos. For
instance, the telnet client requires extra parameters to obviate the need to enter a
username and password when you log in. Examples of Kerberized clients, and some
of their quirks, include the following: telnet The telnet program included with Kerberos works much like the standard telnet program
if run without extra options. Thus, if you just type telnet remote.host , you'll have to type your username and password again. To get the
benefit of Kerberos's one-login system, you must include the -a (automatic
logon) and -f (forward tickets) options. rlogin The standard rlogin program is often used in a relatively insecure way, as described in
Chapter 13 . You
can use the -f option to the Kerberized version of the program to add Kerberos
authentication. The result is very similar to using the Kerberized telnet with -a and -f . ftp Used without any extra parameters, this program uses Kerberos
authentication, although you must still verify your username (the program
presents a default, to which you can probably press the Enter key).TIP
align=left border=0> The Kerberos ftp package presents
somewhat more verbose information during the initial connection phase than do
some Kerberos clients. If you're having problems with a Kerberos
configuration, this additional information may be useful in debugging the
problems.
rsh This program is used to run a text-mode program on another
computer without logging into it with telnet , rlogin , or the
like. As with other Kerberized tools included with Kerberos, this version
includes extra options, such as -f . rcp The standard rcp program is a simple file-transfer program, to which the Kerberized
version adds the usual Kerberos authentication features. Other programs The preceding list covers only those network tools that ship with
a standard Kerberos V5 package. Many other tools come standard with Kerberos
support, provide Kerberos support as a compile-time option, or are available in
Kerberized variants. Of course, you need both Kerberized clients and servers to
use such tools.The man pages for the Kerberized client
programs provide additional details, including information on more options to
set the login realm, principal, and other features of use. If you use a
Kerberized tool that doesn't ship with the standard Kerberos distribution, be
sure to check its options. Some provide only minimal Kerberos functionality
(for instance, authentication but not encryption), but others are more full
featured. One feature that's particularly noteworthy and is supported by all
the standard Kerberos clients is data encryption. If you add the -x option to
any of these tools' command lines, they'll encrypt all data they transfer. This
feature can be extremely useful, particularly if you're connecting over the
Internet or are transferring data that's potentially sensitive even for
internal purposes. For instance, if you intend to log on to a computer with telnet and
then use su to administer it, you may want to use encryption to protect the root password.
(The ksu command, described in the upcoming section "
root account to accept password-less access from your regular account.) The standard Kerberos source code package
places Kerberos user programs in /usr/local/bin by default (administrative
tools go in /usr/local/sbin ). Some binary Kerberos packages may use other locations; for
instance, Red Hat's Kerberos builds place user programs in /usr/kerberos/bin . Chances are you want to
use the Kerberized tools instead of the standard tools. To do so, you should
ensure that the Kerberized tools directory appears before the standard tools
directory in users' paths (set in the PATH
environment variable, usually in /etc/profile
or users' .bashrc files, at
least for Bash users).
Using
Kerberos for User Logins
The preceding discussion of managing a Kerberos session
assumes that users have already logged into the computer. Doing so, however,
reduces the appeal of Kerberos, because it means users must essentially log in
twice: Once to gain access to the workstation, and again (using kinit ) to use Kerberized servers. The
solution is to use a tool that takes over both tasks. There are various tools
that accomplish this goal. Kerberos ships with two, login.krb5 and ksu ,
that can help with certain text-mode tasks. Another approach is to modify
Linux's underlying authentication library to rely upon Kerberos. This approach
is more difficult to set up, but is also much more flexible.WARNING
align=left border=0> Before trying to use login.krb5 ,
I recommend that you first test the kinit
program for important accounts, including your root account. If kinit
doesn't work, it's very likely that login.krb5
won't either, which means you won't be able to log into the console in text
mode. You should also keep a root
shell open in one virtual terminal, so that you can change your configuration
if you encounter a problem with login.krb5 .
Similar cautions apply to changing other login tools.
Performing Text-Mode
Kerberos Login Authentication
The normal text-mode login procedure for a Linux system
involves the use of a program that's known generically as a getty. There are several getty programs, ranging from
the original getty to variants
such as mingetty , mgetty , and vgetty . These programs are run from /etc/inittab , and they take control of a
console, serial port, or the like, and pass control to another program, /bin/login . Some network login protocols,
such as Telnet, also call /bin/login .
As you might guess by the name, login.krb5
is intended as a replacement for /bin/login .
To use the Kerberized tool, you should replace /bin/login
with the new tool. I recommend first backing up the original program. For
instance, you might issue the following commands: # mv /bin/login /bin/login-original # cp /usr/kerberos/sbin/login.krb5 /bin/login
This action ensures that you'll be able to recover the
original /bin/login program if
something goes wrong. After you've replaced this program, subsequent logins
will use Kerberos for the initial login. This includes obtaining a TGT, so
there's no need to run kinit
after such a login. Indeed, once so configured, a computer will use only the Kerberos authentication for logins mediated
by /bin/login , although the user
must still have an entry in the local /etc/passwd
file, a home directory, and any other required local resources to successfully
use the computer. In addition, there are other methods of logging in that you
may need to adjust, such as GUI logins or logins through servers that don't
rely upon /bin/login , such as
SSH.
Changing
Your Account After Logging In
One additional authentication tool, which is not quite the
usual type of logging in, is using su
to acquire another user's identity. Kerberos includes an alternative package, ksu , to permit changes in the current user
account. This program has certain prerequisites: The computer on which you run ksu
must have a host key (typically stored in /etc/krb5.keytab ,
and described earlier in this chapter). The ksu binary
must be installed SUID root if
anybody but root is to use the
program. Most Kerberos packages do not install ksu SUID root ,
so you must do this yourself (say, by typing chmod a+s /usr/ kerberos/bin/ksu ). For best security, the user whose identity you wish to acquire
must have a configuration file authorizing others to gain the specified access.
The .k5login or .k5users file provides this authorization,
as described shortly.To provide authorization to an account, the target user may
create an authorization file. Without this file, another user may still access
the account, but ksu asks for a
password, which may be passed in cleartext over the network if the user is
logged in using an insecure protocol such as Telnet. The .k5login file grants another user full
login privileges, and is simplest to use. This file consists of a series of
lines, each of which is a Kerberos principal. The .k5users file grants users limited access to the account by
specifying a list of programs that the user may run; each line begins with a
Kerberos principal, and is followed by specific program names separated by
spaces. An asterisk ( * ) is a
wildcard for any command. For instance, the following entry grants minerva@THREEROOMCO.COM the right to run
the /bin/ls and /usr/bin/zip programs: minerva@THREEROOMCO.COM /bin/ls /usr/bin/zip
Once configured, the ksu
program works much like su you
type the program name followed by the name of the user whose privileges you
want to acquire. If you haven't configured a .k5login
or .k5users file, you must then
enter the password for that principal. If you've created an appropriate
authorization file, though, you won't need to enter any password. This approach
is also more secure if you're using any unencrypted connection.If you want to directly run a single program, you may do so by
specifying the -e progname parameter, where progname is the name of the program.
For instance, ksu fluffy -e /bin/ls
runs /bin/ls as fluffy .
Using
PAM with Kerberos
The replacement login
and su programs included with
Kerberos can be very useful, but they don't go far enough for many situations.
Of particular interest is the need for a way to control GUI logins for
workstations that should be authenticated through Kerberos. There are numerous
other local authentication tools you may want to link to Kerberos as well, such
as vlock or xscreensaver (which lock text-mode and GUI
sessions, respectively, until a user enters a password). There is a
general-purpose way to add Kerberos support to many such programs, but the
necessary tools aren't as widely available as are the tools that ship with
Kerberos. This method relies on Linux's support for the Pluggable Authentication Module (PAM) tools.PAM is intended as an intermediary between programs that
require authentication (such as FTP servers, login ,
and X-based login tools) and the underlying user and password databases (which
reside in /etc/passwd , /etc/shadow , and similar files in a
standard Linux installation). The idea behind PAM is that by abstracting
authentication procedures into a library, the underlying authentication files
can be easily changed without altering the numerous programs that rely upon
them; only PAM must be modified to understand the new file formats. In this
respect, implementing Kerberos support in PAM is the ideal way to provide
Kerberos support for numerous applicationsif you make these changes, the
programs that use PAM need no changes to support Kerberos.NOTE
align=left border=0> The Kerberos support provided through PAM is limited in
certain ways. In particular, if a program is hard-coded to request a username
and password, these prompts will not change if you alter PAM to use Kerberos.
The program will send the username and password to PAM for authentication,
and PAM will try to authenticate them against the Kerberos database. Thus, if
your FTP server, for instance, uses PAM, Kerberizing PAM won't eliminate the
need to enter a username and password. It might allow you to keep your FTP
passwords up to date with your Kerberos realm, though. This isn't a drawback
when it comes to a Kerberized login program, which should
always request a username and password.
Unfortunately, although PAM is a common authentication tool
among Linux distributions and many non-Linux systems, Kerberized versions of PAM
aren't as common as is the main Kerberos distribution. A few possible sources
include the following: Derrik Brashier's module This
is a module for use with Kerberos V4. It's available from
under various filenames beginning pam_krb4 ;
choose the one with the most recent date (all were in 1998 when I wrote this).
This package ships in source code form, so you'll have to compile it to use it. Frank Cusack's module One PAM
module that supports MIT Kerberos V5 and Heimdal is available from
(The version on this page is currently being maintained by Jacques Vidrine and
others.) This package is available in source code only and was originally
written for Solaris, but it does compile and work under Linux. Curtis King's module Curtis
King has made another Kerberos V5 PAM module available. It can be obtained from
ftp.dementia.org/pub/pam/ under the filename pam_krb5-1.1.3.tar.gz . It also requires
compilation, which may not go smoothly. Red Hat's module Red Hat has
made a Kerberos V5 PAM module available as part of its distribution, under the
package name pam_krb5 . This is
probably the easiest to install on Red Hat and similar distributions, because
it comes precompiled and is distributed in RPM format. I use this package as
the basis for the following discussion, but Frank Cusack's module works in much
the same way. Debian modules The libpam-krb5 and libpam-heimdal modules are available for
Debian systems, and should be easy to install if you're using Kerberos V5 or
Heimdal, respectively, on Debian or related distributions. These packages are
difficult to find from a package search on Debian's site, though; look for them
at target="_blank">http://ftp.nl.debian.org/debian/pool/non-US/main/libp/libpam-krb5/
and
target="_blank">http://ftp.nl.debian.org/debian/pool/non-US/main/libp/libpam-heimdal/ .When you install the Kerberized PAM, what you're installing is
a PAM module, which you can configure PAM to
use in certain specific cases. The PAM module consists of one or more library
files that are stored in /lib/security
or /usr/lib/security . In the
case of the Red Hat package, the files are called pam_krb5.so and pam_krb5afs.so .
To use these libraries, you must alter your PAM configuration files, which are
stored in /etc/pam.d . This
directory contains several files named after the servers or other programs that
require authentication support. For instance, /etc/
pam.d/login controls how the login
program interacts with PAM. To use Kerberos with these programs, you must
change or add lines to the PAM control files to tell PAM to use its new
Kerberos module. In fact, Red Hat's package includes a large number of sample
files in /usr/share/doc/ pam_krb5-version/pam.d ,
where version is the
package's version number. To simplify configuration, you can copy the
appropriate configuration files to /etc/pam.d .
Files you might want to consider copying include the following: login This
controls the login program. If
you install Kerberized PAM support, you can forego the official Kerberos login.krb5 program. gdm The
GNOME Display Manager (GDM) is one of three common GUI login tools in Linux.
(Consult Chapter 14 for information on how to configure
these servers.) xdm The X
Display Manager is another common GUI login tool, and the KDE Display Manager
uses XDM's configuration files, as well. In theory, this file should enable
these tools to use Kerberos for login authentication, but I've had problems
with this configuration on a Mandrake system. su and sudo
The su program, described
earlier, lets users change their identity once logged in. The ksu program does the same using Kerberos,
but you can achieve similar results by installing the Kerberized PAM control
file for su . The sudo control file provides similar
Kerberization for the sudo
command. passwd
This file tells PAM to send password changes, as handled through the passwd program, to the KDC. vlock The vlock program locks a console without
logging the user out; only after entering a password can the console be used
again. As you might expect, this control file causes vlock to use the KDC for authentication. xlock and xscreensaver
These programs both lock an X session, much as does vlock , but xscreensaver
can do so automatically after a period of user inactivity.Naturally, there are other programs whose PAM control files
you might want to modify to add Kerberos support. The details depend on your
system. Note that you don't need to modify the PAM files for services you're
explicitly Kerberizing. For instance, if you install a Kerberos-enabled FTP
server, you don't need to modify the /etc/pam.d/ftp
file. Explicitly Kerberized applications can communicate with the KDC for
authentication, bypassing PAM and the need to explicitly enter a username and
password that PAM requires.If you need to modify a PAM-using program to use Kerberos, you
must add or replace certain lines in the PAM configuration file. These files
specify four authentication services: auth (authenticating a user), account (checking that an account is
valid), password (changing a
password), and session (setting
up and terminating sessions). A PAM configuration file consists of one or more
lines for one or more of these services, describing what PAM modules are to be
involved in the process. For instance,
package.NOTE
align=left border=0> Different distributions often use substantially different
PAM configurations, so yours may call different PAM modules than those shown
in
deleting a reference to another module, is all you need to do to use a
Kerberized PAM.
Listing
6.4 A Sample PAM Configuration File with Kerberos Support
#%PAM-1.0 auth required /lib/security/pam_nologin.so auth sufficient /lib/security/pam_unix.so shadow md5 \ nullok likeauth auth required /lib/security/pam_krb5.so use_first_pass account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow md5 \ nullok use_authtok session required /lib/security/pam_unix.so session optional /lib/security/pam_krb5.so session optional /lib/security/pam_console.so
In this case, the important lines are the
final auth and the second session lines, which tell PAM to use Kerberos for login and logout, respectively.
The auth line includes the use_first_pass argument, which tells the
Kerberos PAM module that it's collecting the first password for a session. This
causes the module to behave like kinit , acquiring and storing a TGT. Most
Kerberos PAM modules can be configured in much this way, but some may need
something else. For instance, the password configuration file requires the
addition of a line like the following after the existing password entries: password required /lib/security/pam_krb5.so use_authtok
This is the case because the password module is used by the passwd program, which changes passwords rather than authenticate users. Some
files shouldn't have a session line, because this line causes authentication tickets to be
destroyed. For instance, the xscreensaver and linuxconf modules shouldn't destroy tickets because when these programs exit,
you're returned to a working login configuration in which the tickets you've
previously obtained should remain valid.In some cases, you may need to remove
existing entries from the /etc/pam.d configuration files. Specifically, if you add a pam_krb5.so entry for a service for which there is also a reference to the pam_pwdb.so library, you should remove the latter line. The pam_pwdb.so library
directly accesses the password database, and if both references are present,
the local password database and the Kerberos database must both authenticate the password. Although this may be
desirable in some very high-security situations, it limits the flexibility of
Kerberos, since users must ensure they change their passwords on the KDC and on
their local workstations simultaneously. If the PAM password configuration file includes a matching duplication, this is easily done with
the passwd tool for a single workstation, but coordinating such changes across
an entire network will be tedious at best.After you've made changes to your PAM
configuration, those changes should be immediately available; there's no PAM
daemon to restart. If a configuration affects a server or program that's
already running, though, you may need to restart it before it will use the new
configuration. In the case of login , the new configuration should take
effect after you log out of the console. For a GUI login tool like GDM, you may
need to restart the server.
