krb5.conf(4)krb5.conf(4)NAMEkrb5.conf - Kerberos configuration file
DESCRIPTION
The configuration file, contains information needed by the Kerberos V5
library. This includes information describing the default Kerberos
realm and the location of the Kerberos key distribution centers for
known realms.
The file uses an INI-style format. Sections are delimited by square
brackets, Within each section, there are relations where tags can be
assigned to have specific values. Tags can also contain a subsection,
which contains further relations or subsections. A tag can be assigned
with multiple values. Here is an example of the INI-style format used
by
[section1]
tag1 = value_a
tag1 = value_b
tag2 = value_c
[section2]
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 file. Each will be
explained in more details.
Contains various default values used by the Kerberos V5 library.
Contains default values used by Kerberos V5 applications.
Contains default values used by the Kerberos V5 login program,
(Note: The Kerberized login program is not deliv‐
ered as part of this product.)
Contains Kerberos realm names which describe where
to find the Kerberos servers for a particular realm
and other realm-specific information.
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.
Contains relations which determine how Kerberos entities are to perform
their logging.
Contains the authentication paths used with non-hierarchical
cross-realm. Entries in this section are used by
the client to determine the intermediate realms
which may be used in cross-realm authentication.
It is also used by the end-service for checking the
transited field for trusted intermediate realms.
libdefaults Section
The following relations are defined in the section: Specifies the
default keytab name to be used by application severs such as telnetd
and rlogind. The default is This formerly defaulted to
Identifies the default realm to be used in a client host's
Kerberos activity.
Identifies the supported list of session key encryption
types that should be returned by the Key Distribution Center.
The list may be delimited with commas or white spaces. See ker‐
beros(5) for a list of supported encryption types for this tag.
Identifies the supported list of session key encryption
types that should be requested by the client, in the same for‐
mat. See kerberos(5) for a list of supported encryption types
for this tag.
Identifies the permitted list of session key encryption
types. See kerberos(5) for a list of supported encryption types
for this tag.
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.
Sets the timeout value for the amount of time (in seconds) to wait for
a response from an admin server. This can be any value between
1 and 300; if a value is specified outside this range, the time‐
out value will be set to the default value, 10.
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
Key Distribution Center. The difference is computed to correct
an inaccurate system clock. This corrective factor is only used
by the Kerberos library.
This relation is used for compatibility with DCE security servers
which do not support the default used by this version of Ker‐
beros. Use a value of 2 to use the instead. This applies to
DCE 1.1 and earlier.
Allows you to set the checksum type used in the authenticator of
messages. The default value for this type is For compatibility
with applications linked against DCE Kerberos libraries, use a
value of 2 so that is used instead. This applies to DCE 1.1 and
earlier.
Allows you to set the keyed-checksum type used in
messages. The default value for this type is For compatibility
with applications linked against DCE Kerberos libraries, use a
value of 3 so that is used instead. This applies to DCE 1.1 and
earlier.
Is used on systems which are DCE clients, to specify the
type of cache to be created by 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 use a value of 2 on DCE 1.1 systems.
This flag need to be set to 1 by the administrator if the realm name of
the
user needs to be obtained from the W2K multidomain. Refer to
the ldapux(5) man page for more information on configuring the
W2K multidomain.
This allows a computer to use multiple local addresses in order to
allow Kerberos to work in a network that uses NATs. The
addresses should be in a comma-separated list.
When sending a message to the Key Distribution Center (KDC),
the library will try using TCP before UDP if the size of the
message is above "udp_preference_limit". If the message is
smaller than "udp_preference_limit", then UDP will be tried
before TCP. Regardless of the size, both protocols will be
tried if the first attempt fails.
The value of this tag is the default renewable lifetime for initial
tickets. The default value for the tag is 0.
Setting this flag causes the initial Kerberos ticket to be addressless.
The default for the flag is true.
If this flag is set, initial tickets by default will be forwardable.
The default value for this flag is false.
If this flag is set, initial tickets by default will be proxiable.
The default value for this flag is false.
appdefaults Section
Each tag in the section names a Kerberos V5 application or an option
that is used by some Kerberos V5 application(s). The value of the tag
is a subsection with relations that define the default behaviors for
that application. The four ways to set values for options are as fol‐
lows, in decreasing order of precedence:
#1)
application = {
realm1 = {
option = value
}
realm2 = {
option = value
}
}
#2)
application = {
option1 = value
option2 = value
}
#3)
realm = {
option = value
}
#4)
option = value
The list of specifiable options for each application may be found in
the respective application man pages. The application defaults speci‐
fied in this section are overridden by those specified in the section.
login Section
The section is used to configure the behavior of the Kerberos V5 login
program,
realms Section
Each tag in the section of the file names a Kerberos 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
}
}
For each realm, the following tags may be specified in the realm's sub‐
section:
The value of this relation is the name of a host running
a Key Distribution Center for that realm. An
optional port number (preceded by a colon) may be
appended to the hostname.
Identifies the host where the administration server is running.
Typically this is the Master Kerberos server.
NOTE: Listing a secondary admin server may update
the password on the secondary. This may result in
an inconsistency if there is no password sync mech‐
anism from the secondary to the Master server.
This occurs in the following cases:
· The secondary server is listed above the pri‐
mary. In this case the will find the sec‐
ondary server first and update the password on
the secondary server.
· If none of the servers listed above the sec‐
ondary server respond, then will update the
password on the secondary.
Identifies the default domain for the hosts in the
realm. This is needed for translating V4 principal
names (which do not contain a domain name) to V5
principal names (which do contain a domain name).
This subsection allows the administrator to configure exceptions to the
default_domain mapping rule. It contains V4
instances (the tag name) which should be translated
to some specific hostname (the tag value) similar
to the second component in a Kerberos V5 principal
name.
domain_realm Section
The section provides a translation from a hostname to the Kerberos
realm name for the services provided 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 considered to be
the hostname's domain portion converted to upper case. For example,
the following 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 into the realm. All other hosts in the domain to the realm, and
all hosts in the domain into the realm. would be mapped by the default
rules to the realm. would be mapped to the realm.
logging Section
The section indicates how a particular entity is to perform its log‐
ging. The relations specified in this section assign one or more val‐
ues to the entity name.
Currently, the following entities are used:
These entries specify how the Key Distribution Center is to perform its
logging.
These entries specify how the administrative server is to perform its
logging.
These entries specify how to perform logging in the absence of explicit
specifications otherwise.
Values for each of these entries take the form entry = value where
entry is one of or and value is one of the following:
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.
This value causes the entity's logging messages to go to its
standard
error stream.
This value causes the entity's logging messages to go to the
console if
the system supports it.
This causes the entity's logging messages to go to the specified
device.
This causes the entity's logging messages to go to the system
log.
The severity argument specifies the default
severity of system log messages. This may
be any of the following severities mentioned
below supported by the call (see sys‐
log(3C)). The supported arguments are:
For example, to specify severity, you would
use for severity. The prefix is deleted.
The facility argument specifies the facility
under which the messages are logged. This
may be any of the following facilities sup‐
ported by the call (see syslog(3C)). The
supported arguments are: and through
If no severity is specified, the default is
If no facility is specified, the default is
In the following example, the logging messages from the Key Dis‐
tribution Center will go to the console and to the system log
under the facility with default severity of the logging messages
from the administrative server will be appended to the file and
sent to the device
[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 hierarchi‐
cally. This hierarchy is based on the name of the realm.
Hence, restrictions are imposed on the choice of realm names and
on who may participate in a cross-realm authentication. A non
hierarchical organization 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 by the
client by checking the transited field of the received ticket.
There is a tag name for every participating realm. 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 authenti‐
cate with. A server needs a tag for each realm of the clients
it will serve.
For example, and all wish to use the realm as an intermediate
realm. has a sub realm of which will authenticate with but not
The section for systems would look like this:
[capaths]
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 section of the configuration file used on 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 determine 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 can‐
not find a client/server path, then normal hierarchical organi‐
zation is assumed.
This feature is not currently supported by DCE. DCE security
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
Kerberos configuration file.
A sample Kerberos configuration file shipped with this product.
AUTHOR
was developed by the Massachusetts Institute of Technology.
SEE ALSOsyslog(3C), kerberos(5), ldapux(5).
krb5.conf(4)
