krb5.conf(4)

NAME

krb5.conf — Kerberos configuration file

DESCRIPTION

The configuration file, krb5.conf, 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 krb5.conf 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 krb5.conf:

   [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 krb5.conf file. Each will be explained in more details.

[libdefaults]: Contains various default values used by the Kerberos V5 library.
[appdefaults]: Contains default values used by Kerberos V5 applications.
[login]: Contains default values used by the Kerberos V5 login program, login.krb5. (Note: The Kerberized login program is not delivered as part of this product.)
[realms]: Contains 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 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 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 [libdefaults] section:

default_keytab_name: 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.
default_realm: Identifies the default realm to be used in a client host's Kerberos activity.
default_tgs_enctypes: 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.
default_tkt_enctypes: Identifies the supported list of session key encryption types that should be requested by the client, in the same format.
permitted_enctypes: Identifies the permitted list of session key encryption types.
clockskew: 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.
kpasswd_timeout: 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 timeout value will be set to the default value, 10.
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 Key Distribution Center. The difference is computed to correct an inaccurate system clock. This corrective factor is only used by the Kerberos library.
kdc_req_checksum_type: This relation is used for compatibility 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: 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 so that CKSUMTYPE_RSA_MD4 is used instead. This applies to DCE 1.1 and earlier.
safe_checksum_type: 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 so that CKSUMTYPE_RSA_MD4_DES is used instead. This applies to DCE 1.1 and earlier.
ccache_type: Is used 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 systems, and use a value of 2 on DCE 1.1 systems.
ldapux_multidomain: 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.
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 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.
renew_lifetime: The value of this tag is the default renewable lifetime for initial 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 forwardable. The default value for this flag is false.
proxiable: 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 [appdefaults] 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 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

The list of specifiable options for each application may be found in the respective application man pages. The application defaults specified in this section are overridden by those specified in the [realms] section.

login Section

The [login] section is used to configure the behavior of the Kerberos V5 login program, login.krb5.

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 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 subsection:

kdc

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.

admin_server

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 mechanism from the secondary to the Master server. This occurs in the following cases:

The secondary server is listed above the primary. In this case the admin_server will find the secondary server first and update the password on the secondary server.
If none of the servers listed above the secondary server respond, then admin_server will update the password on the secondary.

default_domain

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).

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 hostname (the tag value) similar to the second component in a Kerberos V5 principal name.

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. 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 Key Distribution Center is to perform its 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 for each of these entries take the form entry = value where entry is one of kdc, admin_server, or default and value is one of the following:

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 severity of system log messages. This may be any of the following severities mentioned below supported by the syslog() call (see syslog(3C)). The supported arguments are:

LOG_ALERT LOG_CRIT LOG_DEBUG LOG_ERR

LOG_EMERG LOG_INFO LOG_NOTICE LOG_WARNING

For example, to specify LOG_CRIT severity, you would use CRIT for severity. The LOG_ prefix is deleted.

The facility argument specifies the facility under which the messages are logged. This may be any of the following facilities supported by the syslog() call (see syslog(3C)). The supported arguments are: 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.

In the following example, the logging messages from the Key Distribution Center will go to the console and to the system log under the facility LOG_DAEMON with default severity of LOG_INFO; 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 hierarchically. 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 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 [capaths] 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 [capaths] 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 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 cannot find a client/server path, then normal hierarchical organization 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: Kerberos configuration file.
/usr/contrib/krb5/sample/krb5.conf.sample: A sample Kerberos configuration file shipped with this product.

AUTHOR

krb5.conf was developed by the Massachusetts Institute of Technology.