Working with UAMS › Defining Users to the System

Defining Users to the System

There are different types of user ID that can be defined to your system:

• Individual user
• Model
• System console
• Background environments
  • Background process
  • System procedure

The following sections describe how to define each of these user IDs.

Security Planning

Note: This section only applies to CA SOLVE:FTS.

The transmission of a file from one location to another implies access to two data sets: the one being transmitted and the one into which the transmitted data set is being received. If those data sets are of a production nature, it is probable that the individual who requests the transmission is not allowed personal access to either of the data sets. By classifying a transmission definition as a system definition, CA SOLVE:FTS regards the access to the data sets as being access by CA SOLVE:FTS rather than as personal access by the user that issues the transmission request (such as when a user requests a private transmission).

Defining a User ID

Before anyone can access your region, they must be defined as an authorized user. A one- to eight-character user identifier (the user ID), together with a password, is used to associate an individual to the privileges and authorities allocated them. The password can be maintained by UAMS or by an external security system.

In addition to identifying an individual user of the system, the user ID also defines the following information about a user:

• Statistical information—personal information such as name, location, telephone number, as well as user ID expiry date and start times of last session.
• Control information—identifies the functions the user is allowed to perform and the features they can access when logged on to the system. This information determines, for example, whether a user is allowed to act as an OCS operator and if so, their authority level .

To define an individual user ID for a new user

1. Enter /UAMS at the command prompt.

   The UAMS : Primary Menu is displayed.

2. Type A at the Select Option prompt.
3. Type in the User Name.
4. Type USER in the Definition Type field and press Enter.

   The first of several panels of user ID definition details is displayed. These describe a user's access to various features.

   Note: You can associate a user with a group definition (for example, one of the groups generated when your region was installed). To associate a user with a group definition, simply enter the group name in the Group ID field on the first panel. Doing this means that the user inherits the privileges set in the group definition.

5. Type the required information on each following panel, scrolling forward (F8) to review the next panel.
6. Press F3 (File) to save the new user ID definition when all the panels have been reviewed and the required attributes specified.

   You are returned to the UAMS : Primary Menu.

   Note: If the user ID you are defining is similar to another ID, you can save time by copying an existing user ID to a new user you wish to add. Do this by selecting option L (List) to list the existing users, and then option C (Copy) to copy the user definition. UAMS retrieves the details for that user ID and then enters Add mode. You must now enter the new user ID name and change any fields required, before filing the new definition under the new name.

Maintaining User IDs

You can obtain a selection list of the user IDs defined to your system. The list allows you to browse, force a password, update, delete, or copy any of the listed user IDs. If you are not authorized for UAMS maintenance functions, only the browse function is allowed.

The following information is displayed about each user ID:

• Name
• Location
• Telephone number
• Type (Group or User definition)
• Access privileges

To maintain an existing user ID

1. Type L at the Select Option prompt on the UAMS : Primary Menu.
2. To obtain a partial listing, enter a prefix in the User field to list only those user IDs beginning with that prefix.
3. To display the command authority and access privileges information, press F11 (Right) twice.

Forcing a Password Change for a User ID

If a user forgets their password, you can allocate a new password using the Force User's Password Change facility.

To allocate a new password using the Force User's Password Change facility

1. Enter /UAMS at the command prompt.

   The UAMS : Primary Menu is displayed.

2. Type F at the Select Option prompt on the UAMS : Primary Menu, change the User field to the user ID you want to change the password for, and press Enter.

   The UAMS : User Details panel for the specified User ID is displayed.

3. Type the new password in the New Password field, and press Enter.

   The following message displays:

   PASSWORD VERIFICATION COMPLETE
   

4. Press F3 (File) to save the changes.

   When the user next logs on to the region, they are prompted to change the forced password. If a security exit is provided for password processing, this option can be suppressed by the exit.

Note: This function is not available from the special Install User ID.

Defining a Model User ID

Many installations have numerous users who access only one or two functions. Defining and maintaining system access for individual users requires considerable administrative effort. To minimize this effort, you can set up a model user ID so that users can automatically log on and register.

A model user ID is defined in the SYSPARMS MODLUSER operand. It has the following format:

SYSPARMS MODLUSER={ userid | NONE }

