|
|
|
|
krb5.conf - Kerberos configuration file
DESCRIPTION
krb5.conf contains configuration information needed by the
Kerberos V5 library. This includes information describing
the default Kerberos realm, and the location of the Ker-
beros key distribution centers for known realms.
The krb5.conf file uses an INI-style format. Sections are
delimited by square braces; within each section, there are
relations where tags can be assigned to have specific val-
ues. Tags can also contain a subsection, which contains
further relations or subsections. A tag can be assigned
to multiple values. Here is an example of the INI-style
format used by krb5.conf:
[section1]
tag1 = value_a
tag1 = value_b
tag2 = value_c
[section 2]
tag3 = {
subtag1 = subtag_value_a
subtag1 = subtag_value_b
subtag2 = subtag_value_c
}
tag4 = {
subtag1 = subtag_value_d
subtag2 = subtag_value_e
}
The following sections are currently used in the krb5.conf
file:
[libdefaults]
Contains various default values used by the Ker-
beros V5 library.
[login]
Contains default values used by the Kerberos V5
login program, login.krb5(8).
[realms]
Contains subsections keyed by Kerberos realm names
which describe where to find the Kerberos servers
for a particular realm, and other realm-specific
Contains relations which map subdomains and domain
names to Kerberos realm names. This is used by
programs to determine what realm a host should be
in, given its fully qualified domain name.
[logging]
Contains relations which determine how Kerberos
entities are to perform their logging.
[capaths]
Contains the authentication paths used with non-
hierarchical cross-realm. Entries in the section
are used by the client to determine the intermedi-
ate realms which may be used in cross-realm authen-
tication. It is also used by the end-service when
checking the transited field for trusted intermedi-
ate realms.
Each of these sections will be covered in more details in
the following sections.
LIBDEFAULTS SECTION
The following relations are defined in the [libdefaults]
section:
default_keytab_name
This relation specifies the default keytab name to
be used by application severs such as telnetd and
rlogind. The default is "/etc/krb5.keytab". This
formerly defaulted to "/etc/v5srvtab", but was
changed to the current value.
default_realm
This relation identifies the default realm to be
used in a client host's Kerberos activity.
default_tgs_enctypes
This relation identifies the supported list of ses-
sion key encryption types that should be returned
by the KDC. The list may be delimited with commas
or whitespace.
default_tkt_enctypes
This relation identifies the supported list of ses-
sion key encryption types that should be requested
by the client, in the same format.
This relation sets the maximum allowable amount of
clockskew in seconds that the library will tolerate
before assuming that a Kerberos message is invalid.
The default value is 300 seconds, or five minutes.
kdc_timesync
If the value of this relation is non-zero, the
library will compute the difference between the
system clock and the time returned by the KDC and
in order to correct for an inaccurate system clock.
This corrective factor is only used by the Kerberos
library.
kdc_req_checksum_type
For compatability with DCE security servers which
do not support the default CKSUMTYPE_RSA_MD5 used
by this version of Kerberos. Use a value of 2 to
use the CKSUMTYPE_RSA_MD4 instead. This applies to
DCE 1.1 and earlier.
ap_req_checksum_type
This allows you to set the checksum type used in
the authenticator of KRB_AP_REQ messages. The
default value for this type is CKSUMTYPE_RSA_MD5.
For compatibility with applications linked against
DCE Kerberos libraries, use a value of 2 to use the
CKSUMTYPE_RSA_MD4 instead. This applies to DCE 1.1
and earlier.
safe_checksum_type
This allows you to set the keyed-checksum type used
in KRB_SAFE messages. The default value for this
type is CKSUMTYPE_RSA_MD5_DES. For compatibility
with applications linked against DCE Kerberos
libraries, use a value of 3 to use the CKSUM-
TYPE_RSA_MD4_DES instead. This applies to DCE 1.1
and earlier.
ccache_type
User this parameter on systems which are DCE
clients, to specify the type of cache to be created
by kinit, or when forwarded tickets are received.
DCE and Kerberos can share the cache, but some ver-
sions of DCE do not support the default cache as
created by this version of Kerberos. Use a value of
1 on DCE 1.0.3a systems, and a value of 2 on DCE
1.1 systems.
The [login] section is used to configure the behavior of
the Kerberos V5 login program, login.krb5(8). Refer to
the manual entry for login.krb5 for a description of the
relations allowed in this section.
REALMS SECTION
Each tag in the [realms] section of the file names a Ker-
beros realm. The value of the tag is a subsection where
the relations in that subsection define the properties of
that particular realm. For example:
[realms]
ATHENA.MIT.EDU = {
kdc = KERBEROS.MIT.EDU
kdc = KERBEROS-1.MIT.EDU:750
kdc = KERBEROS-2.MIT.EDU:88
admin_server = KERBEROS.MIT.EDU
default_domain = MIT.EDU
v4_instance_convert = {
mit = mit.edu
lithium = lithium.lcs.mit.edu
}
v4_realm = LCS.MIT.EDU
}
For each realm, the following tags may be specified in the
realm's subsection:
kdc The value of this relation is the name of a host
running a KDC for that realm. An optional port
number (preceded by a colon) may be appended to the
hostname.
admin_server
This relation identifies the host where the admin-
istration server is running. Typically this is the
Master Kerberos server.
default_domain
This relation identifies the default domain for
which hosts in this realm are assumed to be in.
This is needed for translating V4 principal names
(which do not contain a domain name) to V5 princi-
pal names (which do).
v4_instance_convert
rule. It contains V4 instances (the tag name)
which should be translated to some specific host-
name (the tag value) as the second component in a
Kerberos V5 principal name.
v4_realm
This relation is used by the krb524 library rou-
tines when converting a V5 principal name to a V4
principal name. It is used when V4 realm name and
the V5 realm are not the same, but still share the
same principal names and passwords. The tag value
is the Kerberos V4 realm name.
DOMAIN_REALM SECTION
The [domain_realm] section provides a translation from a
hostname to the Kerberos realm name for the services pro-
vided by that host.
The tag name can be a hostname, or a domain name, where
domain names are indicated by a prefix of a period ('.')
character. The value of the relation is the Kerberos
realm name for that particular host or domain. Host names
and domain names should be in lower case.
If no translation entry applies, the host's realm is con-
sidered to be the hostname's domain portion converted to
upper case. For example, the following [domain_realm]
section:
[domain_realm]
.mit.edu = ATHENA.MIT.EDU
mit.edu = ATHENA.MIT.EDU
dodo.mit.edu = SMS_TEST.MIT.EDU
.ucsc.edu = CATS.UCSC.EDU
maps dodo.mit.edu into the SMS_TEST.MIT.EDU realm, all
other hosts in the MIT.EDU domain to the ATHENA.MIT.EDU
realm, and all hosts in the UCSC.EDU domain into the
CATS.UCSC.EDU realm. ucbvax.berkeley.edu would be mapped
by the default rules to the BERKELEY.EDU realm, while
sage.lcs.mit.edu would be mapped to the LCS.MIT.EDU realm.
LOGGING SECTION
The [logging] section indicates how a particular entity is
to perform its logging. The relations specified in this
section assign one or more values to the entity name.
Currently, the following entities are used:
logging.
admin_server
These entries specify how the administrative server
is to perform its logging.
default
These entries specify how to perform logging in the
absence of explicit specifications otherwise.
Values are of the following forms:
FILE=<filename>
FILE:<filename>
This value causes the entity's logging messages to
go to the specified file. If the = form is used,
then the file is overwritten. Otherwise, the file
is appended to.
STDERR This value causes the entity's logging messages to
go to its standard error stream.
CONSOLE
This value causes the entity's logging messages to
go to the console, if the system supports it.
DEVICE=<devicename>
This causes the entity's logging messages to go to
the specified device.
SYSLOG[:<severity>[:<facility>]]
This causes the entity's logging messages to go to
the system log.
The severity argument specifies the default sever-
ity of system log messages. This may be any of the
following severities supported by the syslog(3)
call minus the LOG_ prefix: LOG_EMERG, LOG_ALERT,
LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE,
LOG_INFO, and LOG_DEBUG. For example, to specify
LOG_CRIT severity, one would use CRIT for severity.
The facility argument specifies the facility under
which the messages are logged. This may be any of
the following facilities supported by the syslog(3)
call minus the LOG_ prefix: LOG_KERN, LOG_USER,
LOG_MAIL, LOG_DAEMON, LOG_AUTH, LOG_LPR, LOG_NEWS,
LOG_UUCP, LOG_CRON, and LOG_LOCAL0 through
LOG_LOCAL7.
If no severity is specified, the default is ERR,
In the following example, the logging messages from the
KDC will go to the console and to the system log under the
facility LOG_DAEMON with default severity of LOG_INFO; and
the logging messages from the administrative server will
be appended to the file /var/adm/kadmin.log and sent to
the device /dev/tty04.
[logging]
kdc = CONSOLE
kdc = SYSLOG:INFO:DAEMON
admin_server = FILE:/var/adm/kadmin.log
admin_server = DEVICE=/dev/tty04
CAPATHS SECTION
Cross-realm authentication is typically organized hierar-
chically. This hierarchy is based on the name of the
realm, which thus imposes restrictions on the choice of
realm names, and on who may participate in a cross-realm
authentication. A non hierarchical orgization may be used,
but requires a database to construct the authentication
paths between the realms. This section defines that
database.
A client will use this section to find the authentication
path between its realm and the realm of the server. The
server will use this section to verify the authentication
path used be the client, by checking the transited field
of the received ticket.
There is a tag name for each participating realm, and each
tag has subtags for each of the realms. The value of the
subtags is an intermediate realm which may participate in
the cross-realm authentication. The subtags may be
repeated if there is more then one intermediate realm. A
value of "." means that the two realms share keys
directly, and no intermediate realms should be allowed to
participate.
There are n**2 possible entries in this table, but only
those entries which will be needed on the client or the
server need to be present. The client needs a tag for its
local realm, with subtags for all the realms of servers it
will need to authenticate with. A server needs a tag for
each realm of the clients it will serve.
For example, ANL.GOV, PNL.GOV, and NERSC.GOV all wish to
use the ES.NET realm as an intermediate realm. ANL has a
sub realm of TEST.ANL.GOV which will authenticate with
NERSC.GOV but not PNL.GOV. The [capath] section for
ANL.GOV = {
TEST.ANL.GOV = .
PNL.GOV = ES.NET
NERSC.GOV = ES.NET
ES.NET = .
}
TEST.ANL.GOV = {
ANL.GOV = .
}
PNL.GOV = {
ANL.GOV = ES.NET
}
NERSC.GOV = {
ANL.GOV = ES.NET
}
ES.NET = {
ANL.GOV = .
}
The [capath] section of the configuration file used on
NERSC.GOV systems would look like this:
[capaths]
NERSC.GOV = {
ANL.GOV = ES.NET
TEST.ANL.GOV = ES.NET
TEST.ANL.GOV = ANL.GOV
PNL.GOV = ES.NET
ES.NET = .
}
ANL.GOV = {
NERSC.GOV = ES.NET
}
PNL.GOV = {
NERSC.GOV = ES.NET
}
ES.NET = {
NERSC.GOV = .
}
TEST.ANL.GOV = {
NERSC.GOV = ANL.GOV
NERSC.GOV = ES.NET
}
In the above examples, the ordering is not important,
except when the same subtag name is used more then once.
The client will use this to determing the path. (It is not
important to the server, since the transited field is not
sorted.)
If this section is not present, or if the client or server
cannot find a client/server path, then normal hierarchical
rity servers can be used with Kerberized clients and
servers, but versions prior to DCE 1.1 did not fill in the
transited field, and should be used with caution.
FILES
/etc/krb5.conf
SEE ALSO
syslog(3)
|
|
Copyright © 2000-2009 Inside Mac Media, Inc. All rights reserved. |
Apple assumes no responsibility with regard to the selection, performance, or use of the products or services. All understandings, agreements, or warranties, if any, take place directly between the vendors and prospective users. |
| Apple, the Apple logo, Mac, PowerMac G4, PowerMac G5, Xserve, Xserve RAID, PowerBook, iBook, Airport, AirPort Extreme, iMac, eMac, iLife, iMovie, iCal, iPhoto, iTunes, QuickTime, FireWire, iPod, iSight, AppleWorks, Macintosh, Jaguar, Panther, Mac OS, Mac OS X and Mac OS X Server are trademarks of Apple Computer, Inc. |
