krb5.conf(4)
NAME
krb5.conf - Kerberos configuration file
SYNOPSIS
/etc/krb5/krb5.conf
DESCRIPTION
The krb5.conf file contains Kerberos configuration informa-
tion, including the locations of KDCs and administration
daemons for the Kerberos realms of interest, defaults for
the current realm and for Kerberos applications, and map-
pings of host names onto Kerberos realms. This file must
reside on all Kerberos clients.
The format of the krb5.conf consists of sections headings in
square brackets. Each section may contain zero or more con-
figuration variables (called relations), of the form:
relation= relation-value
or
relation-subsection = {
relation= relation-value
relation= relation-value
}
The krb5.conf file may contain any or all of the following
seven sections:
libdefaults
Contains default values used by the Kerberos V5
library.
appdefaults
Contains subsections for Kerberos V5 applications,
where relation-subsection is the name of an applica-
tion. Each subsection describes application-specific
defaults.
realms
Contains subsections for Kerberos realms, where
relation-subsection is the name of a realm. Each sub-
section contains relations that define the properties
for that particular realm.
domain_realm
Contains relations which map domain names and
subdomains onto 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 pro-
grams are to perform logging.
capaths
Contains the authentication paths used with direct
(nonhierarchical) cross-realm authentication. 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 when checking the transited field for trusted
intermediate realms.
kdc For a KDC, may contain the location of the kdc.conf
file.
[libdefaults]
The [libdefaults] section may contain any of the following
relations:
default_realm
Identifies the default Kerberos realm for the client.
Set its value to your Kerberos realm.
default_tgs_enctypes
Identifies the supported list of session key encryp-
tion types that should be returned by the KDC. The
list may be delimited with commas or whitespace. The
supported encryption types are des-cbc-crc and des-
cbc-md5.
default_tkt_enctypes
Identifies the supported list of session key encryp-
tion types that should be requested by the client. The
format is the same as for default_tkt_enctypes. The
supported encryption types are des-cbc-crc and des-
cbc-md5.
clockskew
Sets the maximum allowable amount of clock skew in
seconds that the library will tolerate before assuming
that a Kerberos message is invalid. The default value
is 300 seconds, or five minutes.
forwardable = [true | false]
Sets the "forwardable" flag in all tickets. This
allows users to transfer their credentials from one
host to another without reauthenticating. This option
may also be set in the [appdefaults] or [realms] sec-
tion (see below) to limit its use in particular appli-
cations or just to a specific realm.
proxiable = [true | false]
Sets the "proxiable" flag in all tickets. This allows
users to create a proxy ticket that can be transferred
to a kerberized service to allow that service to per-
form some function on behalf of the original user.
This option may also be set in the [appdefaults] or
[realms] section (see below) to limit its use in par-
ticular applications or just to a specific realm.
renew_lifetime = lifetime
Requests renewable tickets, with a total lifetime of
lifetime. The value for lifetime must be followed
immediately by one of the following delimiters:
s seconds
m minutes
h hours
d days
Example:
renew_lifetime = 90m
Do not mix units. A value of "3h30m" will result in an
error.
dns_lookup_kdc
Indicates whether DNS SRV records need to be used to
locate the KDCs and the other servers for a realm, if
they have not already been listed in the [realms] sec-
tion. Enabling this option does make the machine
vulnerable to a certain type of DoS attack if somone
spoofs the DNS records and does a redirect to another
server. This is, however, no worse than a DoS, since
the bogus KDC will be unable to decode anything sent
(excepting the initial ticket request, which has no
encrypted data). Also, anything the fake KDC sends out
will not be trusted without verification (the local
machine will be unaware of the secret key to be used).
If dns_lookup_kdc is not specified but dns_fallback
is, then that value will be used instead. In either
case, values (if present) in the [realms] section
override DNS.
dns_lookup_realm
Indicates whether DNS TXT records need to be used to
determine the Kerberos realm information and/or the
host/domain name-to-realm mapping of a host, if this
information is not already present in the krb5.conf
file. Enabling this option might make the host vulner-
able to a redirection attack, wherein spoofed DNS
replies persuade a client to authenticate to the wrong
realm. In a realm with no cross-realm trusts, this a
DoS attack. If dns_lookup_realm is not specified but
dns_fallback is, then that value will be used instead.
In either case, values (if present) in the [libde-
faults] and [domain_realm] sections override DNS.
dns_fallback
Generic flag controlling the use of DNS for retrieval
of information about Kerberos servers and host/domain
name-to-realm mapping. If both dns_lookup_kdc and
dns_lookup_realm have been specified, this option has
no effect.
verify_ap_req_nofail [true | false]
If true, the local keytab file (/etc/krb5/krb5.keytab)
must contain an entry for the local host principal,
for example, host/foo.bar.com@FOO.COM. This entry is
needed to verify that the TGT requested was issued by
the same KDC that issued the key for the host princi-
pal. If undefined, the behavior is as if this option
were set to true. Setting this value to false leaves
the system vulnerable to DNS spoofing attacks. This
parameter may be in the [realms] section to set it on
a per-realm basis, or it may be in the [libdefaults]
section to make it a network-wide setting for all
realms.
[appdefaults]
This section contains subsections for Kerberos V5 applica-
tions, where relation-subsection is the name of an applica-
tion. Each subsection contains relations that define the
default behaviors for that application.
The following relations may be found in the [appdefaults]
section, though not all relations are recognized by all ker-
berized applications. Some are specific to particular appli-
cations.
autologin = [true | false]
Forces the application to attempt automatic login by
presenting Kerberos credentials. This is only valid
for the telnet application.
encrypt = [true | false]
Forces applications to use encryption by default
(after authentication) to protect the privacy of the
sessions. This is valid for the following applica-
tions: rlogin, rsh, rcp, rdist, and telnet.
forward = [true | false]
Forces applications to forward the user'ss credentials
(after authentication) to the remote server. This is
valid for the following applications: rlogin, rsh,
rcp, rdist, and telnet.
forwardable = [true | false]
See the description in the [libdefaults] section
above. This is used by any application that creates a
ticket granting ticket and also by applications that
can forward tickets to a remote server.
proxiable = [true | false]
See the description in the [libdefaults] section
above. This is used by any application that creates a
ticket granting ticket.
renewable = [true | false]
Creates a TGT that can be renewed (prior to the ticket
expiration time). This is used by any application that
creates a ticket granting ticket.
no_addresses = [true | false]
Creates tickets with no address bindings. This is to
allow tickets to be used across a NAT boundary or when
using multi-homed systems. This option is valid in the
kinit [appdefault] section only.
max_life = lifetime
Sets the maximum lifetime of the ticket, with a total
lifetime of lifetime. The values for lifetime follow
the format described in the [libdefaults] section
above.
max_renewable_life = lifetime
Requests renewable tickets, with a total lifetime of
lifetime. The values for lifetime follow the format
described in the [libdefaults] section above.
rcmd_protocol = [ rcmdv1 | rcmdv2 ]
Specifies which Kerberized "rcmd" protocol to use when
using the Kerberized rlogin(1), rsh(1), rcp(1), or
rdist(1) programs. The default is to use "rcmdv2" by
default, as this is the more secure and more recent
update of the protocol. However, when talking to older
MIT or SEAM-based "rcmd" servers, it may be necessary
to force the new clients to use the older "rcmdv1"
protocol. This option is valid only for the following
applications: rlogin, rcp, rsh, and rdist.
gkadmin = {
help_url = http://localhost:8888/ab2/coll.384.1/SEAM
}
The following application defaults can be set to true or
false:
kinit
forwardable = true
proxiable = true
renewable = true
no_addresses = true
max_life = delta_time
max_renewable_life = delta_time
See kinit(1) for the valid time duration formats you can
specify for delta_time.
In the following example, kinit will get forwardable tickets
by default and telnet has three default behaviors specified:
[appdefaults]
kinit = {
forwardable = true
}
telnet = {
forward = true
encrypt = true
autologin = true
}
The application defaults specified here are overridden by
those specified in the [realms] section.
[realms]
This section contains subsections for Kerberos realms, where
relation-subsection is the name of a realm. Each subsection
contains relations that define the properties for that par-
ticular realm. The following relations may be specified in
each [realms] subsection:
kdc The name of a host running a KDC for that realm. An
optional port number (separated from the hostname by a
colon) may be included.
admin_server
Identifies the host where the Kerberos administration
daemon (kadmind) is running. Typically, this is the
master KDC.
application defaults
Application defaults that are specific to a particular
realm can be specified within a [realms] subsection.
Realm-specific application defaults override the glo-
bal defaults specified in the [appdefaults] section.
kpasswd_server
Identifies the host where the Kerberos password-
changing server is running. Typically, this is the
same as host indicated in the admin_server. If this
parameter is omitted, the host in admin_server is
used. You can also specify a port number if the server
indicated by kpasswd_server runs on a port other than
464 (the default). The format of this parameter is:
hostname[:port].
kpasswd_protocol
Identifies the protocol to be used when communicating
with the server indicated by kpasswd_server. By
default, this parameter is defined to be RPCSEC_GSS,
which is the protocol used by SEAM-based administra-
tion servers. To be able to change a principal's pass-
word stored on non-SEAM-based Kerberos server, such as
Microsoft Active Directory or MIT Kerberos, this value
should be SET_CHANGE. This indicates that a non-RPC-
based protocol will be used to communicate the pass-
word change request to the server in the
kpasswd_server entry.
verify_ap_req_nofail [true | false]
If true, the local keytab file (/etc/krb5/krb5.keytab)
must contain an entry for the local host principal,
for example, host/foo.bar.com@FOO.COM. This entry is
needed to verify that the TGT requested was issued by
the same KDC that issued the key for the host princi-
pal. If undefined, the behavior is as if this option
were set to true. Setting this value to false leaves
the system vulnerable to DNS spoofing attacks. This
parameter may be in the [realms] section to set it on
a per-realm basis, or it may be in the [libdefaults]
section to make it a network-wide setting for all
realms.
The parameters "forwardable", "proxiable", and
"renew_lifetime" as described in the [libdefaults] section
(see above) are also valid in the [realms] section.
Notice that kpasswd_server and kpasswd_protocol are realm-
specific parameters. Most often, you need to specify them
only when using a non-SEAM-based Kerberos server. Otherwise,
the change request is sent over RPCSEC_GSS to the SEAM
administration server.
[domain_realm]
This section provides a translation from a domain name or
hostname to a Kerberos realm name. The relation can be a
host name, or a domain name, where domain names are indi-
cated by a period (`.') prefix. relation-value is the Ker-
beros 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] sec-
tion maps crash.mit.edu into the TEST.ATHENA.MIT.EDU realm:
[domain_realm]
.mit.edu = ATHENA.MIT.EDU
mit.edu = ATHENA.MIT.EDU
crash.mit.edu = TEST.ATHENA.MIT.EDU
.fubar.org = FUBAR.ORG
fubar.org = FUBAR.ORG
All other hosts in the mit.edu domain will map by default to
the ATHENA.MIT.EDU realm, and all hosts in the fubar.org
domain will map by default into the FUBAR.ORG realm. Note
the entries for the hosts mit.edu and fubar.org. Without
these entries, these hosts would be mapped into the Kerberos
realms EDU and ORG, respectively.
[logging]
This section indicates how Kerberos programs are to perform
logging. There are two types of relations for this section:
relations to specify how to log and a relation to specify
how to rotate kdc log files.
The following relations may be defined to specify how to
log. The same relation can be repeated if you want to assign
it multiple logging methods.
admin_server
Specifies how to log the Kerberos administration dae-
mon (kadmind). The default is
FILE:/var/krb5/kadmin.log.
default
Specifies how to perform logging in the absence of
explicit specifications otherwise.
kdc Specifies how the KDC is to perform its logging. The
default is FILE:/var/krb5/kdc.log.
The admin_server, default, and kdc relations may have the
following values:
FILE:filename
FILE=filename
This value causes the entity's logging messages to go
to the specified file. If the `=' form is used, the
file is overwritten. If the `:' form is used, 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 sys-
tem log messages. This may be any of the following severi-
ties supported by the syslog(3C) call, minus the LOG_ pre-
fix: LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING,
LOG_NOTICE, LOG_INFO, and LOG_DEBUG. For example, a value of
CRIT would specify LOG_CRIT severity.
The facility argument specifies the facility under which the
messages are logged. This may be any of the following facil-
ities supported by the syslog(3C) call minus the LOG_ pre-
fix: 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. If no
facility is specified, the default is AUTH.
The following relation may be defined to specify how to
rotate kdc log files if the FILE: value is being used to
log:
kdc_rotate
A relation subsection that enables kdc logging to be
rotated to multiple files based on a time interval.
This can be used to avoid logging to one file, which
may grow too large and bring the KDC to a halt.
The time interval for the rotation is specified by the
period relation. The number of log files to be rotated is
specified by the versions relation. Both the period and ver-
sions (described below) should be included in this subsec-
tion. And, this subsection applies only if the kdc relation
has a FILE: value.
The following relations may be specified for the kdc_rotate
relation subsection:
period=delta_time
Specifies the time interval before a new log file is
created. See the Time Formats section in kinit(1) for
the valid time duration formats you can specify for
delta_time. If period is not specified or set to
"never", no rotation will occur.
Specifying a time interval does not mean that the log files
will be rotated at the time interval based on real time.
This is because the time interval is checked at each attempt
to write a record to the log, or when logging is actually
occurring. Therefore, rotation occurs only when logging has
actually occurred for the specified time interval.
versions=number
Specifies how many previous versions will be saved
before the rotation begins. A number will be appended
to the log file, starting with 0 and ending with
(number - 1). For example, if versions is set to 2, up
to three logging files will be created (filename,
filename.0, and filename.1) before the first one is
overwritten to begin the rotation.
Notice that if versions is not specified or set to 0, only
one log file will be created, but it will be overwritten
whenever the time interval is met.
In the following example, the logging messages from the Ker-
beros administration daemon will go to the console. The log-
ging messages from the KDC will be appended to the
/var/krb5/kdc.log, which will be rotated between twenty-one
log files with a specified time interval of a day.
[logging]
admin_server = CONSOLE
kdc = FILE:/export/logging/kadmin.log
kdc_rotate = {
period = 1d
versions = 20
}
[capaths]
In order to perform direct (non-hierarchical) cross-realm
authentication, a database is needed 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 subsection for each participating realm, and each
subsection has relations named for each of the realms. The
relation-value is an intermediate realm which may partici-
pate in the cross-realm authentication. The relations may be
repeated if there is more than 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 subsection
named for its local realm, with relations named for all the
realms of servers it will need to authenticate with. A
server needs a subsection named 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 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 relation is used more than once. The client
will use this to determine the path. (It is not important to
the server, since the transited field is not sorted.)
EXAMPLES
Example 1: Sample file
Here is an example of a generic krb5.conf file:
[libdefaults]
default_realm = ATHENA.MIT.EDU
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
[realms]
ATHENA.MIT.EDU = {
kdc = kerberos.mit.edu
kdc = kerberos-1.mit.edu
kdc = kerberos-2.mit.edu
admin_server = kerberos.mit.edu
default_domain = mit.edu
}
FUBAR.ORG = {
kdc = kerberos.fubar.org
kdc = kerberos-1.fubar.org
admin_server = kerberos.fubar.org
}
[domain_realm]
.mit.edu = ATHENA.MIT.EDU
mit.edu = ATHENA.MIT.EDU
FILES
/var/krb5/kdc.log
KDC logging file
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Interface Stability | Evolving |
|_____________________________|_____________________________|
SEE ALSO
kinit(1), rcp(1), rdist(1), rlogin(1), rsh(1), syslog(3C),
SEAM(5), attributes(5)
NOTES
If the krb5.conf file is not formatted properly, the telnet
command will fail. However, the dtlogin and login commands
will still succeed, even if the krb5.conf file is specified
as required for the commands. If this occurs, the following
error message will be displayed:
Error initializing krb5: Improper format of item
To bypass any other problems that may occur, you should fix
the file as soon as possible.
Man(1) output converted with
man2html