Red Hat ENTERPRISE LINUX 5 - VIRTUAL SERVER ADMINISTRATION, Руководство по развертыванию, Страница: 701 / 848

Domain-to-Realm Mapping
675
contains the Cyrus SASL plugins which support GSS-API authentication. Cyrus IMAP should
function properly with Kerberos as long as the
cyrus
user is able to find the proper key in
/
etc/krb5.keytab
, and the root for the principal is set to
imap
(created with
kadmin
).
An alternative to
cyrus-imap
can be found in the
dovecot
package, which is also included in
Red Hat Enterprise Linux. This package contains an IMAP server but does not, to date, support
GSS-API and Kerberos.
• CVS — To use a kerberized CVS server,
gserver
uses a principal with a root of
cvs
and is
otherwise identical to the CVS
pserver
.
Refer to
Chapter 16, Controlling Access to Services
for details about how to enable services.
43.6.7. Domain-to-Realm Mapping
When a client attempts to access a service running on a particular server, it knows the name of the
service (
host
) and the name of the server (
foo.example.com
), but because more than one realm may
be deployed on your network, it must guess at the name of the realm in which the service resides.
By default, the name of the realm is taken to be the DNS domain name of the server, upper-cased.
foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.COM
In some configurations, this will be sufficient, but in others, the realm name which is derived will be the
name of a non-existant realm. In these cases, the mapping from the server's DNS domain name to the
name of its realm must be specified in the
domain_realm
section of the client system's
krb5.conf
.
For example:
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
The above configuration specifies two mappings. The first mapping specifies that any system in the
"example.com" DNS domain belongs to the
EXAMPLE.COM
realm. The second specifies that a
system with the exact name "example.com" is also in the realm. (The distinction between a domain
and a specific host is marked by the presence or lack of an initial ".".) The mapping can also be stored
directly in DNS.
43.6.8. Setting Up Secondary KDCs
For a number of reasons, you may choose to run multiple KDCs for a given realm. In this scenario,
one KDC (the
master KDC
) keeps a writable copy of the realm database and runs
kadmind
(it is
also your realm's
admin server
), and one or more KDCs (
slave KDCs
) keep read-only copies of the
database and run
kpropd
.
The master-slave propagation procedure entails the master KDC dumping its database to a temporary
dump file and then transmitting that file to each of its slaves, which then overwrite their previously-
received read-only copies of the database with the contents of the dump file.
To set up a slave KDC, first ensure that the master KDC's
krb5.conf
and
kdc.conf
files are copied
to the slave KDC.