[realms]

Each tag in the [realms] section of the file is the name of a Kerberos realm. The value of the tag is a subsection with relations that define the properties of that particular realm. For each realm, the following tags may be specified in the realm's 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. For your computer to be able to communicate with the KDC for each realm, this tag must be given a value in each realm subsection in the configuration file, or there must be DNS SRV records specifying the KDCs (see Using DNS).

master_kdc

Identifies the master KDC(s). Currently, this tag is used in only one case: If an attempt to get credentials fails because of an invalid password, the client software will attempt to contact the master KDC, in case the user's password has just been changed, and the updated database has not been propagated to the slave servers yet. (We don't currently check whether the KDC from which the initial response came is on the master KDC list. That may be fixed in the future.)

admin_server

Identifies the host where the administration server is running. Typically, this is the master Kerberos server. This tag must be given a value in order to communicate with the kadmin server for the realm.

default_domain

This tag is used for Kerberos 4 compatibility. Kerberos 4 does not require the entire hostname of a server to be in its principal like Kerberos 5 does. This tag provides the domain name needed to produce a full hostname when translating V4 principal names into V5 principal names. All servers in this realm are assumed to be in the domain given as the value of this tag

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 the V4 realm name and the V5 realm name 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.

The format for exp is [n:$d..string](regexp)s/pattern/replacement/g. The integer n indicates how many components the target principal should have. If this matches, then a string will be formed by putting together the components of the principal in the order indicated by each integer d, and the arbitrary string string (i.e. if the principal was johndoe/admin then [2:$2$1foo] would result in the string "adminjohndoefoo". If this string matches regexp, then the s//[g] substitution command will be run over the string. The optional g will cause the substitution to be global over the string, instead of replacing only the first match in the string.

DEFAULT

The principal name will be used as the local user 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.

For example:

          [realms]
              ATHENA.MIT.EDU = {
                  auth_to_local = {
                      RULE:[2:$1](johndoe)s/^.*$/guest/
                      RULE:[2:$1;$2](^.*;admin$)s/;admin$//
                      RULE:[2:$2](^.*;root)s/^.*$/root/
                      DEFAULT
                      }
                  }
          

would result in any principal without root or admin as the second component to be translated with the default rule. A principal with a second component of admin will become its first component. root will be used as the local name for any principal with a second component of root. The exception to these two rules are any principals johndoe/*, which will always get the local name guest.