Provided by: krb5-doc_1.4.3-5_all bug

NAME

       krb5.conf - Kerberos configuration file

DESCRIPTION

       krb5.conf  contains configuration 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 to 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

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

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

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

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",
              but was changed to the current value.

       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  KDC.  The  list
              may be delimited with commas or whitespace.

       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.

       permitted_enctypes
              This  relation  identifies  the  permitted  list  of session key
              encryption types.

       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 default), the
              library will compute the difference between the system clock and
              the  time  returned  by  the  KDC and in order to correct for an
              inaccurate system clock.  This corrective factor is only used by
              the Kerberos library.

       kdc_req_checksum_type
              For compatability 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  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 version 1.1 or earlier Kerberos
              libraries, use  a  value  of  2  to  use  the  CKSUMTYPE_RSA_MD4
              instead.

       safe_checksum_type
              This allows you to set the preferred keyed-checksum type for use
              in KRB_SAFE messages.   The  default  value  for  this  type  is
              CKSUMTYPE_RSA_MD5_DES.    For  compatibility  with  applications
              linked against DCE version 1.1 or  earlier  Kerberos  libraries,
              use a value of 3 to use the CKSUMTYPE_RSA_MD4_DES instead.  This
              field is ignored when its value is incompatible with the session
              key type.

       ccache_type
              User this parameter 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 a value of 2 on DCE 1.1 systems.

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

       krb4_config
              Specifies  the  location  of hte Kerberos V4 configuration file.
              Default is "/etc/krb.conf".

       krb4_realms
              Specifies  the  location  of  the   Kerberos   V4   domain/realm
              translation file.  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
              Kerberos  realm  of  a  host.   The  default is not to use these
              records.

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

       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 KDC, the library  will  try  using
              TCP   before   UDP   if   the  size  of  the  message  is  above
              "udp_preference_list".   If  the   message   is   smaller   than
              "udp_preference_list",  then  UDP  will  be  tried  before  TCP.
              Regardless of the size, both protocols  will  be  tried  if  the
              first attempt fails.

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

       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 four
       ways  that you can 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

LOGIN SECTION

       The [login] section is used to configure the behavior of  the  Kerberos
       V5  login  program,  login.krb5(8).   Refer  to  the  manual  entry for
       login.krb5 for 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  that
       subsection  define  the  properties  of  that  particular  realm.   For
       example:

                 [realms]
                      ATHENA.MIT.EDU = {
                           admin_server = KERBEROS.MIT.EDU
                           default_domain = MIT.EDU
                           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’s
       subsection:

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

       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 which hosts in
              this realm are assumed to be in.  This is needed for translating
              V4  principal  names  (which do not contain a domain name) to V5
              principal names (which do).

       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) as the 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 realm name 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
              principal  names  to  local  user names.  The tag is the mapping
              name, and the value is the corresponding local user name.

       auth_to_local
              This tag allows you to set a general rule for mapping  principal
              names  to  local user names.  It will be used if there is not an
              explicit  mapping  for  the  principal  name   that   is   being
              translated.  The possible values 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>.
                   DEFAULT
                        The principal name will be used as the local name.  If
                        the principal has more than one component or is not in
                        the default realm, this rule is not applicable and the
                        conversion will fail.

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

       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(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,  to  specify
              LOG_CRIT severity, one would use CRIT for 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(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 through
              LOG_LOCAL7.

              If no severity is specified, the  default  is  ERR,  and  if  no
              facility is specified, the default is AUTH.

       In  the following example, the logging messages from the KDC 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,  which  thus  imposes
       restrictions  on  the choice of realm names, and on who may participate
       in a cross-realm authentication. A non hierarchical orgization  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 be the client, by  checking  the
       transited field of the received ticket.

       There  is  a  tag  name  for each participating realm, and 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 [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 subtag name is used more then once. The client will  use  this  to
       determing  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 orginization 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

SEE ALSO

       syslog(3)

                                                                  KRB5.CONF(5)