krb5.conf(4) File Formats krb5.conf(4)
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 = {
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 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.
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_keytab_name
Specifies the default keytab name to be used by application servers such as telnetd and rlogind. The default is /etc/krb5/krb5.keytab.
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 des3-cbc-sha1, des-cbc-crc, des-cbc-md5, arcfour-hmac-md5, arcfour-hmac-md5-exp,
aes128-cts-hmac-sha1-96, and aes256-cts-hmac-sha1-96.
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 des3-cbc-sha1, des-cbc-crc, des-cbc-md5, arcfour-hmac-md5, arcfour-hmac-
md5-exp, aes128-cts-hmac-sha1-96, and aes256-cts-hmac-sha1-96.
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 reauthen-
ticating. This option may also be set in the [appdefaults] or [realms] section (see below) to limit its use in particular applications
or just to a specific realm.
permitted_enctypes
This relation controls the encryption types for session keys permitted by server applications that use Kerberos for authentication. In
addition, it controls the encryption types of keys added to a keytab by means of the kadmin(1M) ktadd command. The default is:
aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-hmac-sha1, arcfour-hmac-md5, des-cbc-md5, des-cbc-crc.
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 perform 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 particular 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 fol-
lowing 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.
max_lifetime =lifetime
Sets the requested maximum lifetime of the ticket. The values for lifetime follow the format described for the renew_lifetime option,
above.
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] section. 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 speci-
fied 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 map-
ping of a host, if this information is not already present in the krb5.conf file. Enabling this option might make the host vulnerable
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 [libdefaults] 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 principal. If undefined, the behavior is as if this option were set to true. Setting this value to false leaves the system vulner-
able 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 [libde-
faults] section to make it a network-wide setting for all realms.
[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.
The following relations may be found in the [appdefaults] section, though not all relations are recognized by all kerberized applications.
Some are specific to particular applications.
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 applications: 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. This option is obsolete and will be removed in a future release of the Solaris operating system.
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. This option is obsolete and will be removed in a future release of the Solaris operating system.
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 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.
auth_to_local_realm
For use in the default realm, non-default realms can be equated with the default realm for authenticated name-to-local name mapping.
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 indi-
cated 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.
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 principal. If undefined, the behavior is as if this option were set to true. Setting this value to false leaves the system vul-
nerable 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 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 spec-
ify 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
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 log-
ging 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 TimeFormats section in kinit(1) for the valid time duration for-
mats 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 sec-
tion 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 partici-
pate.
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
auth_to_local_realm = KRBDEV.ATHENA.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:
+-----------------------------+-----------------------------+
| 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.
The max_life and max_renewable_life options are obsolete and will be removed in a future release of the Solaris operating system.
SunOS 5.10 25 May 2004 krb5.conf(4)