unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

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, includ-
       ing 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 sec-
       tions:

       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  Ker-
           beros 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 (nonhierarchi-
           cal) 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-ser-
           vice  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 com-
           mas 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 reau-
           thenticating.  This option may also be set in the [appdefaults]  or
           [realms]  section (see below) to limit its use in particular appli-
           cations or just to a specific realm.



       permitted_enctypes

           This relation controls the encryption types for session  keys  per-
           mitted 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 cre-
           ate 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 appli-
           cations 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 specified  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
           mapping of a host, if this information is not  already  present  in
           the  krb5.conf  file. Enabling this option might make the host vul-
           nerable to a redirection attack, wherein spoofed DNS  replies  per-
           suade  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 informa-
           tion 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
           vulnerable 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.



   [appdefaults]
       This  section  contains subsections for Kerberos V5 applications, where
       relation-subsection is the name of an application. Each subsection con-
       tains 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  applica-
           tion.



       encrypt = [true | false]

           Forces applications to use encryption by default (after authentica-
           tion) 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 follow-
           ing 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 grant-
           ing 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  [libde-
           faults]  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 speci-
       fied 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  (kad-
           mind) 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 [appde-
           faults] 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 map-
           ping.



       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 communi-
           cate  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
           vulnerable  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 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 speci-
           fications 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 speci-
           fied  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  stan-
           dard error stream.



       CONSOLE

           This  value  causes the entity's logging messages to go to the con-
           sole, 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 mes-
       sages. 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 TimeFormats 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 rota-
           tion  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 admin-
       istration 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  authentica-
       tion,  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 authentica-
       tion. The relations may be repeated if there is more than one  interme-
       diate  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  sys-
       tems 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 tran-
       sited 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:


       tab()    allbox;    cw(2.750000i)|     cw(2.750000i)     lw(2.750000i)|
       lw(2.750000i).  ATTRIBUTE TYPEATTRIBUTE VALUE Interface StabilityEvolv-
       ing


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)