krb5.conf(4) krb5.conf(4)
NAME [Toc] [Back]
krb5.conf - Kerberos configuration file
DESCRIPTION [Toc] [Back]
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 braces, [ ]. 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. Given below is an example of
the INI-style format that is used by krb5.conf:
[section1]
tag1 = value_a
tag1 = value_b
tag2 = value_c
[section 2]
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. A
detailed explanation of these sections is provided in the following
sections.
[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.
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
[domain_realm] Contains relations which map subdomains and domain
names to Kerberos realm names. This is used by
programs to determine the realm a host should reside
in, based on 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 nonhierarchical
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
This relation 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 This relation identifies the default realm to be used
in a client host's Kerberos activity.
default_tgs_enctypes
This relation 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 whitespaces.
default_tkt_enctypes
This relation identifies the supported list of session
key encryption types that should be requested by the
client, in the same format.
clockskew This relation 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.
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.
Hewlett-Packard Company - 2 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
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
This relation 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
This relation 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 This relation 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.
appdefaults Section
Each tag in the [appdefaults] section names a Kerberos V5 application.
The value of the tag is a subsection with relations that define the
default behaviors for that application. For example:
[appdefaults]
kinit = {
forwardable = true
}
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 over-ridden 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.
Hewlett-Packard Company - 3 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
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 This relation identifies the host where the
administration server is running. Typically this is
the Master Kerberos server.
default_domain This relation 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
Hewlett-Packard Company - 4 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
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 are of the following forms:
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.
Hewlett-Packard Company - 5 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
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 the syslog(3C) manual page). 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, one 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; and 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.
Hewlett-Packard Company - 6 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
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 = {
Hewlett-Packard Company - 7 - HP-UX 11i Version 2: August 2003
krb5.conf(4) krb5.conf(4)
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 [Toc] [Back]
/etc/krb5.conf
Kerberos configuration file.
/usr/contrib/krb5/sample/krb5.conf.sample
A sample Kerberos configuration file shipped with this product.
AUTHOR [Toc] [Back]
krb5.conf was developed by the Massachusetts Institute of Technology.
SEE ALSO [Toc] [Back]
syslog(3C), kerberos(5).
Hewlett-Packard Company - 8 - HP-UX 11i Version 2: August 2003 [ Back ] |
