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.

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.

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:

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

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.

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.

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

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
   }

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

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

Error initializing krb5: Improper format of