The following sections describe exceptions to the rule that a user must enter a usercode to gain access to the system.
Continuous Log-On
If the Transaction Server station attribute “Continuous Log-On” is set, the station is automatically logged on when the system is restored after a halt/load. The station is logged on with the same usercode that was in use prior to the system interruption. Use the Station Activity screen available in the COMS Utility to enable the continuous log-on feature.
Because of the security risks involved, it is advisable to limit the Transaction Server continuous log-on feature to stations with a high degree of physical security. If security is a serious concern, do not use this feature.
Default Usercode
Use the Station Activity screen available in the COMS Utility to establish the default usercode for a station. If you specify a default usercode, the log-on screen is not displayed and the usercode is logged on.
Because of the security risks involved, it is advisable to limit the Transaction Server default usercode feature to stations with a high degree of physical security. If security is a serious concern, do not use this feature.
Some services can be configured to enable users to specify the station name for a connection. If you specify a default usercode for a station, you must ensure that users cannot specify that station name. There are two methods:
-
Custom Connect Facility (CCF)
You can restrict connections to Transaction Server by specifying the DYNAMIC attribute for the connection and defining the station in the COMS CFILE.
-
Telnetsupport (TELNET)
You can override a station name specified by a terminal emulator with the STATION_NAMES option (NA TELNET CONFIGURE STATION_NAME). Refer to the TCP/IP Distributed Systems Services Operations Guide for more information about the STATION_NAMES command. The following table shows the combinations of options that override a station name specified by a terminal emulator. The PSH option must be TRUE.
|
PREDICTABLE |
SHORTNAMES |
CONVERTIP |
DYNAMIC |
|---|---|---|---|
|
True |
False |
True |
- |
|
True |
False |
False |
- |
|
False |
False |
True |
- |
|
False |
False |
False |
- |
|
True |
True |
True |
2 |
|
True |
True |
False |
2 |
|
False |
True |
False |
2,7 |
|
False |
True |
True |
2,7 |
System Access Without a Usercode
A user action that has no usercode associated with it is known as a nonusercoded action. A process that has no usercode associated with its USERCODE task attribute is known as a nonusercoded process.
Nonusercoded actions and processes are initiated by
-
An operator display terminal (ODT) running in system command mode—the normal mode of ODT operation
Refer to Security Configuration for more information about modes of ODT operation.
-
A WFL job initiated from another host by an AT (At Remote Host) system command
-
A super user
-
A process that changes the value of its USERCODE task attribute to a period (.), which indicates no usercode
-
Any process initiated by a nonusercoded process that has no value assigned to its USERCODE task attribute
Types of Nonusercoded System Access
The following sections describe each of the preceding types of nonusercoded system access. Special security considerations that apply to sessions or processes that run without usercodes are also discussed.
Types of Nonusercoded System Access shows the types of nonusercoded system access.
Table 13. Types of Nonusercoded System Access
|
Access Type |
Characteristics |
|---|---|
|
Operator display terminals (ODTs) |
ODTs and remote ODTs Are exempt from log-on requirements. Give immediate system access without requiring the user to log-on. Make it difficult or impossible to attribute actions to an individual. Execute programs as nonusercoded processes. ODTs must be physically protected from unauthorized use. Refer to Controlling Access to the Physical System for more information. To limit system access from ODTs, use the system command RESTRICT (Set Restrictions). Refer to Controlling File Access for more information. |
|
Processes with USERCODE task attributes equal to a period (.) |
A process running under a privileged usercode can change the value of its USERCODE task attribute to a period (.). Such a process is then nonusercoded. |
|
Processes initiated by nonusercoded processes |
Any process initiated by a nonusercoded process is also nonusercoded. |
|
Super users |
Super-user status is A usercode security category Associated with a particular station Not associated with an individual usercode Use the COMS Utility Station Activity screen to designate a station as super-user-capable. At a super-user-capable station, any user can log-on to the system as a super user by entering an asterisk (*) in the usercode field. The asterisk (*) usercode is not privileged but has SYSTEMUSER status. The normal features of MARC are available to the user. A usercode and, optionally, a password are required to log-on to CANDE. System commands have the same privilege as commands entered from the ODT. Primitive system commands are not available. The actions of a user who is not logged on under a usercode might be difficult to monitor. Limit the Transaction Server super-user feature to stations with a high degree of physical security. On systems where security is a concern, do not use this feature. Use the security option NOSUPERUSER to disable super users. |
Cautions About Nonusercoded System Access
A session or process running without a usercode can pose the following special security problems:
-
Because no usercode is associated with the session or process, tracing security-related actions to a single user becomes difficult or even impossible.
-
Files created by a nonusercoded user or process are stored under the asterisk (*) node, indicating that they are files associated with no usercode, unless action is taken to store them under a usercode.
-
A user or process running without a usercode has privileged-like status for certain statements that act on files. This status extends to
-
The MARC command FILE
-
Single-statement WFL jobs started from an ODT that use the WFL statements CHANGE, COPY, ADD, REMOVE, SECURITY, and VOLUME
This status enables the nonusercoded user or process to use these statements on private files belonging to other users. For example, a nonusercoded user can copy another user's private file, or remove that file, or change it to a public file.
-
-
A nonusercoded process can effectively use the UNITNO file attribute to assign a file to a unit, even on systems with security enhancements that deny that ability to nonprivileged users and processes.
-
BNA Version 2 makes no security check of the authorization list and application group list for nonusercoded actions.
The abilities associated with nonusercoded users and processes are intended for operators and other trusted users who require them for maintaining libraries of files and archives.
