HP-UX Reference (11i v2 04/09) - 4 File Formats (vol 8)

k
krb5.conf(4) krb5.conf(4)
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 mentioned below supported by the syslog()
call (see the syslog (3C) manual page).
The supported arguments are
LOG_ALERT LOG_CRIT LOG_DEBUG LOG_ERR
LOG_EMERG LOG_INFO LOG_NOTICE LOG_WARNING
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.Ifnofacility 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 log-
ging 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 Section
Cross-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 con-
struct 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 intermedi-
ate 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 = {
HP-UX 11i Version 2: September 2004 − 4 − Hewlett-Packard Company Section 4−−155