Note: For a detailed description of the MODLUSER operand, see the Reference Guide.

How It Works

If no security exit is in place and a model user ID is defined, a user who tries to log on with an undefined user ID, but using the password of the model user ID, causes the following to occur:

• The model user ID definition is read.
• A new user ID is created using the user ID specified during the logon request with the attributes of the model user ID.
• The new user ID is saved and flagged as a new user.
• The user ID creation is recorded on the log.
• Logon is allowed to proceed.
• The new user is prompted to change their password and fill in personal details (name, telephone, location, and so on) before the logon is complete.

Note: Creating new user IDs from model definitions is not suitable when defining high authority user IDs.

If no security exit is in place, and no model user ID has been defined, logon attempts from user IDs that are not defined are rejected.

If a model user ID has been specified in the SYSPARMS MODLUSER operand but has not been defined to UAMS, logon requests by undefined users will fail as if no model was defined.

If a security exit is in place, model user IDs work differently.

Defining a System Console User ID

The system console needs a special type of user ID. This is because:

• It only receives messages
• It has no full screen capabilities
• User logon is not possible

The system console user ID can be defined in the same manner as any other user ID, however, only fields that are applicable to message receipt are valid. For example, by defining the system console user ID as a monitor status OCS operator with PPO authority and an appropriate command authority, the system console can be profiled as a fully functional OCS operator console in the same manner as any other user ID.

The following sections describe how the system console user ID is created. See the section that applies to your operating environment.

Defining the System Console User ID in z/OS

The z/OS environment supports named consoles as well as extended MCS consoles, RACF signon, and security for consoles.

If necessary, the console user ID can be reproduced in UAMS so that a user who has limited authority cannot circumvent that authority by going to a console and issuing a MODIFY command.

Default OPER Environment

A default CONSOLE environment allows messages to be delivered to the operator. These messages are then delivered using the routing and descriptor codes set by the SYSPARMS ROUTCDE and DESC operands. This environment is built after INIT has finished.

The default terminal name for the system console environment is CONSOLE. The user ID for the console is automatically assigned using the following process:

1. The value of the SYSPARMS SYSCONUI operand is examined.
2. If no value is defined, it looks at the default—ppppOPER, where pppp is the system user prefix as defined in the NMSUP region JCL parameter.
3. If there is no definition for ppppOPER, the system assigns .DFLTOP as the user ID.

If .DFLTOP is used because no other value is defined, problems with ROF routing to other systems might result.

For more information about the SYSPARMS DESC, ROUTCDE, and SYSCONUI operands, see the Reference Guide.

Actual Console Environments

A system console environment is signed on the first time that a command is sent from the console to the system (for example, MODIFY).

The terminal name used is one of the following:

• The MVS console name if:
  • SYSPARMS SYSCONNM=ALL is in effect
  • It is an extended MVS console
• CONS#nn or CONS#nnn

The user ID depends on the values of the following SYSPARMS operands:

• SYSCONUI—sets the basic user ID. If this is not specified, it defaults to ppppOPER
• SYSCONSO—determines the search order for user IDs when a user attempts to sign on to the console

If SYSPARMS SYSCONXU=NO is in effect, the user ID is determined as shown in the following table, with one exception. The extended MCS consoles use the SYSCONUI user ID value as the logical user ID. This is because a user ID cannot be derived from the console ID.

When an attempt to log on to the system console is made, the system tries three times to assign a user ID to the system console. The outcome depends on the value of the SYSCONSO operand, as shown in the following table:

If SYSCONXU=YES is in effect, the user ID is determined by the values of the SYSPARMS SYSCONSO and SYSCONUI operands as follows:

• SYSCONUI—sets the basic user ID. If not specified, it defaults to ppppOPER.
• SYSCONSO—determines the search order for user IDs when a user attempts to sign on to the console

When an attempt to log on to the system console is made, the system tries three times to assign a user ID to the system console. The outcome depends on the value of the SYSCONSO operand. The following table describes this process:

The console is signed on by trying each attempt in turn until one succeeds.

For detailed information about the SYSPARMS SYSCONUI, SYSCONSO, SYSCONXU, and SYSCONNM operands, see the Reference Guide.

