LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/HOWTO/text/Kerberos-Infrastructure-HOWTO

1049 lines
49 KiB
Plaintext
Raw Permalink Blame History

Kerberos Infrastructure HOWTO
V. Alex Brennen
<vab@cryptnet.net>
2004-05-29
Revision History
Revision 2.0.0 2004-05-28 Revised by: VAB
Conversion to DocBook XML. General Content Updates, including incorporation
of Technical and Metadata/Markup Reviews.
Revision 1.0.3 2003-04-01 Revised by: VAB
Minor Updates, Minor Corrections, Additional links added.
Revision 1.0.2 2002-09-13 Revised by: VAB
Minor Updates, Minor Corrections, Added 8.6, Additional links added.
Revision 1.0.1 2002-07-15 Revised by: VAB
Minor Updates, Fixes.
Revision 1.0.0 2002-06-13 Revised by: VAB
Initial Release.
This document describes the design and configuration of a Kerberos
infrastructure for handling authentication with GNU/Linux. It details steps
for a best practices method of setting up servers, Kerberos software,
conversion of legacy systems, and answers frequently asked questions.
-----------------------------------------------------------------------------
Table of Contents
1. About this Document
1.1. General Information
1.2. Translations
1.3. Credits and Contributors
1.4. Feedback
2. An Overview of a Kerberos Infrastructure
2.1. An Introduction to Kerberos
2.2. The Benefits of Kerberos
2.3. How Kerberos Works
2.4. Compromise of Kerberos Infrastructure
3. Installing and Configuration
3.1. General Machine Configuration Overview
3.2. Hardware
3.3. GNU/Linux Installation
3.4. Choosing A Realm
3.5. Kerberos Software Configuration
3.6. Principal Creation
4. Time Synchronization
4.1. The Importance of Time Synchronization
4.2. Introduction to NTP
4.3. NTP Installation and Configuration
5. Kerberos Server Replication
5.1. Description of Replication
5.2. Implementation
5.3. Maintenance
6. Client Configuration
6.1. General GNU/Linux Client Configuration
6.2. PAM
6.3. Apache Web Server
6.4. Microsoft Windows
7. Programming With Kerberos
7.1. The Kerberos API
A. Relevant Sources for More Information
A.1. Links to related documents
A.2. Related web sites
A.3. Related RFCs
A.4. Other references
A.5. Additional resources
A.6. Companies which provide specialist Kerberos consulting
Glossary of Terms
1. About this Document
1.1. General Information
Copyright (c) 2002-2004 [http://cryptnet.net/people/vab/] V. Alex Brennen
([http://cryptnet.net/people/vab/] VAB).
This document is hereby placed in the public domain.
This document lives at [http://cryptnet.net/fdp/admin/kerby-infra/en/
kerby-infra.html] http://cryptnet.net/fdp/admin/kerby-infra/en/
kerby-infra.html
-----------------------------------------------------------------------------
1.2. Translations
This document is currently only available in the following languages:
<EFBFBD><EFBFBD>*<2A> [[http://cryptnet.net/fdp/admin/kerby-infra/en/kerby-infra.html] en]
English
If you know of a translation or would like to translate it to another
language please [mailto:vab@cryptnet.net] let me know so that I can
distribute or link to the translated versions.
-----------------------------------------------------------------------------
1.3. Credits and Contributors
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/people/vab/] V. Alex Brennen ([http://cryptnet.net/
people/vab/] VAB) <vab (at) cryptnet.net> (Principal Author)
<EFBFBD><EFBFBD>*<2A> [http://kolya.net/] Nickolai Zeldovich <kolya (at) zepa.net> (Technical
suggestions, technical corrections)
-----------------------------------------------------------------------------
1.4. Feedback
Please send any additions, comments, corrections and criticisms to the
following email address: <vab@cryptnet.net>.
-----------------------------------------------------------------------------
2. An Overview of a Kerberos Infrastructure
2.1. An Introduction to Kerberos
Kerberos is a system of authentication developed at MIT as part of the
Athena project. Kerberos uses encryption technology and a trusted third
party, an arbitrator, to perform secure authentication on an open network.
Specifically, Kerberos uses cryptographic tickets in order to avoid
transmitting plain text passwords over the wire. Kerberos was based upon the
Needham-Schroeder protocol.
There are two versions of Kerberos currently in use, version 4 and version
5. Kerberos versions 1 through 3 were internal development versions and never
released. Kerberos version 4 has a number of known weaknesses and should no
long be used. This document deals only with Kerberos 5. Kerberos 5 is defined
in [http://cryptnet.net/mirrors/rfcs/rfc1510.txt] RFC1510.
The term Kerberos Infrastructure refers to the software, servers, and client
configurations that will allow an administrator to use the Kerberos protocol
to perform authentication on their network. Specifically, Kerberos
Infrastructure consists of the Kerberos software itself, secured redundant
authentication servers, a centralized account and password store, and systems
configured to authenticate through the Kerberos protocol. This document will
take you through the steps to install, configure, and deploy such an
infrastructure.
-----------------------------------------------------------------------------
2.2. The Benefits of Kerberos
For individuals unfamiliar with the Kerberos protocol, the benefits of
deploying it in their network may not be clear. However, all administrators
are familiar with the problems Kerberos was designed to mitigate. Those
problems include, password sniffing, password filename/database stealing, and
the high level of effort necessary to maintain a large number of account
databases.
A properly deployed Kerberos Infrastructure will help you address these
problems. It will make your enterprise more secure. Use of Kerberos will
prevent plaintext passwords from being transmitted over the network. The
Kerberos system will also centralize your username and password information
which will make it easier to maintain and manage this data. Finally, Kerberos
will also prevent you from having to store password information locally on a
machine, whether it is a workstation or server, thereby reducing the
likelihood that a single machine compromise will result in additional
compromises.
To summarize, in a large enterprise, the benefits of Kerberos will translate
into reduced administration costs through easier account and password
management and through improved network security. In a smaller environment,
scalable authentication infrastructure and improved network security are the
clear benefits.
-----------------------------------------------------------------------------
2.3. How Kerberos Works
Kerberos is an authentication protocol which uses a shared secret and a
trusted third party arbitrator in order to validate the identity of clients.
In Kerberos, clients may be users, servers, or pieces of software. The
trusted third party arbitrator is a server known as a Key Distribution Center
(KDC) which runs the Kerberos daemons. The shared secret is the users
password transformed into a cryptographic key. In the case of servers or
software systems, a random key is generated.
In Kerberos, users are known as principals. The KDC has a database of
principals and their secret keys which is uses to perform authentication. In
Kerberos knowledge of the secret key is considered sufficient for proof of
identity. Since knowledge of a secret key translates into proof of identity
in Kerberos, the Kerberos server can be trusted to authenticate any client to
any other client. Authentication is Kerberos is done with out sending any
clear text passwords across the wire. Below I'll explain how the Kerberos
protocol maps to the GNU/Linux Kerberos software.
The KDC runs two important Kerberos daemons. These daemons are kadmind and
krb5kdc. While GNU/Linux daemon naming conventions suggests that processes
which have names starting with "k" are Kernel related or Kernel space
processes, this is not true in the case of krb5kdc and kadmind. These two
daemons are run as root in user space.
kadmind is the administrative daemon for the Kerberos server. kadmind is
used by a program named kadmin to maintain the database of principals and
policy configuration. If you choose to disallow any remote logins via ssh on
your Kerberos hardware, kadmin will allow you to remotely administer the
Kerberos components of the server.
krb5kdc is the workhorse of the Kerberos server. It is responsible for
performing the role of the trusted third party arbitrator in Kerberos
authentication. When a user wants to authenticate himself to a system or
service, the user requests a ticket from the KDC. A ticket is a datagram
consisting of the client's identity, a session key, a timestamp, and some
other information. The datagram is encrypted with the server's secret key.
In detail that process works as follows, first the request for
authentication is sent to the krb5kdc daemon. When the daemon received this
request, it looks up the client, the principal, trying to authenticate in the
principal database. It reads the clients secret key from this database and
encrypts a special ticket called a Ticket Granting Ticket (TGT) which it then
sends back the client. The client receives this encrypted TGT which contains
a session key. If the client knows the password (the secret key stored in the
principal database) and can successfully decrypt the TGT, it can present the
ticket encrypted with the enclosed session key to a Ticket Granting Service
(TGS). The TGS will then issue a subsequent ticket which will provide the
client with the authentication they need to use a specific system or service.
Through the use of encrypted tickets which can only be decrypted if the
client knows the secret key, secure authentication takes place. Time stamp
information is included in the tickets to prevent replay attacks. A replay
attack would be the fraudulent representation of a previously issued ticket
in order to gain unauthorized access.
-----------------------------------------------------------------------------
2.4. Compromise of Kerberos Infrastructure
The primary way in which an attacker will attempt to compromise a Kerberos
Infrastructure would be to attack the Kerberos servers. If an attacker can
gain root access to a KDC, the attacker will have access to the database of
encrypted passwords of the principals. The attacker will also have access to
the Kerberos software and configuration files both of which they can then
modify to make the system perform authentications which should not be
successful.
Other methods of attacking Kerberos infrastructure include replay attacks
and password-guessing attacks. A replay attack would involve intercepting or
otherwise acquiring a Kerberos ticket and then fraudulently representing that
ticket in an attempt to gain authentication. Password guessing in a Kerberos
system could be done by intercepting Kerberos tickets from the network and
then making a brute force attempt to decrypt the intercepted tickets.
An attacker may exploit outdated software in the infrastructure. For
example, there are many problems with Kerberos version 4. Most importantly,
Kerberos version 4 has a basic protocol weakness in the encryption used. The
design of Kerberos 4 included the use of DES in standard mode which allows
attackers to intercept and modify the ciphertext of Kerberos tickets in an
undetectable way. In order to prevent these attacks, Kerberos 5 has been
modified to use triple DES in Cipher Block Chaining (CBC) mode.
When discussing the strength of Kerberos 4, it is also important to note
that many implementations of Kerberos version 4 have buffer overflow
vulnerabilities. While the reference implementations of version 5 fixed the
buffer overflow weaknesses in version 4, distributions of Kerberos 5 usually
ship with software to provide backward compatibility to support legacy
Kerberos 4 applications. Some of the backward compatibility code for version
4 support in Kerberos version 5 releases is still believed to be vulnerable
to buffer overflow attacks.
Therefore, due to the protocol weaknesses in version 4 and the potential for
buffer overflow attacks with version 4 implementations and version 4 backward
compatibility code, it is best not to support or use Kerberos version 4.
In summary, from this description on how a Kerberos infrastructure can be
compromised, we realize that we must give great priority to the security of
the Kerberos servers themselves, run up to date Kerberos software, and remain
vigilant in picking good passwords and in setting good password policy.
-----------------------------------------------------------------------------
3. Installing and Configuration
3.1. General Machine Configuration Overview
This section of the document describes the installation and configuration of
the machines and software which will function as the KDCs. You may want to
make some adjustments to the configurations suggested, but there are a few
key points presented that are very important to remember when configuring
your KDCs. So, if you do decide on an alternative configuration strategy make
sure you understand the material presented here.
The machines will run the Kerberos daemon and store password and policy
data. Therefore, it's very important to the security of the network that
these servers remain secure. We should take every possible measure to prevent
these servers from being compromised. Pay particular attention to the
security advice given in this section.
The key points of that security advice are that you should dedicate hardware
to providing Kerberos KDC service. You should physically secure that
hardware, and you should harden GNU/Linux as much as possible on that
hardware. If a KDC is compromised, your entire Kerberos infrastructure is
compromised.
-----------------------------------------------------------------------------
3.2. Hardware
Kerberos service does not place a great demand on hardware and the Kerberos
services have a capability for redundancy, therefore server hardware can be
minimal. For the Kerberos servers which I've deployed I've used uniprocessor
PIII machines with two hardware RAID 1 drives. These machines are meant to
handle between forty and one hundred thousand authentications per day. While
servers may be deployed with redundant NIC cards, having both cards active
simultaneously should be avoided. Kerberos includes the IP of the KDC in
tickets, therefore difficulties authenticating may occur if the KDC is
contacted on multiple interfaces by a client during an authentication
session.
It is important to note that Kerberos service should be run on dedicated
hardware. Dedicating a machine to Kerberos means that only the Kerberos
administrator will need to log in on those machines. It also means that no
other services, except perhaps SSH, will be run on the machines. Since all of
your users passwords are stored on the Kerberos servers, it is a good idea to
limit access as much as possible to the hardware. Along with dedicating
servers to Kerberos, you should also physically secure your servers as much
as possible. For Kerberos servers, this may include locking the servers in a
cabinet and having a dedicated terminal attached to them.
In order to take advantage of Kerberos' built in capability for redundancy,
you must have at least two machines running as KDCs. Kerberos is designed to
be deployed with one primary master server, and one or more secondary slave
servers. You may have as many secondary servers as you would like.
-----------------------------------------------------------------------------
3.3. GNU/Linux Installation
The servers we're installing GNU/Linux on will be dedicated to the task of
performing Kerberos service, therefore we can take some extra steps to secure
them.
First, we'll only install software that is absolutely necessary for Kerberos
service. This includes the base operating system and the Kerberos packages.
We should not install X or any GUI applications. SSH is optional. SSH may be
installed if you wish to be able to administer the servers remotely. However,
the servers would be significantly more secure if you only provide login
access to them through an attached terminal.
In Fedora Core based GNU/Linux, the packages required to provide Kerberos
service are:
krb5-server
krb5-libs
Documentation and development libraries should not be installed on the KDC,
since we do not want to use this machine for anything but the performance of
KDC service.
The next step will be to make sure that no ports are open that do not need
to be and that any necessary security patches that are needed are applied.
The methodology to determining what security patches need to be applied is
depended up what package management software is installed. To determine what
ports the machine is currently listening on, the netstat command can be used.
For example, on a machine which only ssh running we should see the following:
bash$ netstat -an | grep -i listen | less
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
Finally, we'll configure the server to restrict access only to servers that
need to talk to it for authentication. This should be done by editing /etc/
hosts.allow and /etc/hosts.deny as well as with iptables.
-----------------------------------------------------------------------------
3.4. Choosing A Realm
Realm names are case sensitive and must be unique on your network. It is a
standard best practice to use your second level domain name in all uppercase
letters as your realm name. If you are setting up Kerberos for only a subnet
rather than your entire network, you should use the trailing domain name of
the subnet.
When determining your realm topology, you should take the overall structure
of your organization into account. If your organization has one or more
remote offices or independent sub groups, they may be best included under a
separate realm. Kerberos realm topology should mirror system management
topology rather than physical network topology.
Finally, legacy systems should also be taken into account. For example,
legacy Kerberos deployments or existing network topology grouping which you
wish to preserve (i.e. Windows NT domains).
If you are installing Kerberos on a network which already has Kerberos
deployed in the overall network or in a subnet, you must avoid a realm name
collision. The most common occurrence of deploying Kerberos on a network with
a preexisting Kerberos installation occurs when working with a network that
includes an IBM SP cluster. The best solution is to create a realm
specifically for the SP cluster at third or high domain name level and then
use a second level domain name for your primary Kerberos realm.
In this document, we'll use an example to help illustrate the design and
configuration of an infrastructure. For our example, we'll use a mythical
university which was founded to educate people with, and perform research in
the area of, free content - Gnu University in Dublin, Ireland. The Gnu
University Dublin example will include two Kerberos servers used to
authenticate students and faculty. The TLD for the university is gnud.ie,
therefore we'll use the Kerberos realm of GNUD.IE.
-----------------------------------------------------------------------------
3.5. Kerberos Software Configuration
Now, you'll need to configure Kerberos, create an administrator, determine a
policy, and initialize the Kerberos principal database.
The first step is to edit the /etc/krb5.conf configuration file. In this
file you'll need to set your realm, expand on the realm definition by
specifying the Kerberos servers, and finally setting the domain realm. For
our example, this is done as follows:
default_realm = GNUD.IE
[realms]
GNUD.IE = {
kdc = kerberos1.gnud.ie:88
kdc = kerberos2.gnud.ie:88
admin_server = kerberos1.gnud.ie:749
default_domain = gnud.ie
}
[domain_realm]
.gnud.ie = GNUD.IE
gnud.ie = GNUD.IE
To initialize and create the Kerberos database, you must run the follow
command:
{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util create -s
The -s flag tell the KDC to create a stash file to authenticate itself. You
may also use a -r flag to specify a realm. Specifying a realm for the new
database is only necessary if you have more than one realm defined in your
krb5.conf file.
Kerberos will then ask you to set the master password for your Kerberos
database. It is very important that you do not forget this password. You will
not be able to administrate your server if you do not remember the master
password.
Next on the KDC you must edit the acl file to grant administrative access.
Typically, this file is located at /var/Kerberos/krb5kdc/kadm5.acl. If
necessary, specify the acl file location in your kdc.conf file. The location
of your kdc.conf file is specified in your /etc/krb5.conf file and defaults
to /var/Kerberos/krb5kdc/kdc.conf. For our GNU University Dublin example,
we'll modify the acl file to include the following contents:
*/admin@GNUD.IE *
The meaning of those acl contents are that any account which ends with a /
admin in the GNUD.IE realm is granted full access privileges.
Now that we've set up access for our administrative user, we need to create
that administrative user. You can do this with the kadmin.local command from
a root shell on the KDC, using the addprinc sub command. The standard is to
name the administrative account admin. For the Gnu University Dublin Kerberos
Administrator, the following command would accomplish this:
{Kerberos1}bash# /usr/Kerberos/sbin/kadmin.local -q "addprinc admin/admin"
The daemons that must run on the server are krb5kdc and kadmin. If
necessary, krb524 may also be run to provide backward compatibility to
Kerberos 4 clients. However, before starting krb524 remember our security
warning about Kerberos V4 and be sure that you really need to provide that
functionality. On the KDCs krb5kdc and kadmin should be configured to start
automatically by turning them on with the chkconfig command.
{Kerberos1}bash# /sbin/chkconfig krb5kdc on
{Kerberos1}bash# /sbin/chkconfig kadmin on
Finally, we can start them up manually, with the following command:
{Kerberos1}bash# /etc/rc.d/init.d/krb5kdc start
{Kerberos1}bash# /etc/rc.d/init.d/kadmin start
and we have a working KDC.
-----------------------------------------------------------------------------
3.6. Principal Creation
You can create the first user principal in Kerberos with the following
command:
{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local: addprinc <username>
A script could be written to create principals in bulk if you have a large
number of account which you will be supporting with Kerberos.
-----------------------------------------------------------------------------
4. Time Synchronization
4.1. The Importance of Time Synchronization
Since the security of Kerberos authentication is in part based upon the time
stamps of tickets, it is critical to have accurately set clocks on Kerberos
servers. As we mentioned in the introduction to Kerberos, a short lifetime
for tickets is used to prevent attackers from performing successful brute
force attacks or replay attacks.
If you allow your clocks of your servers to drift, you will make your
network vulnerable to such attacks. Since clock synchronization is so
important in the security of the Kerberos protocol, if clocks are not
synchronized with in a reasonable window Kerberos will report fatal errors
and refuse to function. Clients attempting to authenticate from a machine
with an inaccurate clock will be failed by the KDC in authentication attempts
due to the time difference with the KDC's clock.
-----------------------------------------------------------------------------
4.2. Introduction to NTP
The Network Time Protocol (NTP) is available for the time synchronization of
servers. A number of public NTP servers are available for synchronization.
NTP is capable of synchronizing client clocks within milliseconds on LANs,
and tens of milliseconds over WANs. NTP servers are divided by stratum.
Primary NTP servers are classified as stratum 1. These public primary servers
should not be used for synchronization of client machines due to the
relatively small number of them. Public stratum 2 servers are available for
client machine synchronization and synchronize their own clocks with the
public stratum 1 servers. For our Kerberos servers, we'll set up NTP to query
against three stratum two servers. A maintained list of public stratum two
servers can be [http://www.eecis.udel.edu/~mills/ntp/clock2b.html] found
here.
-----------------------------------------------------------------------------
4.3. NTP Installation and Configuration
In order to turn NTP on GNU/Linux, you must install the NTP package and edit
the configuration filename. By default, the NTP configuration filename is /
etc/ntp.conf. The default values in the configuration are acceptable. All
that needs to be done is to add the servers we wish to use to synchronize our
clocks. Authentication is not necessary, but authentication can be enabled
from additional security. If you're using NTP servers on your LAN, you may
wish to use authentication. Here is a sample [http://cryptnet.net/fdp/admin/
kerby-infra/en/ntp.conf] ntp.conf filename from the Gnu University Dublin.
Finally we put a cron job in place to do the actual synchronization:
30 * * * * /usr/sbin/ntpdate -s
If our systems are behind a firewall we may need to provide use -su rather
than just -s. The -u argument will direct ntpdate to use an unprivileged port
for its outgoing connection to the stratum 2 time servers.
-----------------------------------------------------------------------------
5. Kerberos Server Replication
5.1. Description of Replication
Kerberos was designed to allow for a Master/Slave replication cluster. While
a Kerberos cluster can consist of any number of hosts, it is recommended that
you have at least two. A master which serves as the primary server and at
least one slave which is available as a backup to the master. The master and
slave servers may be thought of as Primary and Secondary servers
respectively.
Kerberos stores all of its information, both account and policy data, in
application databases. The Kerberos software distribution includes software
for replicating, or copying, this data to other servers.
Kerberos client applications are designed to attempt authentication against
secondary servers if the primary master is down. Therefore you do not need to
do any extra work during a system failure to fail over your Kerberos
authentication service to the backup server. However, the administrative
features of Kerberos do not provide for automatic failover.
In the event that your primary server fails, kadmind will be unavailable.
Therefore, administrative functions will be unavailable until the primary
server is restored or replace. Specifically, principal management, key
creation, and key changes, cannot be done during a primary server failure.
-----------------------------------------------------------------------------
5.2. Implementation
Server replication is handled by the kprop command. kprop must be run on the
primary master KDC. It should be run in a scheduled cron job to keep the
principal database in sync across all servers.
The first step in setting up replication, is to set up ACLs for kpropd. The
kpropd acl filename is by default located at /var/Kerberos/krb5kdc/
kpropd.acl. In our example, it would have the following contents:
host/kerberos1.gnud.ie@GNUD.IE
host/kerberos2.gnud.ie@GNUD.IE
The kpropd.acl file should only exist on the slave Kerberos server. In
Fedora derived GNU/Linux, kadmin will not run on a Kerberos server on which /
var/Kerberos/krb5kdc/kpropd.acl exists.
Next you'll need to create host keys for your master and slave Kerberos
servers:
{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local: addprinc -randkey host/kerberos1.gnud.ie
{Kerberos1}kadmin.local: addprinc -randkey host/kerberos2.gnud.ie
The next step is to extract these keys to the keytab file. The keytab file
is a keyring which contains the cryptographic keys needed to authenticate
with the KDC. Extraction of keys to the keytab is done with the ktadd sub
command:
{Kerberos1}kadmin.local: ktadd host/kerberos1.gnud.ie
{Kerberos1}kadmin.local: ktadd host/kerberos2.gnud.ie
Finally, we want to copy the keytab over to the slave server so that it has
the keys it needs available to authenticate.
{Kerberos2}bash# scp root@kerberos1.gnud.ie:/etc/krb5.keytab /etc
Here is a crontab entry from the master Kerberos server used to synchronize
principal databases every fifteen minutes:
15 * * * * /usr/local/bin/krb5prop.sh
Here are the contents of the krb5prop.sh script:
#!/bin/sh
/usr/Kerberos/sbin/kdb5_util dump /var/Kerberos/krb5kdc/slave_datatrans
/usr/Kerberos/sbin/kprop -f /var/Kerberos/krb5kdc/slave_datatrans kerberos2.gnud.ie > /dev/null
Initially running this command by hand, you should see something similar to
the following:
{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util dump /var/Kerberos/krb5kdc/slave_datatrans
{Kerberos1}bash# /usr/Kerberos/sbin/kprop -d -f /var/Kerberos/krb5kdc/slave_datatrans kerberos2.gnud.ie
3234 bytes sent.
Database propagation to kerberos2.gnud.ie: SUCCEEDED
{Kerberos1}bash#
The slave server will now synchronize its principal database with the master
server.
-----------------------------------------------------------------------------
5.3. Maintenance
With these cron jobs in place principal propagation should be sufficiently
automated as to require no maintenance. At the time of a primary KDC failure,
there is no need for human intervention unless the failure will last for an
extended period of time.
-----------------------------------------------------------------------------
6. Client Configuration
6.1. General GNU/Linux Client Configuration
GNU/Linux distributions of Kerberos include a client package which contains
all of the software and configuration files needed for setting up a GNU/Linux
machine to be able to perform Kerberos authentications against a KDC. In
Fedora derived GNU/Linux, this package is krb5-workstation. In order for your
system to be capable of Kerberos authentication, including by authentication
by kerberized applications, you must configure Kerberos on the system.
Configuration involves editing the /etc/krb5.conf file. In this file, you
must specify your realm, KDC's, administrative server, logging, default
domain, and KDC information. You must also modify the kdc.conf file, which
you are allowed to specify a location for in the krb5.conf file. The default
location is /var/Kerberos/krb5kdc/kdc.conf. The kdc.conf file contains
information about the encryption algorithm policy of the realm.
The configuration information for the system on which you wish to perform
Kerberos authentications is the same information which was placed in the /etc
/krb5.conf filename on the KDC. Here are example [http://cryptnet.net/fdp/
admin/kerby-infra/en/krb5.conf] krb5.conf and [http://cryptnet.net/fdp/admin/
kerby-infra/en/kdc.conf] kdc.conf configuration files from a client for the
Gnu University Dublin example.
Now, you can test Kerberos authentication using the kinit command:
bash$ kinit <username>
If your authentication fails, the best place to look for a description of
the cause are the system log files on the client and the KDC log file on the
KDC which authentication was performed against. When trouble shooting
authentication issues, it can be very helpful to have a terminal windows open
to the KDC running a tail -f on the KDC log. In our example krb5.conf, the
location of the KDC log was /var/log/Kerberos/krb5kdc.log.
-----------------------------------------------------------------------------
6.2. PAM
PAM, or Pluggable Authentication Module, technology which is shipped with
many distributions of GNU/Linux is capable of integration with Kerberos
through the pam_krb5 module. In order to use Kerberos authentication with PAM
you must install the pam_krb5 module and modify the pam configuration files.
The pam_krb5 module comes with sample configuration filenames which are
located in /usr/share/doc/pam_krb5-1.55/pam.d. The basic change that these
configuration files make to allow PAM controlled services to authenticate
against Kerberos is similar to the following:
auth required /lib/security/pam_krb5.so use_first_pass
-----------------------------------------------------------------------------
6.3. Apache Web Server
Kerberos can be used as an authentication mechanism for the Apache Web
Server. The mod_auth_kerb application is an apache module which provides that
functionality. Using that module, you will be able to set Kerberos as an
authentication type for access control stanzas in the httpd.conf file. Be
aware that while Kerberos is being used, this is a less than ideal
authentication mechanism because tickets are stored on the web server rather
than on the client machine. However, if your goals is to implement a single
sign-on solution or consolidate accounts, there is value here. mod_auth_kerb
is capable of supporting Kerberos 4, however that is not covered in this
howto because of the known weaknesses with version 4 of the protocol.
The mod_auth_kerb website can be found at [http://
modauthkerb.sourceforge.net/] http://modauthkerb.sourceforge.net/. It is
important to use the HTTPS protocol when accessing a site which uses
mod_auth_kerb, since mod_auth_kerb uses the base auth mechanism. Base auth
uses base64 encoding which can easily be translated back to plaintext.
Therefore it's important that the authentication exchange is SSL encrypted to
ensure that the user name and password are protected when they are
transmitted to the webserver.
To compile apache with the mod_auth_krb module, you must take the following
steps:
bash$ export 'LIBS=-L/usr/Kerberos/lib -lkrb5 -lcrypto -lcom_err'
bash$ export 'CFLAGS=-DKRB5 -DKRB_DEF_REALM=\\\"GNUD.IE\\\"'
bash$ export 'INCLUDES=-I/usr/Kerberos/include'
bash$ mkdir apache_x.x.x/src/modules/kerberos
bash$ cp mod_auth_kerb-x.x.x.c apache_x.x.x/src/modules/kerberos
bash$ ./configure --prefix=/home/httpd --add-module=src/modules/Kerberos/mod_auth_kerb.c
bash$ make
bash$ make install
You should test apache to make sure that it works. Once you have a known
working copy of SSL enabled apache on the machine you can modify the
httpd.conf filename to provide Kerberos authentication for a directory:
Here is an example stanza from the mod_auth_kerb apache modules which
enables Kerberos 5 authentication for a directory:
<Directory "/home/httpd/htdocs/content">
AllowOverride None
AuthType KerberosV5
AuthName "Kerberos Login"
KrbAuthRealm GNUD.IE
require valid-user
</Directory>
-----------------------------------------------------------------------------
6.4. Microsoft Windows
Due to a flawed implementation of the Kerberos standard by Microsoft, there
is limited compatibility between standard MIT Kerberos and Microsoft's
version. Microsoft has published a document which describes the limited ways
in which Microsoft's broken version of Kerberos is able to interoperate with
standard Kerberos. That document is available [http://www.microsoft.com/
windows2000/techinfo/planning/security/kerbsteps.asp] here.
-----------------------------------------------------------------------------
7. Programming With Kerberos
7.1. The Kerberos API
Kerberos development libraries will allow you to Kerberos enable, or
kerberize, any application. There are two primary libraries, a general usage
Kerberos library used for basic authentication and a Kerberos administration
library used to perform administrative functions such as operations on
principals. In Fedora derived GNU/Linux, the rpm krb5-devel contains the
development libraries and documentation. An API specification for these
libraries can be found in the Kerberos documentation included with most
Kerberos distributions. In Fedora derived GNU/Linux, it installs in: /usr/
share/doc/krb5-devel-1.2.2/api
The documentation is in the LaTeX format. In order to view it you must
generate dvi filenames from it which can then be viewed with xdiv. This can
all be done with the following commands:
bash$ cd /usr/share/doc/krb5-devel-x.x.x/api/
bash$ su
bash# make
bash# (^d)
bash$ xdvi library.dvi
-----------------------------------------------------------------------------
A. Relevant Sources for More Information
A.1. Links to related documents
<EFBFBD><EFBFBD>*<2A> [http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/
install_toc.html] Kerberos V5 Installation Guide
<EFBFBD><EFBFBD>*<2A> [http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/
user-guide_toc.html] Kerberos V5 UNIX User's Guide
<EFBFBD><EFBFBD>*<2A> [http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/admin_toc.html]
Kerberos V5 System Administrator's Guide
<EFBFBD><EFBFBD>*<2A> [http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/
krb425_toc.html] Upgrading to Kerberos V5 from Kerberos V4
<EFBFBD><EFBFBD>*<2A> [http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html] Kerberos FAQ
<EFBFBD><EFBFBD>*<2A> [http://web.mit.edu/kerberos/www/dialogue.html] Designing an
Authentication System: a Dialog in Four Scenes
<EFBFBD><EFBFBD>*<2A> [http://www.ornl.gov/~jar/HowToKerb.html] How To Kerberize Your Site
<EFBFBD><EFBFBD>*<2A> [http://www.isi.edu/gost/brian/security/kerberos.html] The Moron's Guide
to Kerberos
<EFBFBD><EFBFBD>*<2A> [http://www.angelfire.com/hi/plutonic/afs-faq.html] AFS FAQ
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/docs/krb5api.html] The Kerberos 5 API
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/docs/krb5adm_api.html] The Kerberos 5 Admin
API
-----------------------------------------------------------------------------
A.2. Related web sites
<EFBFBD><EFBFBD>*<2A> [http://web.mit.edu/kerberos/www/] MIT Kerberos Website
<EFBFBD><EFBFBD>*<2A> [http://www.ntp.org/] The NTP Distribution Website
<EFBFBD><EFBFBD>*<2A> [http://www.eecis.udel.edu/~mills/ntp/clock2b.html] List of Public
Stratum 2 NTP Servers
<EFBFBD><EFBFBD>*<2A> [http://www.openafs.org/] OpenAFS Website
<EFBFBD><EFBFBD>*<2A> [http://www.pdc.kth.se/heimdal/] Heimdal Kerberos Website
<EFBFBD><EFBFBD>*<2A> [http://www.crypto-publish.org/] The Crypto Publishing Project
(Unrestricted source for Kerberos source code)
<EFBFBD><EFBFBD>*<2A> [http://www.cosic.esat.kuleuven.ac.be/sesame/] SESAME (Secure European
System for Applications in a Multi-vendor Environment)
-----------------------------------------------------------------------------
A.3. Related RFCs
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc2744.txt] RFC2744: Generic Security
Service API Version 2: C-bindings
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc2743.txt] RFC2743: Generic Security
Service Application Program Interface, Version 2 Update 1
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc2712.txt] RFC2712: Addition of
Kerberos Cipher Suites to Transport Layer Security (TLS)
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc2078.txt] RFC2078: Generic Security
Service Application Program Interface, Version 2
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1964.txt] RFC1964: The Kerberos
Version 5 GSS-API Mechanism
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1510.txt] RFC1510: The Kerberos
Network Authentication Service (V5)
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1509.txt] RFC1509: Generic Security
Service API : C-bindings
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1508.txt] RFC1508: Generic Security
Service Application Program Interface
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1411.txt] RFC1411: Telnet
Authentication: Kerberos Version 4
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1305.txt] RFC1305: Network Time
Protocol (Version 3) Specification, Implementation and Analysis
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1119.txt] RFC1119: Network Time
Protocol (Version 2) Specification and Implementation
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc1059.txt] RFC1059: Network Time
Protocol (Version 1) Specification and Implementation
<EFBFBD><EFBFBD>*<2A> [http://cryptnet.net/mirrors/rfcs/rfc958.txt] RFC958: Network Time
Protocol (NTP)
-----------------------------------------------------------------------------
A.4. Other references
<EFBFBD><EFBFBD>*<2A> [Applied Cryptography] Second Edition, Bruce Schneier [[http://
www.amazon.com/exec/obidos/tg/detail/-/0471117099/qid%3D1085516723/
sr%3D11-1/ref%3Dsr%5F11%5F1/103-3431487-6727030?v=glance] ISBN:
0-471-11709-9]
-----------------------------------------------------------------------------
A.5. Additional resources
<EFBFBD><EFBFBD>*<2A> [http://mailman.mit.edu/mailman/listinfo/kerberos] The Kerberos
Authentication System Mailing List
<EFBFBD><EFBFBD>*<2A> [http://mailman.mit.edu/pipermail/kerberos/] The Kerberos Authentication
System Mailing List Archives
<EFBFBD><EFBFBD>*<2A> [news:comp.protocols.kerberos] comp.protocols.kerberos UseNet Newsgroup
-----------------------------------------------------------------------------
A.6. Companies which provide specialist Kerberos consulting
<EFBFBD><EFBFBD>*<2A> [http://www.cybersafe.ltd.uk/] Cybersafe, Ltd.
<EFBFBD><EFBFBD>*<2A> [http://www.e-techservices.com/solutions/kerberos/] e-TechServices.com,
Inc. IBM Business Partner
Glossary of Terms
ASN.1
Abstract Syntax Notation One. ASN.1 is a notation used describe
messages. It describes them as a sequence of components. The described
components may be sequences also. ASN.1 is used to describe the internals
of Kerberos datagrams. Unless you are a software developer, you do not
need to gain an understanding of ASN.1.
Authenticator
A record containing information that can be shown to have been recently
generated using the session key known only by the client and server.
(Definition taken from [http://cryptnet.net/mirrors/rfcs/rfc1510.txt]
RFC1510)
Credentials
A ticket for the server and a session key which is used to authenticate
the principal.
Cross-Realm Authentication
Kerberos has the ability for a KDC is one realm to authenticate a
principal in another realm if a secret is shared between the KDCs of both
realms. This inter-realm authentication is called cross-realm
authentication.
Data Encryption Standard [DES]
An algorithm used for encrypted which was the official algorithm of the
United Sates Government. It was developed by IBM with assistance from the
NSA. The algorithm is a sixteen round block cipher which uses a 64bit
block and a 56bit key.
Forwardable Ticket
A ticket granted by the KDC which allows the user to request additional
tickets with different IP addresses. In effect, a TGT which allows the
authenticated principal to request tickets valid on other additional
machines.
Generic Security Services Application Programming Interface [GSS-API]
A set of C language bindings which provide security services to its
callers. The API may be implemented on top of various cryptographic
systems. Kerberos is one example of such a system.
Key Distribution Center [KDC]
The machine and software which perform the role of the trusted
arbitrator in the Kerberos protocol.
Kerberos
An authentication protocol in which a trusted third party, an
arbitrator, is relied upon to perform the authentication of clients on a
TCP/IP network. The protocol was designed in a way that encrypted tickets
are transmitted over the network rather than traditional plaintext
passwords providing for secure network authentication.
Kerberize
(v.) The act of modifying a system, service, or piece of software to
make use of the Kerberos protocol to perform authentication. (adj.
kerberized) A system, service, or piece of software which supports
authentication through Kerberos.
Network Time Protocol [NTP]
A protocol used to synchronizes clocks of hosts and routers on the
Internet.
Postdatable ticket
In Kerberos 5, a ticket which is invalid initially and which becomes
valid at some time in the future. Normal Kerberos tickets are only valid
from the time they are requested until the time that they expire.
Preauthentication
Additional authentication which takes place before a KDC grants a TGT to
a principal. An example of such authentication may be the satisfaction of
a biometrics system.
Principal
A user or server for which a secret key is stored in the KDC database.
Proxiable Ticket
In Kerberos 5, a ticket which allows you to request a TGT for
alternative IP addresses.
Realm
The scope of a Kerberos deployment. Specifically, the organization
domain for which the KDC is trusted to authenticate principals.
Renewable Ticket
In Kerberos 5, a ticket which allows the principal a maximum renewable
lifetime in addition to the standard ticket lifetime. Renewable tickets
may be used to acquire additional tickets from the KDC as long as the
ticket is valid. Renewed tickets can be requested up to the maximum
renewable lifetime of the original renewable ticket.
Salt
A seed value used in the encryption of a plaintext password to expand
the number of possible resulting ciphertexts from a given plaintext. The
use of a salt value is a defensive measure used to protect encrypted
passwords against dictionary attacks.
Stash File
A disk store of secret keys.
Ticket
A data message consiting of the client's identity, a session key, a
timestamp, and other information all encrypted with the server's secret
key. It is used to perform authentication.
Ticket Granting Service [TGS]
A service which is capable and authorized in the issuing of tickets to
clients after they have acquire a Ticket Granting Ticket (TGT).
Ticket Granting Ticket [TGT]
A ticket which contains a session key to be used in communication
between the client and the KDC.
Transitive Cross-Realm Authentication
In Kerberos 5, the ability to chain trust together between realms
building in effect a trust path so that a principal in realm X that
wishes to authenticate a principal in realm Z does not need the KDC for
realm X to share a secret with realm Z if both realm X and realm Z share
a secret with realm Y. Realm Y can be used as a "hop" in a trust path.
Triple DES
A variant of DES in which data is encrypted three times with standard
DES using two different keys.
Reference in New Issue View Git Blame Copy Permalink