|
|
HP-UX Reference > Kkrb5.conf(4)HP-UX 11i Version 2: December 2007 Update |
|
NAMEkrb5.conf — Kerberos configuration file DESCRIPTIONThe 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. Given below is an example of the INI-style format that is 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. A detailed explanation of these sections is provided in the following sections.
libdefaults SectionThe following relations are defined in the [libdefaults] section:
appdefaults SectionEach tag in the [appdefaults] section names a Kerberos V5 application. The value of the tag is a subsection with relations that define the default behaviors for that application. For example: [appdefaults] kinit = { forwardable = true } The list of specifiable options for each application may be found in the respective application man pages. The application defaults specified in this section are over-ridden by those specified in the [realms] section. login SectionThe [login] section is used to configure the behavior of the Kerberos V5 login program, login.krb5. realms SectionEach 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 = { mit = mit.edu lithium = lithium.lcs.mit.edu } } For each realm, the following tags may be specified in the realm's subsection:
domain_realm SectionThe [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. sage.lcs.mit.edu would be mapped to the LCS.MIT.EDU realm. logging SectionThe [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:
Values are of the following forms:
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
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 SectionCross-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. 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 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. |
|