KRB5.CONF(5)KRB5.CONF(5)NAMEkrb5.conf - Kerberos configuration file
DESCRIPTIONkrb5.conf contains configuration 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 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 values. Tags can also contain a subsec‐
tion, which contains further relations or subsections. A tag can be
assigned to multiple values. Here is an example of the INI-style for‐
mat 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 Kerberos V5 library.
[login]
Contains default values used by the Kerberos V5 login program,
login.krb5(8).
[appdefaults]
Contains default values that can be used by Kerberos V5 applica‐
tions.
[realms]
Contains subsections keyed by Kerberos realm names which
describe where to find the Kerberos servers for a particular
realm, and other realm-specific information.
[domain_realm]
Contains relations which map subdomains and domain names to Ker‐
beros 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 intermediate realms which may be used in cross-
realm authentication. It is also used by the end-service when
checking the transited field for trusted intermediate 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 session 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 session key
encryption types that should be requested by the client, in the
same format.
permitted_enctypes
This relation identifies the permitted list of session key
encryption types.
clockskew
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 default), 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 authentica‐
tor of KRB_AP_REQ messages. The default value for this type is
CKSUMTYPE_RSA_MD5. For compatibility with applications linked
against DCE version 1.1 or earlier Kerberos libraries, use a
value of 2 to use the CKSUMTYPE_RSA_MD4 instead.
safe_checksum_type
This allows you to set the preferred keyed-checksum type for use
in KRB_SAFE messages. The default value for this type is CKSUM‐
TYPE_RSA_MD5_DES. For compatibility with applications linked
against DCE version 1.1 or earlier Kerberos libraries, use a
value of 3 to use the CKSUMTYPE_RSA_MD4_DES instead. This field
is ignored when its value is incompatible with the session key
type.
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 versions 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 sys‐
tems, and a value of 2 on DCE 1.1 systems.
krb4_srvtab
Specifies the location of the Kerberos V4 srvtab file. Default
is "/etc/srvtab".
krb4_config
Specifies the location of hte Kerberos V4 configuration file.
Default is "/etc/krb.conf".
krb4_realms
Specifies the location of the Kerberos V4 domain/realm transla‐
tion file. Default is "/etc/krb.realms".
dns_lookup_kdc
Indicate whether DNS SRV records shoud be used to locate the
KDCs and other servers for a realm, if they are not listed in
the information for the realm. The default is to use these
records.
dns_lookup_realm
Indicate whether DNS TXT records should be used to determine the
Kerberos realm of a host. The default is not to use these
records.
dns_fallback
General flag controlling the use of DNS for Kerberos informa‐
tion. If both of the preceding options are specified, this
option has no effect.
extra_addresses
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.
udp_preference_limit
When sending a message to the KDC, the library will try using
TCP before UDP if the size of the message is above "udp_prefer‐
ence_limit". If the message is smaller than "udp_prefer‐
ence_limit", then UDP will be tried before TCP. Regardless of
the size, both protocols will be tried if the first attempt
fails.
verify_ap_req_nofail
If this flag is set, then an attempt to get initial credentials
will fail if the client machine does not have a keytab. The
default for the flag is false.
renew_lifetime
The value of this tag is the default renewable lifetime for ini‐
tial tickets. The default value for the tag is 0.
noaddresses
Setting this flag causes the initial Kerberos ticket to be
addressless. The default for the flag is true.
forwardable
If this flag is set, initial tickets by default will be forward‐
able. The default value for this flag is false.
proxiable
If this flag is set, initial tickets by default will be proxi‐
able. The default value for this flag is false.
APPDEFAULTS SECTION
Each tag in the [appdefaults] section names a Kerberos V5 application
or an option that is used by some Kerberos V5 application[s]. The four
ways that you can set values for options are as follows, 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
LOGIN SECTION
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 Kerberos realm.
The value of the tag is a subsection where the relations in that sub‐
section define the properties of that particular realm. For example:
[realms]
ATHENA.MIT.EDU = {
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 sub‐
section:
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. This tag should generally be
used only if the realm administrator has not made the informa‐
tion available through DNS.
admin_server
This relation identifies the host where the administration
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
principal names (which do).
v4_instance_convert
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 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 routines when con‐
verting 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.
auth_to_local_names
This subsection allows you to set explicit mappings from princi‐
pal names to local user names. The tag is the mapping name, and
the value is the corresponding local user name.
auth_to_local
This tag allows you to set a general rule for mapping principal
names to local user names. It will be used if there is not an
explicit mapping for the principal name that is being trans‐
lated. The possible values are:
DB:<filename>
The principal will be looked up in the database <file‐
name>. Support for this is not currently compiled in
by default.
RULE:<exp>
The local name will be formulated from <exp>.
DEFAULT
The principal name will be used as the local name. If
the principal has more than one component or is not in
the default realm, this rule is not applicable and the
conversion will fail.
DOMAIN_REALM SECTION
The [domain_realm] 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 [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:
kdc These entries specify how the KDC is to perform its logging.
admin_server
These entries specify how the administrative server is to per‐
form 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 over‐
written. 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 severity of system
log messages. This may be any of the following severities sup‐
ported 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 facili‐
ties 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, and if no
facility is specified, the default is AUTH.
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 admin‐
istrative 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 hierarchically. 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 sub‐
tags for each of the realms. The value of the subtags is an intermedi‐
ate 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 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 [capath] section of the configuration file used on NERSC.GOV sys‐
tems 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 tran‐
sited 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 orginization 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
/etc/krb5.conf
SEE ALSOsyslog(3)KRB5.CONF(5)
