mode, users provide a login and password to gain access to the system. Users in this mode are restricted to commands
in command groups assigned both to their login and to the device. If no restrictions are placed on the device, user
restrictions still apply and command logging and reporting can still occur. This mode is not supported on the MCC or
SCC.
b.
Devices configured with just
user
authority checking (`u') enabled come up with the normal display (no login prompt). In
this mode, users are restricted to commands in command groups assigned to the device. If no restrictions are placed on
the device, command logging and reporting can still occur. This mode is identical to mode (4) with the exception that this
mode provides a user identity in the command logfile.
c.
Devices configured with both login and
terminal
authority checking (`t') enabled initially display the login prompt. In this
mode, users provide a login and password to gain access to the system. Then users are restricted to commands in
command groups assigned to the device. If no restrictions are placed on the device, command logging and reporting
can still occur. This mode is not supported on the MCC or SCC.
d.
Devices configured with just
terminal
authority checking (`t') enabled come up with the normal display (no login prompt).
Users in this mode are restricted to commands in command groups assigned to the device. If no restrictions are placed
on the device, command logging and reporting can still occur.
e.
Devices configured with login enabled but authority checking disabled (`n') come up displaying the login prompt. In this
mode, users provide a login and password to gain access to the system. This mode is not supported on the MCC or
SCC.
This mode is not recommended because login identities used to access the system are those defined with the admin
command (see Section 3.8.4.2 ). The same results can be achieved by creating the desired logins with ADD:PAUTH
and configuring login and terminal authority checking [mode (3)] without establishing terminal restrictions.
f.
Devices configured with neither login nor authority checking come up with the normal display (no login prompt) and with
no restrictions. This is the default configuration.
3.8.3.3 Command Logging and Reporting
In addition to restricting input requests, authority checking also provides the capability to log input requests in the
CMDLOG command logfile. CMDLOG entries may also be routed to and alarmed on devices in the PSSWD output
message class. Input request logging and reporting is configurable on a command group basis. This can be
customized through the Equipment Configuration Data base (ECD) authdef form for each command group.
Command logging allows both permitted and denied input requests to be recorded in the CMDLOG logfile. This
provides an audit trail of user activities. Each CMDLOG entry contains the date and time, the device where the
command was executed (if available), the login identity (if available), and the actual command. The input request
acknowledgment (e.g., "NG - INSUFFICIENT AUTHORITY") is included for rejected input requests. This logfile can
be accessed and searched using the
OP:LOG
input message.
Command reporting displays the same information described above at the desired alarm level on devices in the
PSSWD output message class. This can be used to draw attention to execution, or attempted execution, of
sensitive commands. Default PSSWD devices are the Receive Only Printer (ROP) and the Switching Control Center
(SCC) device.
3.8.3.4 ECD Authority Definition
The ECD Authority Definition (
authdef
) form defines CMDLOG logging and alarming parameters for a command
group. One authdef form exists for each command group. By modifying the authdef form for a command group, the
system administrator can control the command group's logging status (log or do not log) and alarm level of
REPT:CMDLOG
output messages for allowed and denied input requests.
235-105-210
October 1999
Copyright © 1999
Page 24
Summary of Contents for 5ESS-2000
Page 96: ...235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 184: ...235 105 210 October 1999 Copyright 1999 Page 3 ...
Page 300: ...13 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 55 ...
Page 339: ...7 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 13 ...
Page 342: ...235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 359: ...235 105 210 October 1999 Copyright 1999 Page 5 ...
Page 609: ...2 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 12 ...
Page 676: ...235 105 210 October 1999 Copyright 1999 Page 9 ...
Page 792: ...3 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 9 ...
Page 799: ...Figure 11 36 3 1 Cleaning Points 235 105 210 October 1999 Copyright 1999 Page 7 ...
Page 801: ...235 105 210 October 1999 Copyright 1999 Page 9 ...
Page 839: ...2 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 16 ...
Page 999: ...2 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 13 ...
Page 1008: ...Figure 11 55 1 CTSNS DIP Switch Settings 235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 1011: ...235 105 210 October 1999 Copyright 1999 Page 5 ...
Page 1053: ...235 105 210 October 1999 Copyright 1999 Page 15 ...
Page 1289: ...Figure 15 17 2 AMATPS Data Link 235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 1292: ...235 105 210 October 1999 Copyright 1999 Page 5 ...
Page 1303: ...9 STOP YOU HAVE COMPLETED THIS PROCEDURE 235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 1360: ...Figure 15 47 2 Typical SCANS III Link Diagram 235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 1372: ...235 105 210 October 1999 Copyright 1999 Page 2 ...
Page 1374: ...235 105 210 October 1999 Copyright 1999 Page 4 ...
Page 1421: ...Table 1 1 O M Checklist 235 105 210 October 1999 Copyright 1999 Page 3 ...