SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG
DONATE


YUM REPOSITORY

 
 

MAN page from Fedora 11 krb5-libs-1.6.3-31.fc11.i586.rpm

KRB5.CONF

Section: File Formats (5)
Index 

NAME

krb5.conf - Kerberos configuration file 

DESCRIPTION

krb5.confcontains configuration information needed by the Kerberos V5 library.This includes information describing the default Kerberos realm, and thelocation of the Kerberos key distribution centers for known realms.

The krb5.conffile uses an INI-style format. Sections are delimited by square braces;within each section, there are relations where tags can be assigned tohave specific values. Tags can also contain a subsection, whichcontains further relations or subsections. A tag can be assigned tomultiple values. Here is an example of the INI-style format used bykrb5.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.conffile:

[libdefaults]
Contains various default values used by the Kerberos V5 library.

[login]
Contains default values used by the Kerberos V5 login program,login.krb5(8).

[appdefaults]
Contains default values that can be used by Kerberos V5 applications.

[realms]
Contains subsections keyed by Kerberos realm names which describe whereto find the Kerberos servers for a particular realm, and otherrealm-specific information.

[domain_realm]
Contains relations which map subdomains and domain names to Kerberosrealm names. This is used by programs to determine what realm a hostshould be in, given its fully qualified domain name.

[logging]
Contains relations which determine how Kerberos entities are to performtheir logging.

[capaths]
Contains the authentication paths used with non-hierarchicalcross-realm. Entries in the section are used by the client to determinethe intermediate realms which may be used in cross-realmauthentication. It is also used by the end-service when checking thetransited field for trusted intermediate realms.

[dbdefaults]
Contains default values for database specific parameters.

[dbmodules]
Contains database specific parameters used by the database library.

Each of these sections will be covered in more details in the followingsections. 

LIBDEFAULTS SECTION

The following relations are defined in the [libdefaults] section:

default_keytab_name
This relation specifies the default keytab name to be used byapplication severs such as telnetd and rlogind. The default is"/etc/krb5.keytab". This formerly defaulted to "/etc/v5srvtab", butwas changed to the current value.

default_realm
This relation identifies the default realm to be used in a client host'sKerberos activity.

default_tgs_enctypes
This relation identifies the supported list of session key encryptiontypes that should be returned by the KDC. The list may be delimited withcommas or whitespace.

default_tkt_enctypes
This relation identifies the supported list of session key encryptiontypes that should be requested by the client, in the same format.

permitted_enctypes
This relation identifies the permitted list of session key encryptiontypes.

clockskew
This relation sets the maximum allowable amount of clockskew in secondsthat the library will tolerate before assuming that a Kerberos messageis invalid. The default value is 300 seconds, or five minutes.

kdc_timesync
If the value of this relation is non-zero (the default), the librarywill compute the difference between the system clock and the timereturned by the KDC and in order to correct for an inaccurate systemclock. This corrective factor is only used by the Kerberos library.

kdc_req_checksum_type
For compatability with DCE security servers which do not support thedefault CKSUMTYPE_RSA_MD5 used by this version of Kerberos. Use a valueof 2 to use the CKSUMTYPE_RSA_MD4 instead. This applies to DCE 1.1 andearlier.

ap_req_checksum_type
This allows you to set the checksum type used in the authenticator ofKRB_AP_REQ messages. The default value for this type isCKSUMTYPE_RSA_MD5. For compatibility with applications linked againstDCE version 1.1 or earlier Kerberos libraries, use a value of 2 to usethe CKSUMTYPE_RSA_MD4instead.

safe_checksum_type
This allows you to set the preferred keyed-checksum type for use in KRB_SAFEmessages. The default value for this type is CKSUMTYPE_RSA_MD5_DES.For compatibility with applications linked against DCE version 1.1 orearlier Kerberoslibraries, use a value of 3 to use the CKSUMTYPE_RSA_MD4_DESinstead. This field is ignored when its value is incompatible withthe session key type.

preferred_preauth_types
This allows you to set the preferred preauthentication types which theclient will attempt before others which may be advertised by a KDC. Thedefault value for this setting is "17, 16, 15, 14", which forces libkrb5to attempt to use PKINIT if it is supported.

ccache_type
User this parameter on systems which are DCE clients, to specify thetype of cache to be created by kinit, or when forwarded tickets arereceived. DCE and Kerberos can share the cache, but some versions of DCEdo not support the default cache as created by this version ofKerberos. Use a value of 1 on DCE 1.0.3a systems, and a value of 2 onDCE 1.1 systems.

krb4_srvtab
Specifies the location of the Kerberos V4 srvtab file. Default is"/etc/srvtab".

krb4_config
Specifies the location of the Kerberos V4 configuration file. Defaultis "/etc/krb.conf".

krb4_realms
Specifies the location of the Kerberos V4 domain/realm translationfile. Default is "/etc/krb.realms".

dns_lookup_kdc
Indicate whether DNS SRV records shoud be used to locate the KDCs and other servers for a realm, if they are not listed in the information for the realm. The default is to use these records.

dns_lookup_realm
Indicate whether DNS TXT records should be used to determine the Kerberosrealm of a host. The default is not to use these records.

