Manpages

NAME

krb5.conf − Kerberos configuration file

SYNOPSIS

/etc/krb5/krb5.conf

DESCRIPTION

The krb5.conf file contains Kerberos configuration information, including the locations of KDCs and administration daemons for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings 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 configuration variables (called relations), of the form:

relation= relation-value

or

relation-subsection = {

}

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 application. Each subsection describes application-specific defaults.

realms

Contains subsections for Kerberos realms, where relation-subsection is the name of a realm. Each subsection 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 programs 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.

[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 encryption 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 encryption 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.

[appdefaults]
This section contains subsections for Kerberos V5 applications, where relation-subsection is the name of an application. Each subsection contains relations that define the default behaviors for that application.

gkadmin = {
help_url = http://localhost:8888/ab2/coll.384.1/SEAM
}

The following application defaults can be set to true or false:

kinit
forwardable
proxiable
renewable
no_addresses
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 particular realm. The following relations may be specified in each [realms] subsection:

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 global 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 administration servers. To be able to change a principal’s password 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 password change request to the server in the kpasswd_server entry.

Note 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 indicated by a period (’.’) prefix. relation-value 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 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 daemon (kadmind). The default is FILE:/var/krb5/kadmin.log.

default

Specifies how to perform logging in the absence of explicit specifications otherwise.

The admin_server, default, and kdc relations may have the following values:

FILE:filename

or
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 system log messages. This may be any of the following severities supported by the syslog(3C) call, minus the LOG_ prefix: 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 facilities supported by the syslog(3C) 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. 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 versions (described below) should be included in this subsection. 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 Kerberos administration daemon will go to the console. The logging 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 participate 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]
ticket_lifetime = 600
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 attributes:

SEE ALSO

kinit(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

To bypass any other problems that may occur, you should fix the file as soon as possible.