NIO CommKit Host Interface Installation and System Administration Manual

AUTHORIZE(1M) AUTHORIZE(1M)
E-18 CommKit Host Interface, Release 4.0
Multiple Interfaces
The CommKit Host Interface software supports multiple interface boards, allowing connectivity to multiple
data switch networks or redundant connectivity to a single network. Each command that initiates connections
through the network will use the default processing [see dkdial(3X)] to select the interface for the call. If the
interfaces reside in different data switch Originating Groups, an authorization made from one interface will
not be valid for calls established through one of the other interfaces. Users must explicitly authorize through
each interface or must restrict their connections to a single outgoing interface.
Every command that establishes connections allows the user to restrict the connection to a specific interface
by setting the DKINTF environment variable to the desired interface number.
For example, on a host with two interfaces connected to the same data switch, a user can authorize from the
originating machine to the destination machine through both interfaces with the following two commands:
DKINTF=0 dk destination.authorize
DKINTF=1 dk destination.authorize
The DKINTF variable may be set and exported in the .profile file or by shell scripts if the interface preference
is required across several connection attempts.
Log File
The authorize command creates and maintains a log file (owned by root with mode 0600) of all authorization
attempts, whether they were successful or unsuccessful. This log is kept in the file /var/opt/dk/log/dkuidlog
and will grow without bound unless it is periodically cleaned by the administrator.
The format of the authorization log file is very similar to the format used by su(1). The fields contained in the
log are: the string ’DK’, the date and time of the attempted authorization, a status flag that indicates the
outcome of the attempt, the Originating Group of the requester, the numeric user ID of the requester (with a
’/dkkey_value’ appended if there was a DKKEY included in the request), and finally, the login name
requested in the attempt.
The status flag will be one of four possible values:
+ The requester supplied a correct login/password combination and was granted an authorization.
E The requester supplied a correct login/password combination but was denied authorization because the
password had expired.
0 The requester supplied a correct login/password combination but was denied authorization because the
requested login had a user ID of zero (authorizations may not take place to super-user logins).
– The requester supplied an incorrect login/password combination and was denied authorization.
Here are several sample authorization log entries:
DK 10/20 15:50 – nj/jail/hacker 100–guest
DK 10/20 15:50 – nj/jail/hacker 100/dkey–sys
DK 10/20 15:50 0 nj/jail/hacker 0–root
DK 10/20 15:54 – nj/jail/warden 11221–fake
DK 10/20 15:54 – nj/jail/warden 11221–fake
DK 10/20 15:58 E nj/jail/warden 11221–fake
DK 10/20 16:00 + nj/jail/warden 11221–fake
DK 10/20 16:36 + nj/wecare/support 0–guest