dns_fallback
General flag controlling the use of DNS for Kerberos information. If bothof the preceding options are specified, this option has no effect.

extra_addresses
This allows a computer to use multiple local addresses, in order toallow Kerberos to work in a network that uses NATs. The addresses shouldbe in a comma-separated list.

udp_preference_limit
When sending a message to the KDC, the library will try using TCPbefore UDP if the size of the message is above "udp_preference_limit".If the message is smaller than "udp_preference_limit", then UDP will betried before TCP. Regardless of the size, both protocols will betried if the first attempt fails.

verify_ap_req_nofail
If this flag is set, then an attempt to get initial credentials willfail if the client machine does not have a keytab. The default for theflag is false.

renew_lifetime
The value of this tag is the default renewable lifetime for initialtickets. 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 applicationor an option that is used by some Kerberos V5 application[s]. Thefour ways that you can set values for options are as follows, indecreasing order of precedence:

#1)             application = {                realm1 = {                        option = value                }                realm2 = {                        option = value                }        }#2)             application = {                option1 = value                option2 = value        }#3)             realm = {                option = value        }#4)             option = value

 

LOGIN SECTION

The [login] section is used to configure the behavior of the Kerberos V5login program,login.krb5(8).Refer to the manual entry forlogin.krb5for a description of the relations allowed in this section. 

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 thatsubsection define the properties of that particular realm. For example:

[realms]        ATHENA.MIT.EDU = {                admin_server = KERBEROS.MIT.EDU                default_domain = MIT.EDU                database_module = ldapconf                v4_instance_convert = {                        mit = mit.edu                        lithium = lithium.lcs.mit.edu                }                v4_realm = LCS.MIT.EDU        }

For each realm, the following tags may be specified in the realm'ssubsection:

kdc
The value of this relation is the name of a host running a KDC for thatrealm. An optional port number (preceded by a colon) may be appended tothe hostname. This tag should generally be used only if the realmadministrator has not made the information available through DNS.

admin_server
This relation identifies the host where the administration server isrunning. Typically this is the Master Kerberos server.

database_module
This relation indicates the name of the configuration section under dbmodulesfor database specific parameters used by the loadable database library.

default_domain
This relation identifies the default domain for which hosts in thisrealm are assumed to be in. This is needed for translating V4 principalnames (which do not contain a domain name) to V5 principal names (whichdo).

v4_instance_convert
This subsection allows the administrator to configure exceptions to thedefault_domain mapping rule. It contains V4 instances (the tag name)which should be translated to some specific hostname (the tag value) asthe second component in a Kerberos V5 principal name.

v4_realm
This relation is used by the krb524 library routines when converting a V5 principal name to a V4 principal name. It is used when V4 realmname and the V5 realm are not the same, but still share the same principal names and passwords. The tag value is the Kerberos V4 realm name.

auth_to_local_names
This subsection allows you to set explicit mappings from principalnames to local user names. The tag is the mapping name, and the valueis the corresponding local user name.

auth_to_local
This tag allows you to set a general rule for mapping principal namesto local user names. It will be used if there is not an explicitmapping for the principal name that is being translated. The possiblevalues are:

DB:<filename>The principal will be looked up in the database <filename>.Support for this is not currently compiled in by default.RULE:<exp>The local name will be formulated from <exp>.DEFAULTThe principal name will be used as the local name. If theprincipal has more than one component or is not in the defaultrealm, this rule is not applicable and the conversion will fail.

 

DOMAIN_REALM SECTION

The [domain_realm] section provides a translation from a hostname to theKerberos realm name for the services provided by that host.

The tag name can be a hostname, or a domain name, where domain names areindicated by a prefix of a period ('.') character. The value of therelation 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 bethe hostname's domain portion converted to upper case. For example, thefollowing [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 inthe MIT.EDU domain to the ATHENA.MIT.EDU realm, and all hosts in theUCSC.EDU domain into the CATS.UCSC.EDU realm. ucbvax.berkeley.edu wouldbe mapped by the default rules to the BERKELEY.EDU realm, whilesage.lcs.mit.edu would be mapped to the LCS.MIT.EDU realm.

 

LOGGING SECTION

The [logging] section indicates how a particular entity is to performits logging. The relations specified in this section assign one or morevalues to the entity name.

Currently, the following entities are used:

kdc
These entries specify how the KDC 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 explicitspecifications otherwise.

Values are of the following forms:

FILE=<filename>
FILE:<filename>
This value causes the entity's logging messages to go to the specifiedfile. If the=form is used, then the file is overwritten. Otherwise, the file isappended to.
STDERR
This value causes the entity's logging messages to go to its standarderror stream.
CONSOLE
This value causes the entity's logging messages to go to the console, ifthe 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.

Theseverityargument specifies the default severity of system log messages. Thismay be any of the following severities supported by thesyslog(3)call minus the LOG_ prefix: LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR,LOG_WARNING, LOG_NOTICE, LOG_INFO, and LOG_DEBUG. For example, tospecify LOG_CRIT severity, one would use CRIT forseverity.

