krb5.conf man page on SuSE

Man page or keyword search:  
man Server   14857 pages
apropos Keyword Search (all sections)
Output format
SuSE logo
[printable version]

KRB5.CONF(5)							  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 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  subsec‐
       tion,  which  contains  further relations or subsections.  A tag can be
       assigned to multiple values.  Here is an example of the INI-style  for‐
       mat 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 applica‐
	      tions.

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

       [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 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 authentica‐
	      tor  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 CKSUM‐
	      TYPE_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.

       preferred_preauth_types
	      This allows you to set  the  preferred  preauthentication	 types
	      which  the client will attempt before others which may be adver‐
	      tised by a KDC.  The default value for this setting is "17,  16,
	      15,  14", which forces libkrb5 to attempt to use PKINIT if it is
	      supported.

       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 sys‐
	      tems, 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 the Kerberos  V4  configuration	 file.
	      Default is "/etc/krb.conf".

       krb4_realms
	      Specifies	 the location of the Kerberos V4 domain/realm transla‐
	      tion 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 informa‐
	      tion.  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_prefer‐
	      ence_limit".   If	 the  message  is  smaller  than  "udp_prefer‐
	      ence_limit", 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 ini‐
	      tial 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 forward‐
	      able.  The default value for this flag is false.

       proxiable
	      If  this	flag is set, initial tickets by default will be proxi‐
	      able.  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  sub‐
       section 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's sub‐
       section:

       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 informa‐
	      tion available through DNS.

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

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

       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 host‐
	      name (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 con‐
	      verting 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 princi‐
	      pal 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 trans‐
	      lated.  The possible values are:

		   DB:<filename>
			The principal will be looked up in the database <file‐
			name>.	 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 per‐
	      form 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	 over‐
	      written.	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  sup‐
	      ported  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 facili‐
	      ties 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 admin‐
       istrative 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 sub‐
       tags for each of the realms. The value of the subtags is an  intermedi‐
       ate  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 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  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 tran‐
       sited 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.

DATABASE DEFAULT SECTION
       The [dbdefaults] section indicates default values for the database spe‐
       cific parameters.  It can also specify the configuration section	 under
       dbmodules  for  database specific parameters used by the loadable data‐
       base library.

       The following tags are used in this section:

       database_module
	      This relation indicates the name of  the	configuration  section
	      under  dbmodules	for  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  realm objects will be located. This value is used if
	      no object DN is mentioned in  the	 configuration	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 if no object DN is mentioned in the
	      configuration section under dbmodules.

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

       ldap_service_password_file
	      This LDAP specific tag indicates the file containing the stashed
	      passwords	 for  the  objects  used  for  starting	 the  Kerberos
	      servers.	This value is used if no service password file is men‐
	      tioned in the configuration section under dbmodules.

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

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

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

       For  each  section,  the following tags may be specified in the subsec‐
       tion:

       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 realm objects 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 Administra‐
	      tion  server.   The  Administration  server  does a login to the
	      directory as this object.

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

       ldap_servers
	      This LDAP specific tag indicates the list of LDAP	 servers.  The
	      list of LDAP servers is 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 per LDAP server.

FILES
       /etc/krb5.conf

SEE ALSO
       syslog(3)

								  KRB5.CONF(5)
[top]

List of man pages available for SuSE

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net