Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for krb5.conf (redhat section 5)

KRB5.CONF(5)			       File Formats Manual			     KRB5.CONF(5)

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  Ker-
       beros 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  val-
       ues.  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).

       [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  log-
	      ging.

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

       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 KDC and in order  to  correct
	      for  an  inaccurate  system clock.  This corrective factor is only used by the Ker-
	      beros library.

       kdc_req_checksum_type
	      For compatability with DCE security servers which do not support the default CKSUM-
	      TYPE_RSA_MD5  used  by this version of Kerberos. Use a value of 2 to use the CKSUM-
	      TYPE_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 mes-
	      sages.  The default value for this type is CKSUMTYPE_RSA_MD5_DES.  For  compatibil-
	      ity 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.

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  rela-
       tions 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  par-
       ticular 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
			   }
			   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.

       admin_server
	      This relation identifies the host where the administration server is running.  Typ-
	      ically 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.

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] sec-
       tion:

		 [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  specifica-
	      tions 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/kad-
       min.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 interme-
       diate realm. A value of "." means that the two realms share keys directly, and no interme-
       diate 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 inter-
       mediate	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 Ker-
       berized	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)


All times are GMT -4. The time now is 02:54 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
UNIX.COM Login
Username:
Password:  
Show Password