Thefacilityargument specifies the facility under which the messages are logged.This may be any of the following facilities supported by thesyslog(3)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 throughLOG_LOCAL7.

If noseverityis specified, the default is ERR, and if nofacilityis specified, the default is AUTH.

In the following example, the logging messages from the KDC will go tothe console and to the system log under the facility LOG_DAEMON withdefault severity of LOG_INFO; and the logging messages from theadministrative server will be appended to the file /var/adm/kadmin.logand 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. Thishierarchy is based on the name of the realm, which thus imposesrestrictions on the choice of realm names, and on who may participate ina cross-realm authentication. A non hierarchical orgization may be used,but requires a database to construct the authentication paths betweenthe realms. This section defines that database.

A client will use this section to find the authentication path betweenits realm and the realm of the server. The server will use this sectionto verify the authentication path used be the client, by checking thetransited field of the received ticket.

There is a tag name for each participating realm, and each tag hassubtags for each of the realms. The value of the subtags is anintermediate realm which may participate in the cross-realmauthentication. The subtags may be repeated if there is more then oneintermediate realm. A value of "." means that the two realms share keysdirectly, and no intermediate realms should be allowed to participate.

There are n**2 possible entries in this table, but only those entrieswhich will be needed on the client or the server need to be present. Theclient needs a tag for its local realm, with subtags for all the realmsof servers it will need to authenticate with. A server needs a tag foreach realm of the clients it will serve.

For example, ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NETrealm as an intermediate realm. ANL has a sub realm of TEST.ANL.GOVwhich 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 systemswould 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 thesame subtag name is used more then once. The client will use this todeterming the path. (It is not important to the server, since thetransited field is not sorted.)

If this section is not present, or if the client or server cannot find aclient/server path, then normal hierarchical orginization is assumed.

This feature is not currently supported by DCE. DCE security servers canbe used with Kerberized clients and servers, but versions prior to DCE1.1 did not fill in the transited field, and should be used withcaution.

 

DATABASE DEFAULT SECTION

The [dbdefaults] section indicates default values for the database specific parameters.It can also specify the configuration section under dbmodules for databasespecific parameters used by the loadable database library.

The following tags are used in this section:

database_module
This relation indicates the name of the configuration section under dbmodulesfor database specific parameters used by the loadable database library.

ldap_kerberos_container_dn
This LDAP specific tag indicates the DN of the container object where the realmobjects will be located. This value is used if no object DN is mentioned in theconfiguration section under dbmodules.

ldap_kdc_dn
This LDAP specific tag indicates the default bind DN for the KDC server.The KDC server does a login to the directory as this object. This value is used ifno object DN is mentioned in the configuration section under dbmodules.

ldap_kadmind_dn
This LDAP specific tag indicates the default bind DN for theAdministration server. The Administration server does a login to the directoryas this object. This value is used if no object DN is mentioned inthe configuration section under dbmodules.

ldap_service_password_file
This LDAP specific tag indicates the file containing the stashed passwords for theobjects used for starting the Kerberos servers. This value is used if noservice password file is mentioned in the configuration section under dbmodules.

ldap_servers
This LDAP specific tag indicates the list of LDAP servers. The list of LDAP serversis whitespace-separated. The LDAP server is specified by a LDAP URI.This value is used if no LDAP servers are mentioned in the configurationsection under dbmodules.

ldap_conns_per_server
This LDAP specific tag indicates the number of connections to be maintained perLDAP server. This value is used if the number of connections per LDAP server are not mentioned in the configuration section under dbmodules. The default value is 5.

 

DATABASE MODULE SECTION

Each tag in the [dbmodules] section of the file names a configuration sectionfor database specific parameters that can be referred to by a realm. The value of the tag is a subsection where the relations in that subsectiondefine the database specific parameters.

For each section, the following tags may be specified in the subsection:

db_library
This tag indicates the name of the loadable database library.The value should be db2 for db2 database and kldap for LDAP database.

ldap_kerberos_container_dn
This LDAP specific tag indicates the DN of the container object where the realmobjects will be located.

ldap_kdc_dn
This LDAP specific tag indicates the bind DN for the KDC server.The KDC does a login to the directory as this object.

ldap_kadmind_dn
This LDAP specific tag indicates the bind DN for the Administration server.The Administration server does a login to the directoryas this object.

ldap_service_password_file
This LDAP specific tag indicates the file containing the stashed passwords for theobjects used for starting the Kerberos servers.

ldap_servers
This LDAP specific tag indicates the list of LDAP servers. The list of LDAP serversis whitespace-separated. The LDAP server is specified by a LDAP URI.

ldap_conns_per_server
This LDAP specific tag indicates the number of connections to be maintained perLDAP server.
 

FILES

/etc/krb5.conf 

SEE ALSO

syslog(3)


 

Index

NAME
DESCRIPTION
LIBDEFAULTS SECTION
APPDEFAULTS SECTION
LOGIN SECTION
REALMS SECTION
DOMAIN_REALM SECTION
LOGGING SECTION
CAPATHS SECTION
DATABASE DEFAULT SECTION
DATABASE MODULE SECTION
FILES
SEE ALSO

This document was created byman2html,using the manual pages.