Beyond Linux From Scratch - Version 6.1

Chapter 4. Security

Heimdal-0.7

Introduction to Heimdal

Heimdal is a free implementation
of Kerberos 5 that aims to be compatible with MIT krb5 and is
backward compatible with krb4. Kerberos is a network authentication
protocol. Basically it preserves the integrity of passwords in any
untrusted network (like the Internet). Kerberized applications work
hand-in-hand with sites that support Kerberos to ensure that
passwords cannot be stolen or compromised. A Kerberos installation
will make changes to the authentication mechanisms on your network
and will overwrite several programs and daemons from the
Coreutils, Inetutils, Qpopper and Shadow packages.

Heimdal Dependencies

Required

Optional

Note

Some sort of time synchronization facility on your system (like
NTP-4.2.0) is required since
Kerberos won't authenticate if the time differential between a
kerberized client and the KDC server is more than 5 minutes.

Installation of Heimdal

Before installing the package, you may want to preserve the
ftp program from the
Inetutils package. This is because
using the Heimdalftp program to
connect to non-kerberized ftp servers may not work properly. It
will allow you to connect (letting you know that transmission of
the password is clear text) but will have problems doing puts and
gets. Issue the following command as the root user.

mv -v /usr/bin/ftp /usr/bin/ftpn

If you wish the Heimdal package to
link against the CrackLib library
(requires CrackLib-2.8.3 installed with
the heimdal patch), you must apply a
patch:

Command Explanations

--libexecdir=/usr/sbin: This
switch puts the daemon programs into /usr/sbin.

Tip

If you want to preserve all your existing Inetutils package daemons, install the
Heimdal daemons into
/usr/sbin/heimdal (or wherever you
want). Since these programs will be called from
(x)inetd or
rc scripts, it really doesn't matter
where they are installed, as long as they are correctly
specified in the /etc/(x)inetd.conf
file and rc scripts. If you choose
something other than /usr/sbin, you
may want to move some of the user programs (such as
kadmin) to
/usr/sbin manually so they'll be in
the privileged user's default PATH.

mv ... .shadow; mv ... /bin; ln -v
-sf ../../bin...: The login and su programs installed by Heimdal belong in the /bin directory. The login program is symlinked because
Heimdal is expecting to find it in
/usr/bin. The old executables are
preserved before the move to keep things sane should breaks occur.

mv ... /lib; ln -v -sf
../../lib/lib... /usr/lib...: The
login and
su programs installed
by Heimdal link against
Heimdal libraries as well as
libraries provided by the OpenSSL
and Berkeley DB packages. These
libraries are moved to /lib to be FHS
compliant and also in case /usr is
located on a separate partition which may not always be mounted.

Configuring Heimdal

Config
Files

