ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 6. Network Authentication with Kerberos</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.auth.html" title="Part I. Authentication"><link rel="prev" href="cha.security.ad.html" title="Chapter 5. Active Directory Support"><link rel="next" href="cha.security.fp.html" title="Chapter 7. Using the Fingerprint Reader"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.auth.html">Authentication</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 5. Active Directory Support" href="cha.security.ad.html"><span>◀</span></a> <a accesskey="n" title="Chapter 7. Using the Fingerprint Reader" href="cha.security.fp.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 6. Network Authentication with Kerberos"><div class="titlepage"><div><div><h2 class="title"><a name="cha.security.kerberos"></a>Chapter 6. Network Authentication with Kerberos<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.security.kerberos">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.security.kerberos.html#sec.security.kerberos.terms">6.1. Kerberos Terminology</a></span></dt><dt><span class="sect1"><a href="cha.security.kerberos.html#sec.security.kerberos.how">6.2. How Kerberos Works</a></span></dt><dt><span class="sect1"><a href="cha.security.kerberos.html#sec.security.kerberos.users">6.3. Users' View of Kerberos</a></span></dt><dt><span class="sect1"><a href="cha.security.kerberos.html#sec.security.kerberos.admin">6.4. Installing and Administering Kerberos</a></span></dt><dt><span class="sect1"><a href="cha.security.kerberos.html#sec.security.kerberos.info">6.5. For More Information</a></span></dt></dl></div><a class="indexterm" name="idx.networks_authentication_Kerberos"></a><a class="indexterm" name="idx.Kerberos"></a><p>
An open network provides no means of ensuring that a workstation can
identify its users properly, except through the usual password mechanisms.
In common installations, the user must enter the password each time a
service inside the network is accessed. Kerberos provides an
authentication method with which a user registers once then is trusted in
the complete network for the rest of the session. To have a secure
network, the following requirements must be met:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
Have all users prove their identity for each desired service and make
sure that no one can take the identity of someone else.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Make sure that each network server also proves its identity. Otherwise
an attacker might be able to impersonate the server and obtain sensitive
information transmitted to the server. This concept is called
<span class="emphasis"><em>mutual authentication</em></span>, because the client
authenticates to the server and vice versa.
</p></li></ul></div><p>
Kerberos helps you meet these requirements by providing strongly encrypted
authentication. Only the basic principles of Kerberos are discussed here.
For detailed technical instruction, refer to the Kerberos documentation.
</p><div class="sect1" title="6.1. Kerberos Terminology"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.kerberos.terms"></a>6.1. Kerberos Terminology<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.terms">¶</a></span></h2></div></div></div><p>
The following glossary defines some Kerberos terminology.
</p><div class="variablelist"><dl><dt><span class="term">credential</span></dt><dd><p>
<a class="indexterm" name="id577579"></a> Users or clients need to present some kind of credentials
that authorize them to request services. Kerberos knows two kinds of
credentials—tickets and authenticators.
</p></dd><dt><span class="term">ticket</span></dt><dd><p>
<a class="indexterm" name="id577603"></a> A ticket is a per-server credential used by a client to
authenticate at a server from which it is requesting a service. It
contains the name of the server, the client's name, the client's
Internet address, a time stamp, a lifetime, and a random session key.
All this data is encrypted using the server's key.
</p></dd><dt><span class="term">authenticator</span></dt><dd><p>
<a class="indexterm" name="id577628"></a> Combined with the ticket, an authenticator is used to
prove that the client presenting a ticket is really the one it claims
to be. An authenticator is built using the client's name, the
workstation's IP address, and the current workstation's time, all
encrypted with the session key known only to the client and the
relevant server. An authenticator can only be used once, unlike a
ticket. A client can build an authenticator itself.
</p></dd><dt><span class="term">principal</span></dt><dd><p>
<a class="indexterm" name="id577655"></a> A Kerberos principal is a unique entity (a user or
service) to which it can assign a ticket. A principal consists of the
following components:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
<span class="bold"><strong>Primary</strong></span>—the first part of the
principal, which can be the same as your username in the case of a
user.
</p></li><li class="listitem" style="list-style-type: disc"><p>
<span class="bold"><strong>Instance</strong></span>—some optional
information characterizing the primary. This string is separated
from the primary by a <code class="literal">/</code>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
<span class="bold"><strong>Realm</strong></span>—this specifies your
Kerberos realm. Normally, your realm is your domain name in
uppercase letters.
</p></li></ul></div></dd><dt><span class="term">mutual authentication</span></dt><dd><p>
Kerberos ensures that both client and server can be sure of each
others identity. They share a session key, which they can use to
communicate securely.
</p></dd><dt><span class="term">session key</span></dt><dd><p>
<a class="indexterm" name="id577742"></a> Session keys are temporary private keys generated by
Kerberos. They are known to the client and used to encrypt the
communication between the client and the server for which it requested
and received a ticket.
</p></dd><dt><span class="term">replay</span></dt><dd><p>
Almost all messages sent in a network can be eavesdropped, stolen, and
resent. In the Kerberos context, this would be most dangerous if an
attacker manages to obtain your request for a service containing your
ticket and authenticator. The attacker could then try to resend it
(<span class="emphasis"><em>replay</em></span>) to impersonate you. However, Kerberos
implements several mechanisms to deal with this problem.
</p></dd><dt><span class="term">server or service</span></dt><dd><p>
<span class="emphasis"><em>Service</em></span> is used to refer to a specific action to
perform. The process behind this action is referred to as a
<span class="emphasis"><em>server</em></span>.
</p></dd></dl></div></div><div class="sect1" title="6.2. How Kerberos Works"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.kerberos.how"></a>6.2. How Kerberos Works<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.how">¶</a></span></h2></div></div></div><p>
Kerberos is often called a third party trusted authentication service,
which means all its clients trust Kerberos's judgment of another client's
identity. Kerberos keeps a database of all its users and their private
keys.
</p><p>
To ensure Kerberos is working correctly, run both the authentication and
ticket-granting server on a dedicated machine. Make sure that only the
administrator can access this machine physically and over the network.
Reduce the (networking) services run on it to the absolute
minimum—do not even run
<code class="systemitem">sshd</code>.
</p><div class="sect2" title="6.2.1. First Contact"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.how.contact"></a>6.2.1. First Contact<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.how.contact">¶</a></span></h3></div></div></div><p>
Your first contact with Kerberos is quite similar to any login procedure
at a normal networking system. Enter your username. This piece of
information and the name of the ticket-granting service are sent to the
authentication server (Kerberos). If the authentication server knows
you, it generates a random session key for further use between your
client and the ticket-granting server. Now the authentication server
prepares a ticket for the ticket-granting server. The ticket contains
the following information—all encrypted with a session key only
the authentication server and the ticket-granting server know:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
The names both of the client and the ticket-granting server
</p></li><li class="listitem" style="list-style-type: disc"><p>
The current time
</p></li><li class="listitem" style="list-style-type: disc"><p>
A lifetime assigned to this ticket
</p></li><li class="listitem" style="list-style-type: disc"><p>
The client's IP address
</p></li><li class="listitem" style="list-style-type: disc"><p>
The newly-generated session key
</p></li></ul></div><p>
This ticket is then sent back to the client together with the session
key, again in encrypted form, but this time the private key of the
client is used. This private key is only known to Kerberos and the
client, because it is derived from your user password. Now that the
client has received this response, you are prompted for your password.
This password is converted into the key that can decrypt the package
sent by the authentication server. The package is
<span class="quote">“<span class="quote">unwrapped</span>”</span> and password and key are erased from the
workstation's memory. As long as the lifetime given to the ticket used
to obtain other tickets does not expire, your workstation can prove your
identity.
</p></div><div class="sect2" title="6.2.2. Requesting a Service"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.how.request"></a>6.2.2. Requesting a Service<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.how.request">¶</a></span></h3></div></div></div><p>
To request a service from any server in the network, the client
application needs to prove its identity to the server. Therefore, the
application generates an authenticator. An authenticator consists of the
following components:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
The client's principal
</p></li><li class="listitem" style="list-style-type: disc"><p>
The client's IP address
</p></li><li class="listitem" style="list-style-type: disc"><p>
The current time
</p></li><li class="listitem" style="list-style-type: disc"><p>
A checksum (chosen by the client)
</p></li></ul></div><p>
All this information is encrypted using the session key that the client
has already received for this special server. The authenticator and the
ticket for the server are sent to the server. The server uses its copy
of the session key to decrypt the authenticator, which gives it all the
information needed about the client requesting its service, to compare
it to that contained in the ticket. The server checks if the ticket and
the authenticator originate from the same client.
</p><p>
Without any security measures implemented on the server side, this stage
of the process would be an ideal target for replay attacks. Someone
could try to resend a request stolen off the net some time before. To
prevent this, the server does not accept any request with a time stamp
and ticket received previously. In addition to that, a request with a
time stamp differing too much from the time the request is received is
ignored.
</p></div><div class="sect2" title="6.2.3. Mutual Authentication"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.how.mutual"></a>6.2.3. Mutual Authentication<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.how.mutual">¶</a></span></h3></div></div></div><p>
Kerberos authentication can be used in both directions. It is not only a
question of the client being the one it claims to be. The server should
also be able to authenticate itself to the client requesting its
service. Therefore, it sends an authenticator itself. It adds one to the
checksum it received in the client's authenticator and encrypts it with
the session key, which is shared between it and the client. The client
takes this response as a proof of the server's authenticity and they
both start cooperating.
</p></div><div class="sect2" title="6.2.4. Ticket Granting—Contacting All Servers"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.how.tgs"></a>6.2.4. Ticket Granting—Contacting All Servers<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.how.tgs">¶</a></span></h3></div></div></div><p>
<a class="indexterm" name="id577979"></a> <a class="indexterm" name="id577989"></a> Tickets are designed to be used for one server at a time.
This implies that you have to get a new ticket each time you request
another service. Kerberos implements a mechanism to obtain tickets for
individual servers. This service is called the <span class="quote">“<span class="quote">ticket-granting
service</span>”</span>. The ticket-granting service is a service (like any
other service mentioned before) and uses the same access protocols that
have already been outlined. Any time an application needs a ticket that
has not already been requested, it contacts the ticket-granting server.
This request consists of the following components:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
The requested principal
</p></li><li class="listitem" style="list-style-type: disc"><p>
The ticket-granting ticket
</p></li><li class="listitem" style="list-style-type: disc"><p>
An authenticator
</p></li></ul></div><p>
Like any other server, the ticket-granting server now checks the
ticket-granting ticket and the authenticator. If they are considered
valid, the ticket-granting server builds a new session key to be used
between the original client and the new server. Then the ticket for the
new server is built, containing the following information:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
The client's principal
</p></li><li class="listitem" style="list-style-type: disc"><p>
The server's principal
</p></li><li class="listitem" style="list-style-type: disc"><p>
The current time
</p></li><li class="listitem" style="list-style-type: disc"><p>
The client's IP address
</p></li><li class="listitem" style="list-style-type: disc"><p>
The newly-generated session key
</p></li></ul></div><p>
The new ticket is assigned a lifetime, which is the lesser of the
remaining lifetime of the ticket-granting ticket and the default for the
service. The client receives this ticket and the session key, which are
sent by the ticket-granting service, but this time the answer is
encrypted with the session key that came with the original
ticket-granting ticket. The client can decrypt the response without
requiring the user's password when a new service is contacted. Kerberos
can thus acquire ticket after ticket for the client without bothering
the user more than once at login time.
</p></div><div class="sect2" title="6.2.5. Compatibility to Windows 2000"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.how.win"></a>6.2.5. Compatibility to Windows 2000<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.how.win">¶</a></span></h3></div></div></div><p>
Windows 2000 contains a Microsoft implementation of Kerberos 5. Because
openSUSE® uses the MIT implementation of Kerberos 5, find useful
information and guidance in the MIT documentation. See
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.info" title="6.5. For More Information">Section 6.5, “For More Information”</a>.
</p></div></div><div class="sect1" title="6.3. Users' View of Kerberos"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.kerberos.users"></a>6.3. Users' View of Kerberos<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.users">¶</a></span></h2></div></div></div><p>
Ideally, a user's one and only contact with Kerberos happens during login
at the workstation. The login process includes obtaining a
ticket-granting ticket. At logout, a user's Kerberos tickets are
automatically destroyed, which makes it difficult for anyone else to
impersonate this user. The automatic expiration of tickets can lead to a
somewhat awkward situation when a user's login session lasts longer than
the maximum lifespan given to the ticket-granting ticket (a reasonable
setting is 10 hours). However, the user can get a new ticket-granting
ticket by running <span class="command"><strong>kinit</strong></span>. Enter the password again and
Kerberos obtains access to desired services without additional
authentication. To get a list of all the tickets silently acquired for
you by Kerberos, run <span class="command"><strong>klist</strong></span>.
</p><p>
Here is a short list of some applications that use Kerberos
authentication. These applications can be found under
<code class="filename">/usr/lib/mit/bin</code> or
<code class="filename">/usr/lib/mit/sbin</code> after installing the package
<code class="systemitem">krb5-apps-clients</code>. They all have the full
functionality of their common UNIX and Linux brothers plus the additional
bonus of transparent authentication managed by Kerberos:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
telnet, telnetd
</p></li><li class="listitem" style="list-style-type: disc"><p>
rlogin
</p></li><li class="listitem" style="list-style-type: disc"><p>
rsh, rcp, rshd
</p></li><li class="listitem" style="list-style-type: disc"><p>
ftp, ftpd
</p></li><li class="listitem" style="list-style-type: disc"><p>
ksu
</p></li></ul></div><p>
You no longer have to enter your password for using these applications
because Kerberos has already proven your identity. ssh, if compiled with
Kerberos support, can even forward all the tickets acquired for one
workstation to another one. If you use ssh to log in to another
workstation, ssh makes sure that the encrypted contents of the tickets
are adjusted to the new situation. Simply copying tickets between
workstations is not sufficient because the ticket contains
workstation-specific information (the IP address). XDM, GDM, and KDM
offer Kerberos support, too. Read more about the Kerberos network
applications in <span class="emphasis"><em>Kerberos V5 UNIX User's Guide</em></span> at
<a class="ulink" href="http://web.mit.edu/kerberos" target="_top">http://web.mit.edu/kerberos</a>.
</p></div><div class="sect1" title="6.4. Installing and Administering Kerberos"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.kerberos.admin"></a>6.4. Installing and Administering Kerberos<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin">¶</a></span></h2></div></div></div><a class="indexterm" name="idx.Kerberos_installing"></a><a class="indexterm" name="idx.Kerberos_administering"></a><p>
A Kerberos environment consists of several different components. A key
distribution center (KDC) holds the central database with all
Kerberos-relevant data. All clients rely on the KDC for proper
authentication across the network. Both the KDC and the clients need to
be configured to match your setup:
</p><div class="variablelist"><dl><dt><span class="term">General Preparations</span></dt><dd><p>
Check your network setup and make sure it meets the minimum
requirements outlined in
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.top" title="6.4.1. Kerberos Network Topology">Section 6.4.1, “Kerberos Network Topology”</a>. Choose an
appropriate realm for your Kerberos setup, see
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.realm" title="6.4.2. Choosing the Kerberos Realms">Section 6.4.2, “Choosing the Kerberos Realms”</a>. Carefully set up
the machine that is to serve as the KDC and apply tight security, see
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.kdc" title="6.4.3. Setting Up the KDC Hardware">Section 6.4.3, “Setting Up the KDC Hardware”</a>. Set up a reliable
time source in your network to make sure all tickets contain valid
timestamps, see <a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.time" title="6.4.4. Configuring Time Synchronization">Section 6.4.4, “Configuring Time Synchronization”</a>.
</p></dd><dt><span class="term">Basic Configuration</span></dt><dd><p>
Configure the KDC and the clients, see
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.instkdc" title="6.4.5. Configuring the KDC">Section 6.4.5, “Configuring the KDC”</a> and
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.client" title="6.4.6. Configuring Kerberos Clients">Section 6.4.6, “Configuring Kerberos Clients”</a>. Enable remote
administration for your Kerberos service, so you do not need physical
access to your KDC machine, see
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.remote" title="6.4.7. Configuring Remote Kerberos Administration">Section 6.4.7, “Configuring Remote Kerberos Administration”</a>. Create service
principals for every service in your realm, see
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.hostprinc" title="6.4.8. Creating Kerberos Service Principals">Section 6.4.8, “Creating Kerberos Service Principals”</a>.
</p></dd><dt><span class="term">Enabling Kerberos Authentication</span></dt><dd><p>
Various services in your network can make use of Kerberos. To add
Kerberos password-checking to applications using PAM, proceed as
outlined in <a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.pam" title="6.4.9. Enabling PAM Support for Kerberos">Section 6.4.9, “Enabling PAM Support for Kerberos”</a>. To
configure SSH or LDAP with Kerberos authentication, proceed as
outlined in <a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.sshd" title="6.4.10. Configuring SSH for Kerberos Authentication">Section 6.4.10, “Configuring SSH for Kerberos Authentication”</a> and
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.ldap" title="6.4.11. Using LDAP and Kerberos">Section 6.4.11, “Using LDAP and Kerberos”</a>.
</p></dd></dl></div><div class="sect2" title="6.4.1. Kerberos Network Topology"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.top"></a>6.4.1. Kerberos Network Topology<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.top">¶</a></span></h3></div></div></div><p>
Any Kerberos environment must meet the following requirements to be
fully functional:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
Provide a DNS server for name resolution across your network, so
clients and servers can locate each other. Refer to
Chapter <i>The Domain Name System</i> (↑Reference) for information on DNS setup.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Provide a time server in your network. Using exact time stamps is
crucial to a Kerberos setup, because valid Kerberos tickets must
contain correct time stamps. Refer to Chapter <i>Time Synchronization with NTP</i> (↑Reference)
for information on NTP setup.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Provide a key distribution center (KDC) as the center piece of the
Kerberos architecture. It holds the Kerberos database. Use the
tightest possible security policy on this machine to prevent any
attacks on this machine compromising your entire infrastructure.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Configure the client machines to use Kerberos authentication.
</p></li></ul></div><p>
The following figure depicts a simple example network with just the
minimum components needed to build a Kerberos infrastructure. Depending
on the size and topology of your deployment, your setup may vary.
</p><div class="figure"><a name="fig.netw.kerb"></a><p class="title"><b>Figure 6.1. Kerberos Network Topology</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.netw.kerb">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="100%"><tr><td><img src="images/network_kerb.png" width="100%" alt="Kerberos Network Topology"></td></tr></table></div></div></div><br class="figure-break"><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Configuring Subnet Routing"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Configuring Subnet Routing</th></tr><tr><td colspan="2" align="left" valign="top"><p>
For a setup similar to the one in <a class="xref" href="cha.security.kerberos.html#fig.netw.kerb" title="Figure 6.1. Kerberos Network Topology">Figure 6.1, “Kerberos Network Topology”</a>,
configure routing between the two subnets (192.168.1.0/24 and
192.168.2.0/24). Refer to
Section “Configuring Routing” (Chapter 21, <i>Basic Networking</i>, ↑Reference) for more information
on configuring routing with YaST.
</p></td></tr></table></div></div><div class="sect2" title="6.4.2. Choosing the Kerberos Realms"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.realm"></a>6.4.2. Choosing the Kerberos Realms<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.realm">¶</a></span></h3></div></div></div><a class="indexterm" name="id578469"></a><p>
The domain of a Kerberos installation is called a realm and is
identified by a name, such as <code class="literal">EXAMPLE.COM</code> or simply
<code class="literal">ACCOUNTING</code>. Kerberos is case-sensitive, so
<code class="literal">example.com</code> is actually a different realm than
<code class="literal">EXAMPLE.COM</code>. Use the case you prefer. It is common
practice, however, to use uppercase realm names.
</p><p>
It is also a good idea to use your DNS domain name (or a subdomain, such
as <code class="literal">ACCOUNTING.EXAMPLE.COM</code>). As shown below, your life
as an administrator can be much easier if you configure your Kerberos
clients to locate the KDC and other Kerberos services via DNS. To do so,
it is helpful if your realm name is a subdomain of your DNS domain name.
</p><p>
Unlike the DNS name space, Kerberos is not hierarchical. You cannot set
up a realm named <code class="literal">EXAMPLE.COM</code>, have two
<span class="quote">“<span class="quote">subrealms</span>”</span> named <code class="literal">DEVELOPMENT</code> and
<code class="literal">ACCOUNTING</code> underneath it, and expect the two
subordinate realms to somehow inherit principals from
<code class="literal">EXAMPLE.COM</code>. Instead, you would have three separate
realms for which you would have to configure crossrealm authentication
for users from one realm to interact with servers or other users from
another realm.
</p><p>
For the sake of simplicity, assume you are setting up just one realm for
your entire organization. For the remainder of this section, the realm
name <code class="literal">EXAMPLE.COM</code> is used in all examples.
</p></div><div class="sect2" title="6.4.3. Setting Up the KDC Hardware"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.kdc"></a>6.4.3. Setting Up the KDC Hardware<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.kdc">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.Kerberos_KDC"></a><p>
The first thing required to use Kerberos is a machine that acts as the
key distribution center, or KDC for short. This machine holds the entire
Kerberos user database with passwords and all information.
</p><p>
The KDC is the most important part of your security
infrastructure—if someone breaks into it, all user accounts and
all of your infrastructure protected by Kerberos is compromised. An
attacker with access to the Kerberos database can impersonate any
principal in the database. Tighten security for this machine as much as
possible:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Put the server machine into a physically secured location, such as a
locked server room to which only a very few people have access.
</p></li><li><p>
Do not run any network applications on it except the KDC. This
includes servers and clients—for example, the KDC should not
import any file systems via NFS or use DHCP to retrieve its network
configuration.
</p></li><li><p>
Install a minimal system first then check the list of installed
packages and remove any unneeded packages. This includes servers, such
as inetd, portmap, and cups, as well as anything X-based. Even
installing an SSH server should be considered a potential security
risk.
</p></li><li><p>
No graphical login is provided on this machine as an X server is a
potential security risk. Kerberos provides its own administration
interface.
</p></li><li><p>
<a class="indexterm" name="id578616"></a> Configure <code class="filename">/etc/nsswitch.conf</code> to use
only local files for user and group lookup. Change the lines for
<code class="literal">passwd</code> and <code class="literal">group</code> to look like
this:
</p><pre class="screen">passwd: files
group: files</pre><p>
Edit the <code class="filename">passwd</code>, <code class="filename">group</code>, and
<code class="filename">shadow</code> files in <code class="filename">/etc</code> and
remove the lines that start with a <code class="literal">+</code> character
(these are for NIS lookups).
</p></li><li><p>
Disable all user accounts except <code class="systemitem">root</code>'s account by editing
<code class="filename">/etc/shadow</code> and replacing the hashed passwords
with <code class="literal">*</code> or <code class="literal">!</code> characters.
</p></li></ol></div><a class="indexterm" name="id578686"></a></div><div class="sect2" title="6.4.4. Configuring Time Synchronization"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.time"></a>6.4.4. Configuring Time Synchronization<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.time">¶</a></span></h3></div></div></div><a class="indexterm" name="id578700"></a><p>
To use Kerberos successfully, make sure that all system clocks within
your organization are synchronized within a certain range. This is
important because Kerberos protects against replayed credentials. An
attacker might be able to observe Kerberos credentials on the network
and reuse them to attack the server. Kerberos employs several defenses
to prevent this. One of them is that it puts time stamps into its
tickets. A server receiving a ticket with a time stamp that differs from
the current time rejects the ticket.
</p><p>
Kerberos allows a certain leeway when comparing time stamps. However,
computer clocks can be very inaccurate in keeping time—it is not
unheard of for PC clocks to lose or gain half an hour over the course of
a week. For this reason, configure all hosts on the network to
synchronize their clocks with a central time source.
</p><p>
A simple way to do so is by installing an NTP time server on one machine
and having all clients synchronize their clocks with this server. Do
this either by running an NTP daemon in client mode on all these
machines or by running <span class="command"><strong>ntpdate</strong></span> once a day from all
clients (this solution probably works for a small number of clients
only). The KDC itself needs to be synchronized to the common time source
as well. Because running an NTP daemon on this machine would be a
security risk, it is probably a good idea to do this by running ntpdate
via a cron entry. To configure your machine as an NTP client, proceed as
outlined in Section “Configuring an NTP Client with YaST” (Chapter 25, <i>Time Synchronization with NTP</i>, ↑Reference).
</p><p>
A different way to secure the time service and still use the NTP daemon
is to attach a hardware reference clock to a dedicated NTP server as
well as an additional hardware reference clock to the KDC.
</p><p>
It is also possible to adjust the maximum deviation Kerberos allows when
checking time stamps. This value (called <span class="emphasis"><em>clock
skew</em></span>) can be set in the <code class="filename">krb5.conf</code> file
as described in
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.client.clockskew" title="6.4.6.2.3. Adjusting the Clock Skew">Section 6.4.6.2.3, “Adjusting the Clock Skew”</a>.
</p></div><div class="sect2" title="6.4.5. Configuring the KDC"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.instkdc"></a>6.4.5. Configuring the KDC<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.instkdc">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.Kerberos_inst_KDC"></a><p>
This section covers the initial configuration and installation of the
KDC, including the creation of an administrative principal. This
procedure is consists of several steps:
</p><div class="procedure"><ol class="procedure" type="1"><li><p title="Install the RPMs"><b>Install the RPMs. </b>
On a machine designated as the KDC, install special software
packages. Use YaST to install the
<code class="systemitem">krb5</code>,
<code class="systemitem">krb5-server</code> and
<code class="systemitem">krb5-client</code>
packages.
</p></li><li><p title="Adjust the Configuration Files"><b>Adjust the Configuration Files. </b>
The <code class="filename">/etc/krb5.conf</code> and
<code class="filename">/var/lib/kerberos/krb5kdc/kdc.conf</code> configuration
files must be adjusted for your scenario. These files contain all
information on the KDC.
</p></li><li><p title="Create the Kerberos Database"><b>Create the Kerberos Database. </b>
Kerberos keeps a database of all principal identifiers and the secret
keys of all principals that need to be authenticated. Refer to
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.kdc.database" title="6.4.5.1. Setting Up the Database">Section 6.4.5.1, “Setting Up the Database”</a> for
details.
</p></li><li><p title="Adjust the ACL Files: Add Administrators"><b>Adjust the ACL Files: Add Administrators. </b>
The Kerberos database on the KDC can be managed remotely. To prevent
unauthorized principals from tampering with the database, Kerberos
uses access control lists. You must explicitly enable remote access
for the administrator principal to enable him to manage the database.
The Kerberos ACL file is located under
<code class="filename">/var/lib/kerberos/krb5kdc/kadm5.acl</code>. Refer to
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.remote" title="6.4.7. Configuring Remote Kerberos Administration">Section 6.4.7, “Configuring Remote Kerberos Administration”</a> for details.
</p></li><li><p title="Adjust the Kerberos Database: Add Administrators"><b>Adjust the Kerberos Database: Add Administrators. </b>
You need at least one administrative principal to run and administer
Kerberos. This principal must be added before starting the KDC. Refer
to <a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.kdc.princ" title="6.4.5.2. Creating a Principal">Section 6.4.5.2, “Creating a Principal”</a> for
details.
</p></li><li><p title="Start the Kerberos Daemon"><b>Start the Kerberos Daemon. </b>
Once the KDC software is installed and properly configured, start the
Kerberos daemon to provide Kerberos service for your realm. Refer to
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.kdc.start" title="6.4.5.3. Starting the KDC">Section 6.4.5.3, “Starting the KDC”</a> for details.
</p></li><li><p title="Create a Principal for Yourself"><b>Create a Principal for Yourself. </b>
You need a principal for yourself. Refer to
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.admin.kdc.princ" title="6.4.5.2. Creating a Principal">Section 6.4.5.2, “Creating a Principal”</a> for details.
</p></li></ol></div><div class="sect3" title="6.4.5.1. Setting Up the Database"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.kdc.database"></a>6.4.5.1. Setting Up the Database<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.kdc.database">¶</a></span></h4></div></div></div><a class="indexterm" name="id578952"></a><a class="indexterm" name="id578960"></a><p>
Your next step is to initialize the database where Kerberos keeps all
information about principals. Set up the database master key, which is
used to protect the database from accidental disclosure (in particular
when it is backed up to tape). The master key is derived from a pass
phrase and is stored in a file called the stash file. This is so you do
not need to enter the password every time the KDC is restarted. Make
sure that you choose a good pass phrase, such as a sentence from a book
opened to a random page.
</p><p>
When you make tape backups of the Kerberos database
(<code class="filename">/var/lib/kerberos/krb5kdc/principal</code>), do not back
up the stash file (which is in
<code class="filename">/var/lib/kerberos/krb5kdc/.k5.EXAMPLE.COM</code>).
Otherwise, everyone able to read the tape could also decrypt the
database. Therefore, keep a copy of the pass phrase in a safe or some
other secure location, because you will need it to restore your
database from backup tape after a crash.
</p><a class="indexterm" name="id578987"></a><p>
To create the stash file and the database, run:
</p><pre class="screen">kdb5_util create -r EXAMPLE.COM -s</pre><p>
You will see the following output:
</p><pre class="screen">Initializing database '/var/lib/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: <a name="co.kerb.kdb5.pass"></a><img src="callouts/1.png" alt="1" border="0">
Re-enter KDC database master key to verify: <a name="co.kerb.kdb5.pass.repeat"></a><img src="callouts/2.png" alt="2" border="0">
</pre><a class="indexterm" name="id579021"></a><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.kerb.kdb5.pass"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
Type the master password.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.kerb.kdb5.pass.repeat"><img src="callouts/2.png" alt="2" border="0"></a> </p></td><td valign="top" align="left"><p>
Type password again.
</p></td></tr></table></div><p>
To verify, use the list command:
</p><pre class="screen">kadmin.local
kadmin> listprincs</pre><p>
You will see several principals in the database, which are for internal
use by Kerberos:
</p><pre class="screen">K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM</pre></div><div class="sect3" title="6.4.5.2. Creating a Principal"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.kdc.princ"></a>6.4.5.2. Creating a Principal<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.kdc.princ">¶</a></span></h4></div></div></div><a class="indexterm" name="id579072"></a><p>
Create two Kerberos principals for yourself: one normal principal for
everyday work and one for administrative tasks relating to Kerberos.
Assuming your login name is <code class="literal">geeko</code>, proceed as
follows:
</p><pre class="screen">kadmin.local
kadmin> ank geeko
</pre><p>
You will see the following output:
</p><pre class="screen">geeko@EXAMPLE.COM's Password: <a name="co.kerb.geeko.pass"></a><img src="callouts/1.png" alt="1" border="0">
Verifying password: <a name="co.kerb.geeko.pass.repeat"></a><img src="callouts/2.png" alt="2" border="0">
</pre><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.kerb.geeko.pass"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
Type geeko's password.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.kerb.geeko.pass"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
Type geeko's password again.
</p></td></tr></table></div><p>
Next, create another principal named <code class="literal">geeko/admin</code> by
typing <span class="command"><strong>ank <code class="option">geeko/admin</code></strong></span> at the
<span class="command"><strong>kadmin</strong></span> prompt. The <code class="literal">admin</code> suffixed
to your username is a <span class="emphasis"><em>role</em></span>. Later, use this role
when administering the Kerberos database. A user can have several roles
for different purposes. Roles are basically completely different
accounts with similar names.
</p></div><div class="sect3" title="6.4.5.3. Starting the KDC"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.kdc.start"></a>6.4.5.3. Starting the KDC<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.kdc.start">¶</a></span></h4></div></div></div><a class="indexterm" name="id579160"></a><p>
Start the KDC daemon and the kadmin daemon. To start the daemons
manually, enter <span class="command"><strong>rckrb5kdc start</strong></span> and
<span class="command"><strong>rckadmind start</strong></span>. Also make sure that KDC and kadmind
are started by default when the server machine is rebooted with the
command <span class="command"><strong>insserv</strong></span> <code class="option">krb5kdc</code> and
<span class="command"><strong>insserv</strong></span> <code class="option">kadmind</code> or use the
YaST runlevel editor.
</p><a class="indexterm" name="id579195"></a></div></div><div class="sect2" title="6.4.6. Configuring Kerberos Clients"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.client"></a>6.4.6. Configuring Kerberos Clients<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.client">¶</a></span></h3></div></div></div><p>
Once the supporting infrastructure is in place (DNS, NTP) and the KDC
has been properly configured and started, configure the client machines.
You can either use YaST to configure a Kerberos client or use one of
the two manual approaches described below.
</p><div class="sect3" title="6.4.6.1. Configuring a Kerberos Client with YaST"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.client.yast"></a>6.4.6.1. Configuring a Kerberos Client with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.client.yast">¶</a></span></h4></div></div></div><p>
Rather than manually editing all relevant configuration files when
configuring a Kerberos client, let YaST do the job for you. You can
either perform the client configuration during the installation of your
machine or in the installed system:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Log in as <code class="systemitem">root</code> and select <span class="guimenu">Network
Services</span>+<span class="guimenu">Kerberos Client</span>.
</p></li><li><p>
Select <span class="guimenu">Use Kerberos</span>.
</p></li><li><p>
To configure a DNS-based Kerberos client, proceed as follows:
</p><ol type="a" class="substeps"><li><p>
Enable <span class="guimenu">Use DNS to acquire the configuration data at
runtime</span> and confirm the <span class="guimenu">Basic Kerberos
Settings</span> that are displayed.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: Using DNS Support"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">Using DNS Support</th></tr><tr><td colspan="2" align="left" valign="top"><p>
The <span class="guimenu">Use DNS</span> option cannot be selected if the
DNS server does not provide such data.
</p></td></tr></table></div></li><li><p>
Click <span class="guimenu">Advanced Settings</span> to configure details on
ticket-related issues, OpenSSH support, time synchronization, and
extended PAM configurations.
</p></li></ol></li><li><p>
To configure a static Kerberos client, proceed as follows:
</p><ol type="a" class="substeps"><li><p>
Set <span class="guimenu">Default Domain</span>, <span class="guimenu">Default
Realm</span>, and <span class="guimenu">KDC Server Address</span> to the
values that match your setup.
</p></li><li><p>
Click <span class="guimenu">Advanced Settings</span> to configure details on
ticket-related issues, OpenSSH support, time synchronization, and
extended PAM configurations.
</p></li></ol></li></ol></div><div class="figure"><a name="id579367"></a><p class="title"><b>Figure 6.2. YaST: Basic Configuration of a Kerberos Client</b></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/kerb_y2_basic.png" width="100%" alt="YaST: Basic Configuration of a Kerberos Client"></td></tr></table></div></div></div><br class="figure-break"><p>
To configure ticket-related options in the <span class="guimenu">Advanced
Settings</span> dialog, choose from the following options:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
Specify the <span class="guimenu">Default Ticket Lifetime</span> and the
<span class="guimenu">Default Renewable Lifetime</span> in days, hours, or
minutes (using the units of measurement <span class="emphasis"><em>d</em></span>,
<span class="emphasis"><em>h</em></span>, and <span class="emphasis"><em>m</em></span>, with no blank
space between the value and the unit).
</p></li><li class="listitem" style="list-style-type: disc"><p>
To forward your complete identity (to use your tickets on other
hosts), select <span class="guimenu">Forwardable</span>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Enable the transfer of certain tickets by selecting
<span class="guimenu">Proxiable</span>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Enable Kerberos authentication support for your OpenSSH client by
selecting the corresponding check box. The client then uses Kerberos
tickets to authenticate with the SSH server.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Exclude a range of user accounts from using Kerberos authentication
by providing a value for the <span class="guimenu">Minimum UID</span> that a
user of this feature must have. For instance, you may want to exclude
the system administrator
(<code class="systemitem">root</code>).
</p></li><li class="listitem" style="list-style-type: disc"><p>
Use <span class="guimenu">Clock Skew</span> to set a value for the allowable
difference between the time stamps and your host's system time.
</p></li><li class="listitem" style="list-style-type: disc"><p>
To keep the system time in sync with an NTP server, you can also set
up the host as an NTP client by selecting <span class="guimenu">NTP
Configuration</span>, which opens the YaST NTP client dialog
that is described in Section “Configuring an NTP Client with YaST” (Chapter 25, <i>Time Synchronization with NTP</i>, ↑Reference). After
finishing the configuration, YaST performs all the necessary
changes and the Kerberos client is ready for use.
</p></li></ul></div><div class="figure"><a name="id579512"></a><p class="title"><b>Figure 6.3. YaST: Advanced Configuration of a Kerberos Client</b></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/kerb_y2_advanced.png" width="100%" alt="YaST: Advanced Configuration of a Kerberos Client"></td></tr></table></div></div></div><br class="figure-break"><p>
For more information about the configuration of <span class="guimenu">Expert PAM
Settings</span> and <span class="guimenu">PAM Services</span> tabs, see the
official documentation referenced in
<a class="xref" href="cha.security.kerberos.html#sec.security.kerberos.info" title="6.5. For More Information">Section 6.5, “For More Information”</a> and the manual page
<span class="command"><strong>man 5 krb5.conf</strong></span>.
</p></div><div class="sect3" title="6.4.6.2. Manually Configuring Kerberos Clients"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.client.man"></a>6.4.6.2. Manually Configuring Kerberos Clients<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.client.man">¶</a></span></h4></div></div></div><a class="indexterm" name="idx.Kerberos_clients_configuring"></a><a class="indexterm" name="idx.Kerberos_configuring_clients"></a><p>
When configuring Kerberos, there are basically two approaches you can
take—static configuration in the
<code class="filename">/etc/krb5.conf</code> file or dynamic configuration with
DNS. With DNS configuration, Kerberos applications try to locate the
KDC services using DNS records. With static configuration, add the
hostnames of your KDC server to <code class="filename">krb5.conf</code> (and
update the file whenever you move the KDC or reconfigure your realm in
other ways).
</p><a class="indexterm" name="id579615"></a><p>
DNS-based configuration is generally a lot more flexible and the amount
of configuration work per machine is a lot less. However, it requires
that your realm name is either the same as your DNS domain or a
subdomain of it. Configuring Kerberos via DNS also creates a minor
security issue—an attacker can seriously disrupt your
infrastructure through your DNS (by shooting down the name server,
spoofing DNS records, etc.). However, this amounts to a denial of
service at worst. A similar scenario applies to the static
configuration case unless you enter IP addresses in
<code class="filename">krb5.conf</code> instead of hostnames.
</p><div class="sect4" title="6.4.6.2.1. Static Configuration"><div class="titlepage"><div><div><h5 class="title"><a name="sec.security.kerberos.admin.client.stat"></a>6.4.6.2.1. Static Configuration<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.client.stat">¶</a></span></h5></div></div></div><a class="indexterm" name="id579644"></a><p>
One way to configure Kerberos is to edit
<code class="filename">/etc/krb5.conf</code>. The file installed by default
contains various sample entries. Erase all of these entries before
starting. <code class="filename">krb5.conf</code> is made up of several
sections (stanzas), each introduced by the section name included in
brackets like <code class="literal">[this]</code>.
</p><p>
To configure your Kerberos clients, add the following stanza to
<code class="filename">krb5.conf</code> (where
<code class="systemitem">kdc.example.com</code> is the
hostname of the KDC):
</p><pre class="screen">[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
}</pre><p>
The <code class="literal">default_realm</code> line sets the default realm for
Kerberos applications. If you have several realms, just add additional
statements to the <code class="literal">[realms]</code> section.
</p><p>
Also add a statement to this file that tells applications how to map
hostnames to a realm. For example, when connecting to a remote host,
the Kerberos library needs to know in which realm this host is
located. This must be configured in the
<code class="literal">[domain_realms]</code> section:
</p><pre class="screen">[domain_realm]
.example.com = EXAMPLE.COM
www.foobar.com = EXAMPLE.COM</pre><p>
This tells the library that all hosts in the
<code class="filename">example.com</code> DNS domains are in the
<code class="filename">EXAMPLE.COM</code> Kerberos realm. In addition, one
external host named <code class="filename">www.foobar.com</code> should also be
considered a member of the <code class="filename">EXAMPLE.COM</code> realm.
</p></div><div class="sect4" title="6.4.6.2.2. DNS-Based Configuration"><div class="titlepage"><div><div><h5 class="title"><a name="sec.security.kerberos.admin.client.dns"></a>6.4.6.2.2. DNS-Based Configuration<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.client.dns">¶</a></span></h5></div></div></div><p>
DNS-based Kerberos configuration makes heavy use of SRV records. See
<span class="emphasis"><em>(RFC2052) A DNS RR for specifying the location of
services</em></span> at <a class="ulink" href="http://www.ietf.org" target="_top"> http://www.ietf.org</a>.
</p><p>
The name of an SRV record, as far as Kerberos is concerned, is always
in the format <code class="literal">_service._proto.realm</code>, where realm is
the Kerberos realm. Domain names in DNS are case insensitive, so
case-sensitive Kerberos realms would break when using this
configuration method. <code class="literal">_service</code> is a service name
(different names are used when trying to contact the KDC or the
password service, for example). <code class="literal">_proto</code> can be
either <code class="literal">_udp</code> or <code class="literal">_tcp</code>, but not all
services support both protocols.
</p><p>
The data portion of SRV resource records consists of a priority value,
a weight, a port number, and a hostname. The priority defines the
order in which hosts should be tried (lower values indicate a higher
priority). The weight value is there to support some sort of load
balancing among servers of equal priority. You probably do not need
any of this, so it is okay to set these to zero.
</p><p>
MIT Kerberos currently looks up the following names when looking for
services:
</p><div class="variablelist"><dl><dt><span class="term">_kerberos</span></dt><dd><p>
This defines the location of the KDC daemon (the authentication and
ticket granting server). Typical records look like this:
</p><pre class="screen">_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com.</pre></dd><dt><span class="term">_kerberos-adm</span></dt><dd><p>
This describes the location of the remote administration service.
Typical records look like this:
</p><pre class="screen">
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 0 0 749 kdc.example.com.</pre><p>
Because kadmind does not support UDP, there should be no
<code class="literal">_udp</code> record.
</p></dd></dl></div><p>
As with the static configuration file, there is a mechanism to inform
clients that a specific host is in the <code class="literal">EXAMPLE.COM</code>
realm, even if it is not part of the <code class="literal">example.com</code>
DNS domain. This can be done by attaching a TXT record to
<code class="literal">_kerberos.hostname</code>, as shown here:
</p><pre class="screen">_kerberos.www.foobar.com. IN TXT "EXAMPLE.COM"</pre><a class="indexterm" name="id579837"></a><a class="indexterm" name="id579842"></a></div><div class="sect4" title="6.4.6.2.3. Adjusting the Clock Skew"><div class="titlepage"><div><div><h5 class="title"><a name="sec.security.kerberos.admin.client.clockskew"></a>6.4.6.2.3. Adjusting the Clock Skew<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.client.clockskew">¶</a></span></h5></div></div></div><a class="indexterm" name="id579856"></a><p>
The <span class="emphasis"><em>clock skew</em></span> is the tolerance for accepting
tickets with time stamps that do not exactly match the host's system
clock. Usually, the clock skew is set to 300 seconds (five minutes).
This means a ticket can have a time stamp somewhere between five
minutes behind and five minutes ahead of the server's clock.
</p><p>
When using NTP to synchronize all hosts, you can reduce this value to
about one minute. The clock skew value can be set in
<code class="filename">/etc/krb5.conf</code> like this:
</p><a class="indexterm" name="id579880"></a><pre class="screen">[libdefaults]
clockskew = 120</pre></div></div></div><div class="sect2" title="6.4.7. Configuring Remote Kerberos Administration"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.remote"></a>6.4.7. Configuring Remote Kerberos Administration<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.remote">¶</a></span></h3></div></div></div><a class="indexterm" name="id579902"></a><p>
To be able to add and remove principals from the Kerberos database
without accessing the KDC's console directly, tell the Kerberos
administration server which principals are allowed to do what by editing
<code class="filename">/var/lib/kerberos/krb5kdc/kadm5.acl</code>. The ACL
(access control list) file allows you to specify privileges with a
precise degree of control. For details, refer to the manual page with
<span class="command"><strong>man <code class="option">8 kadmind</code></strong></span>.
</p><p>
For now, just grant yourself the privilege to administer the database by
putting the following line into the file:
</p><pre class="screen">geeko/admin *</pre><p>
Replace the username <code class="literal">geeko</code> with your own. Restart
kadmind for the change to take effect.
</p><p>
You should now be able to perform Kerberos administration tasks remotely
using the kadmin tool. First, obtain a ticket for your admin role and
use that ticket when connecting to the kadmin server:
</p><pre class="screen">kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:</pre><a class="indexterm" name="id579951"></a><p>
Using the <span class="command"><strong>getprivs</strong></span> command, verify which privileges
you have. The list shown above is the full set of privileges.
</p><p>
As an example, modify the principal <code class="literal">geeko</code>:
</p><pre class="screen">kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin: modify_principal -maxlife "8 hours" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin: getprinc joe
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:</pre><p>
This changes the maximum ticket life time to eight hours. For more
information about the <span class="command"><strong>kadmin</strong></span> command and the options
available, see the <code class="systemitem">krb5-doc</code> package, refer to
<a class="ulink" href="http://web.mit.edu/kerberos/www/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#Kadmin%20Options" target="_top">http://web.mit.edu/kerberos/www/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#Kadmin%20Options</a>
or the <span class="command"><strong>man<code class="option">8 kadmin</code></strong></span> manual page.
</p></div><div class="sect2" title="6.4.8. Creating Kerberos Service Principals"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.hostprinc"></a>6.4.8. Creating Kerberos Service Principals<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.hostprinc">¶</a></span></h3></div></div></div><a class="indexterm" name="id580016"></a><a class="indexterm" name="id580027"></a><p>
So far, only user credentials have been discussed. However,
Kerberos-compatible services usually need to authenticate themselves to
the client user, too. Therefore, special service principals must be
present in the Kerberos database for each service offered in the realm.
For example, if ldap.example.com offers an LDAP service, you need a service
principal, <code class="literal">ldap/ldap.example.com@EXAMPLE.COM</code>, to
authenticate this service to all clients.
</p><p>
The naming convention for service principals is
<code class="literal"><em class="replaceable"><code>service</code></em>/<em class="replaceable"><code>hostname</code></em>@<em class="replaceable"><code>REALM</code></em></code>,
where <em class="replaceable"><code>hostname</code></em> is the host's fully qualified
hostname.
</p><p>
Valid service descriptors are:
</p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Service Descriptor
</p>
</th><th>
<p>
Service
</p>
</th></tr></thead><tbody><tr><td>
<p>
<code class="literal">host</code>
</p>
</td><td>
<p>
Telnet, RSH, SSH
</p>
</td></tr><tr><td>
<p>
<code class="literal">nfs</code>
</p>
</td><td>
<p>
NFSv4 (with Kerberos support)
</p>
</td></tr><tr><td>
<p>
<code class="literal">HTTP</code>
</p>
</td><td>
<p>
HTTP (with Kerberos authentication)
</p>
</td></tr><tr><td>
<p>
<code class="literal">imap</code>
</p>
</td><td>
<p>
IMAP
</p>
</td></tr><tr><td>
<p>
<code class="literal">pop</code>
</p>
</td><td>
<p>
POP3
</p>
</td></tr><tr><td>
<p>
<code class="literal">ldap</code>
</p>
</td><td>
<p>
LDAP
</p>
</td></tr></tbody></table></div><p>
Service principals are similar to user principals, but have significant
differences. The main difference between a user principal and a service
principal is that the key of the former is protected by a
password—when a user obtains a ticket-granting ticket from the
KDC, he needs to type his password so Kerberos can decrypt the ticket.
It would be quite inconvenient for the system administrator if he had to
obtain new tickets for the SSH daemon every eight hours or so.
</p><p>
Instead, the key required to decrypt the initial ticket for the service
principal is extracted by the administrator from the KDC only once and
stored in a local file called the <span class="emphasis"><em>keytab</em></span>. Services
such as the SSH daemon read this key and use it to obtain new tickets
automatically, when needed. The default keytab file resides in
<code class="filename">/etc/krb5.keytab</code>.
</p><a class="indexterm" name="id580234"></a><a class="indexterm" name="id580242"></a><p>
To create a host service principal for <code class="literal">jupiter.example.com</code>
enter the following commands during your kadmin session:
</p><pre class="screen">kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.</pre><p>
Instead of setting a password for the new principal, the
<code class="option">-randkey</code> flag tells <span class="command"><strong>kadmin</strong></span> to
generate a random key. This is used here because no user interaction is
wanted for this principal. It is a server account for the machine.
</p><p>
Finally, extract the key and store it in the local keytab file
<code class="filename">/etc/krb5.keytab</code>. This file is owned by the
superuser, so you must be <code class="systemitem">root</code>
to execute the next command in the kadmin shell:
</p><pre class="screen">kadmin: ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:</pre><a class="indexterm" name="id580290"></a><p>
When completed, make sure that you destroy the admin ticket obtained
with kinit above with <span class="command"><strong>kdestroy</strong></span>.
</p></div><div class="sect2" title="6.4.9. Enabling PAM Support for Kerberos"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.pam"></a>6.4.9. Enabling PAM Support for Kerberos<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.pam">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.Kerberos_PAM_support"></a><p>
openSUSE® comes with a PAM module named
<code class="filename">pam_krb5</code>, which supports Kerberos login and
password update. This module can be used by applications such as console
login, su, and graphical login applications like KDM (where the user
presents a password and would like the authenticating application to
obtain an initial Kerberos ticket on his behalf). To configure PAM
support for Kerberos, use the following command:
</p><pre class="screen">pam-config --add --krb5</pre><p>
The above command adds the <code class="filename">pam_krb5</code> module to the
existing PAM configuration files and makes sure it is called in the
right order. To make precise adjustments to the way in which
<code class="filename">pam_krb5</code> is used, edit the file
<code class="filename">/etc/krb5.conf</code> and add default applications to
<code class="filename">pam</code>. For details, refer to the manual page with
<span class="command"><strong>man <code class="option">5 pam_krb5</code></strong></span>.
</p><a class="indexterm" name="id580363"></a><p>
The <code class="filename">pam_krb5</code> module was specifically not designed
for network services that accept Kerberos tickets as part of user
authentication. This is an entirely different matter, and is discussed
below.
</p><a class="indexterm" name="id580379"></a></div><div class="sect2" title="6.4.10. Configuring SSH for Kerberos Authentication"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.sshd"></a>6.4.10. Configuring SSH for Kerberos Authentication<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.sshd">¶</a></span></h3></div></div></div><a class="indexterm" name="id580392"></a><p>
OpenSSH supports Kerberos authentication in both protocol version 1
and 2. In version 1, there are special protocol messages to
transmit Kerberos tickets. Version 2 does not use Kerberos directly
anymore, but relies on GSSAPI, the General Security Services API. This
is a programming interface that is not specific to Kerberos—it was
designed to hide the peculiarities of the underlying authentication
system, be it Kerberos, a public-key authentication system like SPKM, or
others. The included GSSAPI library supports only Kerberos, however.
</p><p>
To use sshd with Kerberos authentication, edit
<code class="filename">/etc/ssh/sshd_config</code> and set the following options:
</p><a class="indexterm" name="id580414"></a><pre class="screen"># These are for protocol version 1
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes
# These are for version 2 - better to use this
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes</pre><p>
Then restart your SSH daemon using <span class="command"><strong>rcsshd</strong></span>
<code class="option">restart</code>.
</p><p>
To use Kerberos authentication with protocol version 2, enable it on the
client side as well. Do this either in the systemwide configuration file
<code class="filename">/etc/ssh/ssh_config</code> or on a per-user level by
editing <code class="filename">~/.ssh/config</code>. In both cases, add the
option <code class="literal">GSSAPIAuthentication yes</code>.
</p><a class="indexterm" name="id580450"></a><p>
You should now be able to connect using Kerberos authentication. Use
<span class="command"><strong>klist</strong></span> to verify that you have a valid ticket then
connect to the SSH server. To force SSH protocol version 1, specify the
<code class="literal">-1</code> option on the command line.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Additional Information"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Additional Information</th></tr><tr><td colspan="2" align="left" valign="top"><p>
The file
<code class="filename">/usr/share/doc/packages/openssh/README.kerberos</code>
discusses the interaction of OpenSSH and Kerberos in more detail.
</p></td></tr></table></div></div><div class="sect2" title="6.4.11. Using LDAP and Kerberos"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.kerberos.admin.ldap"></a>6.4.11. Using LDAP and Kerberos<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.ldap">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.Kerberos_LDAP_and"></a><a class="indexterm" name="idx.LDAP_Kerberos_and"></a><p>
When using Kerberos, one way to distribute the user information (such as
user ID, groups,and home directory) in your local network is to use
LDAP. This requires a strong authentication mechanism that prevents
packet spoofing and other attacks. One solution is to use Kerberos for
LDAP communication, too.
</p><p>
OpenLDAP implements most authentication flavors through SASL, the simple
authentication session layer. SASL is basically a network protocol
designed for authentication. The SASL implementation is cyrus-sasl,
which supports a number of different authentication flavors. Kerberos
authentication is performed through GSSAPI (General Security Services
API). By default, the SASL plug-in for GSSAPI is not installed. Install
the <code class="systemitem">cyrus-sasl-gssapi</code> with YaST.
</p><p>
To enable Kerberos to bind to the OpenLDAP server, create a principal
<code class="literal">ldap/ldap.example.com</code> and add that to the keytab.
</p><p>
By default, the LDAP server slapd runs as user and group
<code class="systemitem">ldap</code>, while the keytab file is
readable by <code class="systemitem">root</code> only.
Therefore, either change the LDAP configuration so the server runs as
<code class="systemitem">root</code> or make the keytab
file readable by the group
<code class="systemitem">ldap</code>. The latter is done
automatically by the OpenLDAP start script
(<code class="filename">/etc/init.d/ldap</code>) if the keytab file has been
specified in the <code class="envar">OPENLDAP_KRB5_KEYTAB</code> variable in
<code class="filename">/etc/sysconfig/openldap</code> and the
<code class="envar">OPENLDAP_CHOWN_DIRS</code> variable is set to
<code class="literal">yes</code>, which is the default setting. If
<code class="envar">OPENLDAP_KRB5_KEYTAB</code> is left empty, the default keytab
under <code class="filename">/etc/krb5.keytab</code> is used and you must adjust
the privileges yourself as described below.
</p><p>
To run slapd as <code class="systemitem">root</code>, edit
<code class="filename">/etc/sysconfig/openldap</code>. Disable the
<code class="systemitem">OPENLDAP_USER</code> and
<code class="systemitem">OPENLDAP_GROUP</code> variables by putting a comment
character in front of them.
</p><a class="indexterm" name="id580600"></a><p>
To make the keytab file readable by group LDAP, execute
</p><pre class="screen">chgrp ldap /etc/krb5.keytab
chmod 640 /etc/krb5.keytab</pre><p>
A third (and maybe the best) solution is to tell OpenLDAP to use a
special keytab file. To do this, start kadmin, and enter the following
command after you have added the principal ldap/ldap.example.com:
</p><pre class="screen">ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM</pre><p>
Then in the shell run:
</p><pre class="screen">chown ldap.ldap /etc/openldap/ldap.keytab
chmod 600 /etc/openldap/ldap.keytab</pre><p>
To tell OpenLDAP to use a different keytab file, change the following
variable in <code class="filename">/etc/sysconfig/openldap</code>:
</p><pre class="screen">OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"</pre><p>
Finally, restart the LDAP server using
<span class="command"><strong>rcldap</strong></span> <code class="option">restart</code>.
</p><div class="sect3" title="6.4.11.1. Using Kerberos Authentication with LDAP"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.ldap.auth"></a>6.4.11.1. Using Kerberos Authentication with LDAP<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.ldap.auth">¶</a></span></h4></div></div></div><p>
You are now able to automatically use tools such as ldapsearch with
Kerberos authentication.
</p><pre class="screen">ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)'
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]
# geeko, people, example.com
dn: uid=geeko,ou=people,dc=example,dc=com
uid: geeko
cn: Olaf Kirch
[...]</pre><a class="indexterm" name="id580666"></a><p>
As you can see, ldapsearch prints a message that it started GSSAPI
authentication. The next message is very cryptic, but it shows that the
<span class="emphasis"><em>security strength factor</em></span> (SSF for short) is 56
(The value 56 is somewhat arbitrary. Most likely it was chosen because
this is the number of bits in a DES encryption key). What this tells
you is that GSSAPI authentication was successful and that encryption is
being used to protect integrity and provide confidentiality for the
LDAP connection.
</p><p>
In Kerberos, authentication is always mutual. This means that not only
have you authenticated yourself to the LDAP server, but also the LDAP
server has authenticated itself to you. In particular, this means
communication is with the desired LDAP server, rather than some bogus
service set up by an attacker.
</p></div><div class="sect3" title="6.4.11.2. Kerberos Authentication and LDAP Access Control"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.kerberos.admin.ldap.acl"></a>6.4.11.2. Kerberos Authentication and LDAP Access Control<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.admin.ldap.acl">¶</a></span></h4></div></div></div><p>
Now, allow each user to modify the login shell attribute of their LDAP
user record. Assuming you have a schema where the LDAP entry of user
<code class="systemitem">joe</code> is located at
<code class="filename">uid=joe,ou=people,dc=example,dc=com</code>, set up the
following access controls in
<code class="filename">/etc/openldap/slapd.conf</code>:
</p><a class="indexterm" name="id580715"></a><pre class="screen"># This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
by self write
# Every user can read everything
access to *
by users read</pre><p>
The second statement gives authenticated users write access to the
<code class="literal">loginShell</code> attribute of their own LDAP entry. The
third statement gives all authenticated users read access to the entire
LDAP directory.
</p><p>
There is one minor piece of the puzzle missing—how the LDAP
server can find out that the Kerberos user
<code class="literal">joe@EXAMPLE.COM</code> corresponds to the LDAP
distinguished name
<code class="literal">uid=joe,ou=people,dc=example,dc=com</code>. This sort of
mapping must be configured manually using the
<code class="literal">saslExpr</code> directive. In this example, add the
following to <code class="filename">slapd.conf</code>:
</p><a class="indexterm" name="id580753"></a><pre class="screen">authz-regexp
uid=(.*),cn=GSSAPI,cn=auth
uid=$1,ou=people,dc=example,dc=com</pre><p>
To understand how this works, you need to know that when SASL
authenticates a user, OpenLDAP forms a distinguished name from the name
given to it by SASL (such as <code class="literal">joe</code>) and the name of
the SASL flavor (<code class="literal">GSSAPI</code>). The result would be
<code class="literal">uid=joe,cn=GSSAPI,cn=auth</code>.
</p><p>
If a <code class="literal">authz-regexp</code> has been configured, it checks the
DN formed from the SASL information using the first argument as a
regular expression. If this regular expression matches, the name is
replaced with the second argument of the
<code class="literal">authz-regexp</code> statement. The placeholder
<code class="literal">$1</code> is replaced with the substring matched by the
<code class="literal">(.*)</code> expression.
</p><p>
More complicated match expressions are possible. If you have a more
complicated directory structure or a schema in which the username is
not part of the DN, you can even use search expressions to map the SASL
DN to the user DN.
</p><a class="indexterm" name="id580802"></a><a class="indexterm" name="id580807"></a><a class="indexterm" name="id580812"></a><a class="indexterm" name="id580817"></a></div></div></div><div class="sect1" title="6.5. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.kerberos.info"></a>6.5. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.kerberos.info">¶</a></span></h2></div></div></div><p>
The official site of the MIT Kerberos is
<a class="ulink" href="http://web.mit.edu/kerberos" target="_top">http://web.mit.edu/kerberos</a>. There, find links to any
other relevant resource concerning Kerberos, including Kerberos
installation, user, and administration guides.
</p><p>
The paper at
<a class="ulink" href="ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS" target="_top">ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS</a> gives
quite an extensive insight to the basic principles of Kerberos, without
being too difficult to read. It also provides a lot of opportunities for
further investigation and reading about Kerberos.
</p><p>
The official Kerberos FAQ is available at
<a class="ulink" href="http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html" target="_top">http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html</a>.
The book <span class="emphasis"><em>Kerberos—A Network Authentication
System</em></span> by Brian Tung (ISBN 0-201-37924-4) offers extensive
information.
</p><a class="indexterm" name="id580861"></a><a class="indexterm" name="id580866"></a></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.auth.html">Authentication</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 5. Active Directory Support" href="cha.security.ad.html"><span>◀</span></a> <a accesskey="n" title="Chapter 7. Using the Fingerprint Reader" href="cha.security.fp.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018