unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (HP-UX-11.11)
Page:
Section:
Apropos / Subsearch:
optional field



 krb5.conf(4)							krb5.conf(4)




 NAME
      krb5.conf - Kerberos configuration file

 DESCRIPTION
      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. 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.	Each
      of these sections will be explained in more details in the following
      sections.

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

      [login]	     Contains default values used by the Kerberos V5 login
		     program, login.krb5 (Note. Kerberized login program
		     will not be 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.

      [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



 Hewlett-Packard Company	    - 1 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




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

      kdc_req_checksum_type    This relation is used for compatibility with
			       DCE security servers which do not support the



 Hewlett-Packard Company	    - 2 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




			       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.

    login Section
      The [login] section is used to configure the behavior of the Kerberos
      V5 login program, login.krb5.

    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 = {



 Hewlett-Packard Company	    - 3 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




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



 Hewlett-Packard Company	    - 4 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




      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=<&lt&lt&lt;filename>&gt&gt&gt;

      FILE:<&lt&lt&lt;filename>&gt&gt&gt;
	   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=<&lt&lt&lt;devicename>&gt&gt&gt;
	   This causes the entity's logging messages to go to the specified
	   device.

      SYSLOG[:<&lt&lt&lt;severity>&gt&gt&gt;[:<&lt&lt&lt;facility>&gt&gt&gt;]]
	   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




 Hewlett-Packard Company	    - 5 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




	   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.

      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.



 Hewlett-Packard Company	    - 6 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




      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 = {
		NERSC.GOV = ES.NET
	   }
	   PNL.GOV = {
		NERSC.GOV = ES.NET
	   }
	   ES.NET = {
		NERSC.GOV = .
	   }
	   TEST.ANL.GOV = {
		NERSC.GOV = ANL.GOV



 Hewlett-Packard Company	    - 7 -   HP-UX Release 11i: November 2000






 krb5.conf(4)							krb5.conf(4)




		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
      /etc/krb5.conf
	   Kerberos configuration file

 AUTHOR
      krb5.conf was developed by the Massachusetts Institute of Technology.

 SEE ALSO
      kerberos(9), syslog(3C).


























 Hewlett-Packard Company	    - 8 -   HP-UX Release 11i: November 2000