/etc/heimdal/*

Configuration
Information

Note

All the configuration steps shown below must be accomplished
by the root user unless otherwise
noted.

You will need to substitute your domain and proper hostname for
the occurrences of the [hostname] and [EXAMPLE.COM] names.

default_realm should be the name of
your domain changed to ALL CAPS. This isn't required, but both
Heimdal and MIT krb5 recommend it.

encrypt = true provides encryption of
all traffic between kerberized clients and servers. It's not
necessary and can be left off. If you leave it off, you can
encrypt all traffic from the client to the server using a
switch on the client program instead.

The [realms] parameters tell the client
programs where to look for the KDC authentication services.

The [domain_realm] section maps a
domain to a realm.

Store the master password in a key file using the following
commands:

install -v -m755 -d /var/lib/heimdal &&
kstash

Create the KDC database:

kadmin -l

The commands below will prompt you for information about the
principles. Choose the defaults for now unless you know what
you are doing and need to specify different values. You can go
in later and change the defaults, should you feel the need. You
may use the up and down arrow keys to use the history feature
of kadmin in a
similar manner as the bash history feature.

At the kadmin> prompt, issue the
following statement:

init [EXAMPLE.COM]

The database must now be populated with at least one principle
(user). For now, just use your regular login name or root. You
may create as few, or as many principles as you wish using the
following statement:

add [loginname]

The KDC server and any machine running kerberized server
daemons must have a host key installed:

add --random-key host/[hostname.example.com]

After choosing the defaults when prompted, you will have to
export the data to a keytab file:

ext host/[hostname.example.com]

This should have created two files in /etc/heimdal: krb5.keytab (Kerberos 5) and srvtab (Kerberos 4). Both files should have 600
(root rw only) permissions. Keeping the keytab files from
public access is crucial to the overall security of the
Kerberos installation.

Eventually, you'll want to add server daemon principles to the
database and extract them to the keytab file. You do this in
the same way you created the host principles. Below is an
example:

add --random-key ftp/[hostname.example.com]

(choose the defaults)

ext ftp/[hostname.example.com]

Exit the kadmin
program (use quit
or exit) and
return back to the shell prompt. Start the KDC daemon manually,
just to test out the installation:

/usr/sbin/kdc &

Attempt to get a TGT (ticket granting ticket) with the
following command:

kinit [loginname]

You will be prompted for the password you created. After you
get your ticket, you should list it with the following command:

klist

Information about the ticket should be displayed on the screen.

To test the functionality of the keytab file, issue the following command:

ktutil list

This should dump a list of the host principals, along with the
encryption methods used to access the principals.

At this point, if everything has been successful so far, you
can feel fairly confident in the installation, setup and
configuration of your new Heimdal Kerberos 5 installation.

Using Kerberized
Client Programs

To use the kerberized client programs (telnet, ftp, rsh, rxterm, rxtelnet, rcp, xnlock), you first must get a TGT.
Use the kinit
program to get the ticket. After you've acquired the ticket,
you can use the kerberized programs to connect to any
kerberized server on the network. You will not be prompted for
authentication until your ticket expires (default is one day),
unless you specify a different user as a command line argument
to the program.

The kerberized programs will connect to non-kerberized daemons,
warning you that authentication is not encrypted. As mentioned
earlier, only the ftp program gives any trouble
connecting to non-kerberized daemons.

In order to use the HeimdalX programs, you'll need to add
a service port entry to the /etc/services file for the kxd server. There is no 'standardized
port number' for the 'kx' service in the IANA database, so
you'll have to pick an unused port number. Add an entry to the
services file similar to the entry
below (substitute your chosen port number for [49150]):

Short Descriptions

takes a principal database in a specified format and
converts it into a stream of Heimdal database records.

hpropd

is a server that receives a database sent by
hprop and
writes it as a local database.

ipropd-master

is a daemon which runs on the master KDC server which
incrementally propagates changes to the KDC database to
the slave KDC servers.

ipropd-slave

is a daemon which runs on the slave KDC servers which
incrementally propagates changes to the KDC database from
the master KDC server.

kadmin

is a utility used to make modifications to the Kerberos
database.

kadmind

is a server for administrative access to the Kerberos
database.

kauth

is a symbolic link to the kinit program.

kcm

is a process based credential cache for Kerberos tickets.

kdc

is a Kerberos 5 server.

kdestroy

removes a principle's current set of tickets.

kf

is a program which forwards tickets to a remote host
through an authenticated and encrypted stream.

kfd

is a server used to receive forwarded tickets.

kgetcred

obtains a ticket for a service.

kinit

is used to authenticate to the Kerberos server as a
principal and acquire a ticket granting ticket that can
later be used to obtain tickets for other services.

klist

reads and displays the current tickets in the credential
cache.

kpasswd

is a program for changing Kerberos 5 passwords.

kpasswdd

is a Kerberos 5 password changing server.

krb5-config

gives information on how to link programs against
Heimdal libraries.

kstash

stores the KDC master password in a file.

ktutil

is a program for managing Kerberos keytabs.

kx

is a program which securely forwards X connections.

kxd

is the daemon for kx.

login

is a kerberized login program.

otp

manages one-time passwords.

otpprint

prints lists of one-time passwords.

pfrom

is a script that runs push
--from.

popper

is a kerberized POP-3 server.

push

is a kerberized POP mail retrieval client.

rcp

is a kerberized rcp client program.

rsh

is a kerberized rsh client program.

rshd

is a kerberized rsh server.

rxtelnet

starts a secure xterm window with a
telnet to a
given host and forwards X connections.

rxterm

starts a secure remote xterm.

string2key

maps a password into a key.

su

is a kerberized su client program.

telnet

is a kerberized telnet client program.

telnetd

is a kerberized telnet server.

tenletxr

forwards X connections
backwards.

verify_krb5_conf

checks krb5.conf file for
obvious errors.

xnlock

is a program that acts as a secure screen saver for
workstations running X.

libasn1.[so,a]

provides the ASN.1 and DER functions to encode and decode
the Kerberos TGTs.

libeditline.a

is a command-line editing library with history.

libgssapi.[so,a]

contain the Generic Security Service Application
Programming Interface (GSSAPI) functions which provides
security services to callers in a generic fashion,
supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability
of applications to different environments.