The [libdefaults] Section

database_module

default_keytab_name

default_realm

default_tgs_enctypes

default_tkt_enctypes

clockskew

forwardable = [true | false]

permitted_enctypes

proxiable = [true | false]

renew_lifetime =lifetime

renew_lifetime = 90m

max_lifetime =lifetime

dns_lookup_kdc

dns_lookup_realm

dns_fallback

verify_ap_req_nofail [true | false]

The [appdefaults] Section

The following relations can 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]

encrypt = [true | false]

forward = [true | false]

forwardable = [true | false]

proxiable = [true | false]

renewable = [true | false]

no_addresses = [true | false]

max_life =lifetime

max_renewable_life =lifetime

rcmd_protocol = [ rcmdv1 | rcmdv2 ]

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 gets 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 specified in the [realms] section.

The [realms] Section

admin_server

application defaults

auth_to_local_realm

auth_to_local_names

auth_to_local

RULE:[<ncomps>:<format>](<regex>)s/<regex>/<text>/

"[" <ncomps> ":" <format> "]"

"(" <regex> ")"

<rule> ...

"s/" <regex> "/" <text> "/" ["g"]

database_module

extra_addresses...

kdc

kpasswd_server

kpasswd_protocol

udp_preference_limit

verify_ap_req_nofail [true | false]

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-Solaris-based Kerberos server. Otherwise, the change request is sent over RPCSEC_GSS to the Solaris Kerberos administration server.

The [domain_realm] Section

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 maps by default to the ATHENA.MIT.EDU realm, and all hosts in the fubar.org domain maps by default into the FUBAR.ORG realm. 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.

The [logging] Section

The following relations can be defined to specify how to log. The same relation can be repeated if you want to assign it multiple logging methods.

admin_server

default

kdc

The admin_server, default, and kdc relations can have the following values:

FILE:filename
FILE=filename

STDERR

CONSOLE

DEVICE=devicename

SYSLOG[:severity[:facility]]

The severity argument specifies the default severity of system log messages. This can 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 can 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 can be defined to specify how to rotate kdc log files if the FILE: value is being used to log:

kdc_rotate

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 can be specified for the kdc_rotate relation subsection:

period=delta_time

Specifying a time interval does not mean that the log files are 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

Notice that if versions is not specified or set to 0, only one log file is created, but it is overwritten whenever the time interval is met.

In the following example, the logging messages from the Kerberos administration daemon goes to the console. The logging messages from the KDC is appended to the /var/krb5/kdc.log, which is 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
   }

The [capaths] Section

A client uses this section to find the authentication path between its realm and the realm of the server. The server uses 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 can participate in the cross-realm authentication. The relations can be repeated if there is more than 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 is 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 needs to authenticate with. A server needs a subsection named for each realm of the clients it serves.

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 authenticates 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 relation is used more than once. The client uses this to determine the path. (It is not important to the server, since the transited field is not sorted.)

PKINIT-specific Options

The search order is:

The syntax for specifying Public Key identity, trust, and revocation information for pkinit is as follows:

pkinit_identities = URI

pkinit_anchors = URI

pkinit_pool = URI

pkinit_revoke = URI

pkinit_require_crl_checking = value

pkinit_dh_min_bits = value

pkinit_win2k = value

pkinit_win2k_require_binding = value

pkinit_eku_checking = value

pkinit_kdc_hostname = value

pkinit_cert_match = rule

[relation-operator]component-rule `...'

`<SUBJECT>'regular-expression
`<ISSUER>'regular-expression
`<SAN>'regular-expression
`<EKU>'extended-key-usage-list
               where extended-key-usage-list is a comma-separated list
               of required Extended Key Usage values.  All values in
               the list must be present in the certificate.
                    `pkinit'
                    `msScLogin'
                    `clientAuth'
                    `emailProtection'
`<KU>'key-usage-list
               where key-usage-list is a comma-separated list of
               required Key Usage values.  All values in the list must
               be present in the certificate.
                    `digitalSignature'

pkinit_cert_match = ||<SUBJECT>.*DoE.*<SAN>.*@EXAMPLE.COM
pkinit_cert_match = &&<EKU>msScLogin,clientAuth<ISSUER>.*DoE.*
pkinit_cert_match = <EKU>msScLogin,clientAuth<KU>digitalSignature

PKINIT URI Types

DIR:directory-name

PKCS12:pkcs12-file-name

PKCS11:[slotid=slot-id][:token=token-label][:cert id=cert-id][:certlabel=cert-label]

ENV:environment-variable-name

The [dbmodules] Section

db_library

db_module_dir

ldap_cert_path

ldap_conns_per_server

ldap_kadmind_dn

ldap_kdc_dn

ldap_servers

ldap://<ds hostname>:<SSL port>
ldap://<ds hostname>

ldap_service_password_file

ldap_ssl_port