When a RACF user ID is signed on at the system console, there are two special cases, as follows:

• If a user is not signed on at the master console, RACF uses an internal name of *BYPASS*. This defaults to .MASTOP in this case.

  If .MASTOP is encountered, the signon always succeeds, with system assigned defaults.

• If the user is not signed on for other consoles, an internal user ID of .NOTSIGN is used.

  If .NOTSIGN is encountered, the signon of that user ID fails, leading to a try of the next user ID, and so on. If it is the last, the signon fails completely.

Receiving Command Replies on the System Console

All commands entered at the system console in an MVS system are treated as private to that console. The results of the commands entered are returned only to that console.

Defining the System Console User ID in z/VM Environments

The system console for a z/VM environment is created during system initialization. The logical terminal name is CONSOLE. The system console is used as a target to deliver messages to the operator.

The system console is automatically signed on during system initialization (after INIT has finished). The user ID for the console is automatically assigned using the following process:

1. The value of the SYSPARMS SYSCONUI operand is examined.
2. If no value is defined, it looks at the default—ppppOPER.
3. If there is no definition for ppppOPER, the system assigns .DFLTOP as the user ID.

If .DFLTOP is used because no other value is defined, problems with ROF routing to other systems might result.

Note: For detailed information about the SYSPARMS SYSCONUI operand, see the Reference Guide.

Note: z/VM environments do not support multiple operating system consoles.

Using ROF with System Consoles

System consoles can establish ROF sessions with remote domains.

If a user ID has been defined to UAMS for a specific console, then a corresponding user ID must be defined on every other domain to which the console user ID can establish a ROF connection.

If no specific console user ID has been defined and the console is operating with the same privileges as defined for the console user, the console user ID may establish ROF connections to any other domain without specific user ID definitions being required by the other domains. The console user ID uses the ROF attributes of the console user instead.

MSGPROC and System Console User IDs

The user ID environment for a system console can have a standard MSGPROC associated with it. MSGPROC processing is activated automatically during the console's signon.

Unsolicited Output to the System Console

To have the system console receive unsolicited messages, for example, PPO messages or Monitor class messages, direct them to a console user ID. The default system routing codes then determine which physical consoles receive the messages.

For example, if your region receives PPO messages and has no one to report them to, the messages are automatically sent to ppppOPER so that they will be seen on the system console. It is the system routing codes (as set by the SYSPARMS ROUTCDE operand) that then determine which consoles receive the messages.

You must ensure that the system console routing codes applying in your installation allows your region to route PPO messages successfully to the system console if no PPO authorized users are logged on as native users.

If at least one signed-on console is profiled as a PPO receiver, then messages are regarded as deliverable, and are not sent to the console user automatically.

Defining Background Environment User IDs

There are two types of background environments:

• Background processes, which include:
  • BMON—background monitor
  • BLOG—background logger
  • BSYS—background system process
• System procedures, which execute in special system-level environments logically signed on before the procedure starts; examples include:
  • LOGPROC
  • PPOPROC
  • AOMPROC
  • CNMPROC

Initialization User IDs

Each background environment is assigned a special user ID by the system at initialization. These user IDs are formed by using the system user prefix as defined in the NMSUP initialization parameter. For example, if your system has a system user prefix of NM01:

• The background environment user ID is defined as NM01BMON.
• The LOGPROC system procedure user ID is defined as NM01LOGP.

Note: Background environments cannot be canceled.

To see the names of these processes on your own system, enter a SHOW USERS command to list background environment users.

Initialization Privileges

When the system initializes, the background environment users are logically signed on. If a UAMS user ID is defined for a background environment, the attributes and privileges for it are determined from the user ID definition. If no user ID is defined, the system assigns the background environment with the following privileges:

• Time zone of the system
• Maximum command authority
• OCS authority

Note: UAMS background user ID definitions are created automatically when your product region starts for the first time.

Using ROF with Background Environments

Background environments can have ROF sessions with connected domains. Background environments must have their user IDs defined to all of the remote domains that they will log on to.

MSGPROC and Background Environment User IDs

Background environment user IDs can have standard MSGPROCs associated with them. To associate a MSGPROC with a background environment user ID, update the user ID in UAMS to include MSGPROC.