CA-ACF2 VM interface: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
Line 249: Line 249:


<ul>
<ul>
<li>User logins  
  <li>User logins  


<ul>
    <ul>
<li>LOGIN/LOGON command </li>
    <li>LOGIN/LOGON command </li>
<li>IFSTRT function </li>
    <li>IFSTRT function </li>
<li>IFLOG function </li>
    <li>IFLOG function </li>
</ul>
    </ul>


</li>
  </li>


<li>User logouts  
  <li>User logouts  


<ul>
    <ul>
<li>LOGOUT/LOGOFF command </li>
    <li>LOGOUT/LOGOFF command </li>
<li>IFFNSH/IFDTHRD function </li>
    <li>IFFNSH/IFDTHRD function </li>
</ul>
    </ul>
</li>
  </li>


<li>Model 204 user resources  
  <li>Model 204 user resources  


<ul>
    <ul>
<li>Job submission (USE $JOB command)</li>
    <li>Job submission (USE $JOB command)</li>


<li>Dynamic allocation of new DASD space (ALLOCATE command)</li>
    <li>Dynamic allocation of new DASD space (ALLOCATE command)</li>


<li>All sequential file and VSAM file opens for READ/WRITE access</li>
    <li>All sequential file and VSAM file opens for READ/WRITE access</li>


<li>Sequential data set handling (Record I/O)</li>
    <li>Sequential data set handling (Record I/O)</li>


<li>DUMP/RESTORE commands</li>
    <li>DUMP/RESTORE commands</li>


<li>OPEN command naming a deferred update data set</li>
    <li>OPEN command naming a deferred update data set</li>
</ul>
    </ul>
</li>
  </li>
</ul>
</ul>


Line 302: Line 302:


<ul>
<ul>
<li>
  <li>
If the SECURID argument is defined as the CMS Logonid of the security service machine, ACF2CMS requests are made from the security service machine.  
If the SECURID argument is defined as the CMS Logonid of the security service machine, ACF2CMS requests are made from the security service machine.  
</li>
  </li>


<li>
  <li>
If the CA-ACF2 SECURID argument is left blank, CA-ACF2 requests are made from the Online (or IFAM1).  
If the CA-ACF2 SECURID argument is left blank, CA-ACF2 requests are made from the Online (or IFAM1).  
</li>
  </li>
</ul>
</ul>


Line 316: Line 316:


<ul>
<ul>
<li>
  <li>LOGON or LOGIN</li>
LOGON or LOGIN  
</li>


<li>
  <li>IFSTRT function</li>
IFSTRT function  
</li>


<li>
  <li>IFLOG function within IFAM1</li>
IFLOG function within IFAM1  
</li>
</ul>
</ul>
   
   
Line 353: Line 347:


<ul>
<ul>
<li>
  <li>User ID that identifies you to Model 204  
User ID that identifies you to Model 204  
  </li>
</li>


<li>
  <li>Password that provides access to the system  
Password that provides access to the system  
  </li>
</li>


<li>
  <li>User privileges associated with your user ID and password to define the particular type of access that you have </li>
User privileges associated with your user ID and password to define the particular type of access that you have  
</li>


<li>
  <li>Default priority class assigned to your user ID  
Default priority class assigned to your user ID  
  </li>
</li>
</ul>
</ul>


Line 381: Line 370:


<ul>
<ul>
<li>
  <li>Provide a default account value when you do not specify an account on the LOGON/LOGIN command. In this case, the account is supplied from the CA-ACF2 user Logonid record.  
Provide a default account value when you do not specify an account on the LOGON/LOGIN command. In this case, the account is supplied from the CA-ACF2 user Logonid record.  
  </li>
</li>


<li>
  <li>Provide account validation if you do specify an account value on the LOGON/LOGIN command.  
Provide account validation if you do specify an account value on the LOGON/LOGIN command.  
  </li>
</li>
</ul>
</ul>


Line 488: Line 475:


<ul>
<ul>
<li>Code a LOGIN command with no user ID or password (recommended approach).  
  <li>Code a LOGIN command with no user ID or password (recommended approach).  


<p>For example: </p>
  <p>For example: </p>


<p class="code"><nowiki>PGSIZE=6184  
  <p class="code"><nowiki>PGSIZE=6184  
  . . .  
    . . .  
IODEV=41,POLLNO=10  
  IODEV=41,POLLNO=10  
LOGIN  
  LOGIN  
BROADCAST...  
  BROADCAST...  
  . . .  
    . . .  
</nowiki></p>
  </nowiki></p>


<p>Model 204 logs in User 0 as a CA-ACF2 user by appending the Logonid of the MODEL204 machine to the LOGIN command as the user ID. No password is required. </p>
  <p>Model 204 logs in User 0 as a CA-ACF2 user by appending the Logonid of the MODEL204 machine to the LOGIN command as the user ID. No password is required. </p>
</li>
  </li>


<li><p>Use a CCASTAT user ID and password: </p>
  <li><p>Use a CCASTAT user ID and password: </p>


<p class="syntax">LOGIN <span class="term">userid</span> [<span class="term">account</span>]  
  <p class="syntax">LOGIN <span class="term">userid</span> [<span class="term">account</span>]  
<span class="term">password</span>  
  <span class="term">password</span>  
</p>
  </p>
</li>
  </li>


<li><p>Enter the Logonid of the MODEL204 machine on the LOGIN command without a password </p>
<li><p>Enter the Logonid of the MODEL204 machine on the LOGIN command without a password </p>

Revision as of 00:21, 5 December 2014

Overview

This topic presents an overview of the Model 204 CA-ACF2 VM Interface and how it affects the Model 204 user, system manager, and CA-ACF2 installation security officer.

CA-ACF2 VM

CA-ACF2 VM is an extension of the IBM VM/CMS environment that provides comprehensive data security functions. CA-ACF2 VM protects all data (or installation-defined resources) by default; that is, it protects all resources from all users unless specifically allowed by the resource owner or a security officer. This differs from other security systems that force you to define what is to be protected, rather than what is to be shared.

Model 204 CA-ACF2 VM interface

The Model 204 CA-ACF2 VM Interface provides for an orderly migration from Model 204 security to CA-ACF2 security and allows you to use either or both security methods. The Interface provides the tools and instructions necessary to:

  • Define a security service machine to issue all CA-ACF2 validation requests or to require the MODEL204 service machine to issue CA-ACF2 requests online
  • Make the changes required to the ACFFDR and reload the ACFFDR
  • Define the CA-ACF2 Logonid privileges required by the security service machine or the Model 204 service machine or both
  • Specify CA-ACF2 VM Interface parameters in the ACF2GEN macro and create ACF2PARM
  • Define CA-ACF2 Generalized Resource Rules to control access to ACF2PARM parameter sets defined by one or more ACF2GEN macros
  • Define CA-ACF2 Generalized Resource Rules so CA-ACF2 can authorize Model 204 user privileges
  • Define a CA-ACF2 Generalized Resource Rule to control system entry to Model 204
  • Define an installation default user priority class, or a priority class field within a CA-ACF2 Logonid record
  • Define a default user account within a CA-ACF2 Logonid record, and provide account authorization services
  • Define a record security key field within the CA-ACF2 Logonid record; define source entry rules to enforce terminal security
  • Migrate CCASTAT users to CA-ACF2 or force all users to log in through CA-ACF2
  • Automatically log in CCASTAT and CA-ACF2 users without requiring a password or require all users to enter passwords at all times (optional)

In summary, the CA-ACF2 VM Interface enables you to implement CA-ACF2 LOGIN and LOGOUT security, to validate account, Model 204 user, and Model 204 execution privileges, and to set user priorities and record security keys.

CA-ACF2 VM Interface configurations

Two configurations are allowed for the CA-ACF2 VM Interface:

Configuration Description
Inline validation Validates all CA-ACF2 information via a security service machine
Service machine validation Performs validation inline within the MODEL204 machine

These configurations are interchangeable; either or both can be used at the same site simultaneously in different virtual machines.

Inline validation

CA-ACF2 requests are synchronous. If CA-ACF2 requests are made inline from the Model 204 machine, whenever any user requires CA-ACF2 validation, everyone on that machine waits for the validation to finish.

In a batch or single-user environment, inline validation does not affect performance. But in a multiuser Online, a CA-ACF2 request by one user forces all other users to wait until the request has been processed.

Service machine validation

If CA-ACF2 requests are made through a security service machine, the security service machine issues the CA-ACF2 requests and sends the results back to Model 204. Using a security service machine is usually faster; only the user who requires CA-ACF2 validation is kept waiting.

Another advantage to using a security service machine, besides speed in a multiuser environment, is that only the security service machine needs special CA-ACF2 privileges. That is, if multiple Onlines execute in more than one machine rather than each machine having its own set of CA-ACF2 VM SRF and ACCOUNT privileges, all CA-ACF2 special privileges can reside on one virtual machine.

One possible configuration is to have multiuser Onlines off-load CA-ACF2 requests to the security service machine while batch, single-user, and IFAM1 users issue CA-ACF2 requests directly from the Online. This prevents multiuser users from having to wait while giving single users the fastest possible validation.

The following figure illustrates the CA-ACF2 VM Interface using the security service machine.

CA-ACF2 AM Interface using a security service machine

The CA-ACF2 VM Interface using the security service machine consists of the following components:

Component Notes
Model 204 Communicates with the security service machine via IUCV
ACF2PARM Is loaded dynamically at initialization by Model 204
ACF2CMS text deck Contains the CA-ACF2 VM Interface object code and invokes the System Request Facility (SRF)
CCASTAT Is a file defined to MODEL204 machines through a FILEDEF

The following figure illustrates the CA-ACF2 VM Interface without a security service machine.

CA-ACF2 VM Interface without a security service machine

The CA-ACF2 VM Interface without a security service machine consists of the following components:

Component Notes
Model 204 (N/A)
ACF2PARM Is loaded dynamically at initialization
ACF2CMS Contains the CA-ACF2 VM Interface object code and invokes the SRF facility
CCASTAT Is a file defined to Model 204 machines through a FILEDEF

Brief introduction to CA-ACF2 VM

This section provides a brief summary of key CA-ACF2 VM features that are used in the discussion of the Model 204 CA-ACF2 VM Interface.

For more information about CA-ACF2 VM, see the CA Technologies documentation associated with that product.

CA-ACF2 processing

When a user logs in to VM, CA-ACF2 performs the following functions:

  • Validates the password found for the Logonid in the CA-ACF2 Logonid database
  • Checks for password expiration
  • Optionally, ensures that the user is accessing the system from a specific terminal or other source
  • Optionally, ensures that the user is accessing the system only during certain dates and times

System manager options

The system manager has the following additional options when a user logs in to Model 204 as a CA-ACF2 user:

  • Require each user’s login to go through Login or Account validation, defined by the ACF2GEN macro.
  • Either allow automatic login if the user ID is the same as the user’s CMS Logonid or always require passwords.
  • Either allow user IDs from CCASTAT or require that all user IDs are CAACF2 Logonids.
  • Set the priority globally for all users or individually through a user’s Logonid record. If the priority is not set for each Logonid, Model 204 assumes global priority.
  • Change the user’s record security key and not default to the Model 204 user ID.

CA-ACF2 VM and the Model 204 CA-ACF2 VM Interface

The Model 204 CA-ACF2 VM Interface uses the System Request Facility (SRF) to send validation requests to the CA-ACF2 service machine. The two forms of SRF are single-user and multiuser.

Single-user SRF executes all CA-ACF2 validation requests using the Logonid of the CMS virtual machine running Model 204. The Model 204 configurations of single-user SRF are:

  • Single-user Online or BATCH
  • IFAM1

Multiuser SRF allows one CMS virtual machine to issue CA-ACF2 validation requests on behalf of other CMS virtual machines or Logonids. The terms multiuser SRF and MUSASS (Multiuser Single Address Space System) are interchangeable. Sample Model 204 configurations are:

  • Multiuser Online
  • Single-user Online

Logonid record

CA-ACF2 maintains a Logonid record (or LIDREC) for each user. The Logonid record includes the Logonid, which is the same as the CMS user ID. Each user on a CA-ACF2-protected system has a password associated with the Logonid. The passwords are stored in an encrypted format that cannot be reversed.

With CA-ACF2 VM, each user is defined once, regardless of the number of subsystems they can access. To help an installation define differing authorities for different subsystems, users are identified via a user identification (UID) field.

User identification string

The user identification string (UID) is a field on the Logonid record. It is a 24byte character string constructed from the user’s Logonid and other site-definable fields such as department number or employee ID. The default UID is the Logonid. CA-ACF2 compares the user’s UID with the UID masks specified in a rule set to determine whether a user can have access to a resource.

A UID mask can be placed on any rule to allow or prevent access by a group of users based on their UID string. For example, a rule in the Rules database can have a UID mask that allows everyone with a department code of DEV to have access to a certain resource.

The ACMCB control block, which CA-ACF2 uses to perform validations, is created from information in the Logonid record. When using single-user SRF, this control block is in CP storage and cannot be inspected or changed by the users. When using a MUSASS (Multiuser Single Address Space Systems), a copy of the ACMCB for each user is made available to allow the Model 204 Online or the security service machine to make security validation requests on behalf of other users.

CA-ACF2 Generalized Resource Control

CA-ACF2’s Generalized Resource Rules are similar to access control rules. However, they control access to resources other than files. These system resources can be defined either by CA-ACF2 or locally by each site.

By allowing each site to specify which local resources require security protection, the rules for a data processing installation can be complex enough to define any arbitrary or real system resources needed. One example of user-defined local resources is Model 204 user privileges.

Generalized Resource Rules are most often written by the CA-ACF2 security officer. For more information, see Maintaining the CA-ACF2 VM Interface.

Running the CA-ACF2 VM Interface with Model 204

A Model 204 multiuser Online always runs as a CA-ACF2 MUSASS (Multiuser Single Address Space System). A MUSASS is defined by CA-ACF2 as any program that runs as a single job in one virtual machine that supports more than one user. Other Model 204 configurations such as single-user and IFAM1 do not normally run as a MUSASS, because only a single user’s authorization is in question.

In either a MUSASS or single-user environment, Model 204 queries CA-ACF2 for the authorization to grant access to various system resources on behalf of the user. For example, user privileges are defined as resources to be protected, and rules are written to determine who is authorized to use those resources.

Managing the authorization process

In a MUSASS, Model 204 manages the authorization process, because only Model 204 can identify which user initiates a request for a resource. Model 204 assists CA-ACF2 in validating those requests and responds to users who issue requests for unavailable resources.

Model 204 interfaces with CA-ACF2 in the following areas:

  • User logins
    • LOGIN/LOGON command
    • IFSTRT function
    • IFLOG function
  • User logouts
    • LOGOUT/LOGOFF command
    • IFFNSH/IFDTHRD function
  • Model 204 user resources
    • Job submission (USE $JOB command)
    • Dynamic allocation of new DASD space (ALLOCATE command)
    • All sequential file and VSAM file opens for READ/WRITE access
    • Sequential data set handling (Record I/O)
    • DUMP/RESTORE commands
    • OPEN command naming a deferred update data set

Note: Because Model 204 databases are not validated on behalf of the user by the security interface, CA-ACF2 VM must grant the owner of an address space permission to open Model 204 file data sets for update, regardless of whether the owner has write or read-only privileges. This allows Model 204 to write back updates to the FPL (File Parameter List) page, as required by the database management system, regardless of the Model 204 file open privileges.

The CA-ACF2 VM Interface uses the ACFDIAG macro, discussed below, to validate user requests for Model 204 resources. No source code modifications or exits to the CA-ACF2 software are necessary. CA-ACF2 system parameters do, however, need modifying as described later on this page.

ACFDIAG macro

Whenever the CA-ACF2 VM Interface encounters a request for validation, the Interface issues a call to ACFDIAG, which in turn issues a diagnosis. The virtual machine then waits while the ACF2VM virtual machine processes the request and returns the results to the MODEL204 machine. The ACFDIAG macro is provided by SRF of CA-ACF2 VM.

ACF2CMS module

ACF2CMS, a Model 204 object module, builds all SRF argument blocks, issues the ACFDIAG macro, and retrieves data returned from ACF2VM (CA-ACF2’s service machine). The ACF2CMS module is linked into the Model 204 Online, IFAM1, and the CA-ACF2 security service machine.

Where ACF2CMS issues its CA-ACF2 calls from is determined by the SECURID argument in the ACF2GEN macro as discussed in ACF2GEN macro.

  • If the SECURID argument is defined as the CMS Logonid of the security service machine, ACF2CMS requests are made from the security service machine.
  • If the CA-ACF2 SECURID argument is left blank, CA-ACF2 requests are made from the Online (or IFAM1).

Using the CA-ACF2 VM Interface

This section discusses the changes to Model 204 when running with the CAACF2 VM Interface. The areas affected include:

  • LOGON or LOGIN
  • IFSTRT function
  • IFLOG function within IFAM1

LOGIN or LOGON command

To log in, enter:

LOGIN userid [account]

or

LOGON userid [account]

where

userid Is a character string that identifies you
account Is an optional character string that identifies the account under which you log in

Every Model 204 user has a user ID, password, and user privileges assigned by the system manager consisting of:

  • User ID that identifies you to Model 204
  • Password that provides access to the system
  • User privileges associated with your user ID and password to define the particular type of access that you have
  • Default priority class assigned to your user ID

When native Model 204 security is in effect, this user ID information is stored in a record in the CCASTAT system file. The record is deleted from CCASTAT when the system manager puts the user under CA-ACF2 security.

After the record is deleted from CCASTAT, your user ID and password are verified by CA-ACF2. Your user ID must be 8 characters or less or CA-ACF2 cannot validate it. Model 204 prompts for a password unless the NOPASSWORD argument of ACF2GEN is specified and the user ID is the same as your CMS Logonid. You can change the CA-ACF2 Logonid password when you log in to Model 204. For more information, see the wiki page for the Model 204 LOGIN or LOGON command.

If the LOGIN option is specified on the M204 EXEC, a LOGIN command is automatically generated using your CMS Logonid as your Model 204 user ID. If the NOPASSWORD option of ACF2GEN is also specified, you are logged in and not prompted for a password when you issue M204 EXEC.

Account validation

Account validation can occur as part of account processing at your site. The two parts to account processing are:

  • Provide a default account value when you do not specify an account on the LOGON/LOGIN command. In this case, the account is supplied from the CA-ACF2 user Logonid record.
  • Provide account validation if you do specify an account value on the LOGON/LOGIN command.

Account validation ensures that your Logonid belongs to a certain group, or account, such as DEV or MKTG. If your site performs CA-ACF2 account validation, any value you enter in the account field is verified via CA-ACF2 services.

Source validation

Source entry validation is when CA-ACF2 ensures that you log in only from certain specified sources, such as a specific terminal. If your site performs source entry validation, the physical terminal source is your CMS Logonid. CAACF2 validates the source of the login along with the password.

IFSTRT function

In IFAM2 environments, the IFSTRT function allocates a Host Language Interface thread in a Host Language program. IFSTRT also establishes the calling convention.

When processing the login argument of the IFSTRT call, the user login process is the same process as for User 0 login.

IFLOG function within IFAM1

The IFLOG function is used only in the IFAM1 environment. It is called following IFSTRT to identify the user when a login is required. This function is necessary in any IFAM1 program where user authorization is validated by CA-ACF2.

As with the IFSTRT function, the user login process is the same as the process for User 0 login.

Login processing

The system manager is responsible for defining and controlling security processing in a Model 204 installation in which CA-ACF2 supplies authorization services.This section describes the login processing performed by the CA-ACF2 VM Interface.

Online login processing

When a user login occurs, Model 204 acquires the user ID and account and searches CCASTAT to determine whether or not the Model 204 user ID exists. If the user ID is found, Model 204 proceeds with CCASTAT security processing.

If the user ID is not in CCASTAT and CA-ACF2 security is in effect, Model 204 uses CA-ACF2 facilities to authorize the user login. Model 204 prompts for a password for CCASTAT and CA-ACF2 users unless the NOPASSWORD argument is specified in ACF2GEN and the user ID in the LOGIN command is the same as the CMS Logonid.

Note: The PASSWORD/NOPASSWORD argument of ACF2GEN overrides the LOGCTL NP CMS and P CMS options for CCASTAT and CAACF2 users.

IFAM2 login processing

If the login is processed via IFAM2, a password is always required, as the NOPASSWORD argument of ACF2GEN and the LOGCTL NP CMS option do not work in conjunction with IFAM2.

Source entry validation is performed if there is a SOURCE field on the Logonid record. If your site performs source entry validation, the physical terminal source is the user’s CMS Logonid.

CA-AFC2 Logonid record

After the user’s CA-ACF2 user ID and password are verified, the CA-ACF2 VM Interface has access to the CA-ACF2 Logonid record.

Model 204 continues processing the login via the Logonid record, and the following parameters are specified in ACF2GEN:

Parameter Function
VALIDAT=LOGIN Performs login validation to determine if a user is authorized to log in to Model 204. Model 204 does a Generalized Resource Call using the resource type defined by the RESOURC field of ACF2GEN and the PRIV.LOGIN.M204 key name.
ACCOUNT= Performs account processing. If default account location and length are specified in ACF2GEN and the user does not enter an account, the default account is retrieved from the Logonid record and the user is allowed in to Model 204.

Account processing is taken further if the VALIDAT=ACCOUNT and ACCTRES arguments are specified in ACF2GEN. If the user provides an account and there is a value in ACCOUNT= in ACF2GEN, the value entered is compared to the value in the Logonid record. If the values match, the user is allowed in to Model 204. If the values do not match, CA-ACF2 validates the account using the resource code defined by the ACCTRES argument of the ACF2GEN macro and the account value as the key name.
PRTY= Specifies the user priority. The priority field is taken from the Logonid record if PRTY is specified as an offset into the Logonid record in ACF2GEN. Otherwise, if PRTY is set to H, S, or L, all CA-ACF2 users receive the same priority.
RECSCTY= Specifies record security. The record security key is also taken from the Logonid record if RECSCTY is specified as an offset into the Logonid record in ACF2GEN. If it is not specified, the Model 204 user ID is used.

If CA-ACF2 denies system access because of an invalid password, account, or source, or if the user is not authorized to use Model 204, the user is not logged in and Model 204 issues an error message.

In addition, if the user enters an invalid password, CA-ACF2 increments a password violation counter, which is maintained by CA-ACF2. When the counter reaches a maximum number that you set, CA-ACF2 prevents entry to the system.

After successfully logging in, the user is granted Model 204 privileges of X‘008’. Any additional privileges are determined whenever a user issues a command that requires a specific privilege.

CCASTAT and CA-ACF2

To provide a smooth transition from Model 204 security to CA-ACF2 security, user ID data can continue to be stored in CCASTAT. As users are secured by CA-ACF2, you can delete the standard Model 204 CCASTAT user ID entries.

If the LOGONID argument of ACF2GEN macro is left blank, CCASTAT users are not allowed to log in to Model 204. Only CA-ACF2 users are allowed access unless the LOGONID argument specifies VMID or JOBLID.

All the system manager commands concerning CCASTAT maintenance functions continue to work as usual. The ZBLDTAB and ZCTLTAB utilities also continue to work as usual.

File, group, and subsystem security functions are defined and described in Security topic and in the Rocket Model 204 System Manager’s Guide.

User 0 login

User 0 is treated differently than ordinary users logging in to an Online through an IODEV.

There are several ways to log in User 0. The first is the method that Technical Support recommends:

  • Code a LOGIN command with no user ID or password (recommended approach).

    For example:

    PGSIZE=6184 . . . IODEV=41,POLLNO=10 LOGIN BROADCAST... . . .

    Model 204 logs in User 0 as a CA-ACF2 user by appending the Logonid of the MODEL204 machine to the LOGIN command as the user ID. No password is required.

  • Use a CCASTAT user ID and password:

    LOGIN userid [account] password

  • Enter the Logonid of the MODEL204 machine on the LOGIN command without a password

    The user ID must equal the Logonid or VMID of the virtual machine or the login fails.

User 0 processing

Model 204 first checks CCASTAT for the user ID in the LOGIN command:

  • If the user ID is found, Model 204 checks the LOGONID argument of ACF2GEN to determine if a CCASTAT User 0 is allowed access.
  • If the LOGONID argument is left blank, the CCASTAT user ID is not allowed and the User 0 login fails. Only a User 0 logged in through the CAACF2 VM Interface has access to Model 204.
  • If the LOGONID argument is set to the VMID or JOBLID, a password is required and the CCASTAT User 0 receives its Model 204 privileges from the user ID entry in CCASTAT.
  • If the user ID is the same as the Logonid, do not add a password. If there is a password, it is registered as an invalid Model 204 command.
  • If CCASTAT does not contain the user ID, Model 204 assumes it is a CAACF2 login. Model 204 does a Generalized Resource check to see if User 0 is allowed to log in to Model 204. If the user ID is from CCASTAT, no check is done.

The rules for coding LOGIN for the IFAM1 IFLOG commands are the same as for User 0. For security reasons, Technical Support recommends that, if a CAACF2 Logonid is provided, code the LOGIN command without a user ID and password.

Single-user Onlines

Logins from single-user Onlines can come from a command in a CCAIN file or interactively from a terminal and have the attribute of being User 0. A login from CCAIN is similar to User 0 login from a multiuser Online or IFAM1 thread. However, a login from a terminal has characteristics similar to a user logging in to a MUSASS through an IODEV thread.

Flexibility is provided by treating all LOGIN commands from CCAIN as User 0 logins. However, once the end of CCAIN is reached and commands can be entered interactively through the terminal, all LOGIN commands go through password, account, login privilege, and terminal security processing as if through an IODEV thread.

After the commands are issued interactively from the terminal, the single-user Online can usually issue a login for any CCASTAT or CA-ACF2 user ID.

One exception is if the Online is issuing its own CA-ACF2 diagnose commands within the MODEL204 machine and the machine is not SRF-authorized. In this case, the user ID must either be from CCASTAT or be the Model 204 virtual machine Logonid. If the user ID is the virtual machine Logonid, Model 204 does not prompt for a password and the user is logged in automatically.

AUTHCTL VIEW command

The AUTHCTL VIEW command displays the interface control options currently in effect for the active interface (CCASTAT and ACF2GEN).

The syntax is as follows:

AUTHCTL VIEW

or

AUTHCTL VIEW ACF2

(For information about setting control information, see Preparing ACF2PARM with ACF2GEN).

Maintaining the CA-ACF2 VM Interface

At each CA-ACF2 VM site, the installation security officer (ISO) performs system-wide maintenance functions within CA-ACF2. The security officer is responsible for defining and maintaining the CA-ACF2 Generalized Resource Rules for privilege security that will eventually be used by Model 204. In addition, the security officer creates the ACF2PARM module, which defines the CA-ACF2 environment to Model 204. This section describes the Model 204 data that the security officer maintains.

Defining user privileges

You must identify Model 204 privileges to CA-ACF2.

The Model 204 privileges for CA-ACF2 users are defined as CA-ACF2 Generalized Resource Rules. The RESOURC argument of ACF2GEN is used along with fixed CA-ACF2 key names. If an argument is not specified, RESOURC defaults to 204.

The following user privilege names define the possible privilege rules for a user. See LOGCTL for more information on the LOGCTL command.

This privilege... Defines users who can... Corresponding LOGCTL setting
‘PRIV.SUPER.USER’ Exercise superuser privilege and can create a file with the CREATE command. X‘80’
‘PRIV.SYSTEM.ADMIN’ Exercise system administrator privilege and issue commands such as LOGWHO, MONITOR, PRIORITY, and WARN. X‘40’
‘PRIV.CHANGE.FILE.PASSWORD’ Change CCASTAT file passwords when opening a file. X‘20’
‘PRIV.SYSTEM.MANAGER’ Issue system manager commands, that is issue all system administrator commands plus certain other privileged commands. X‘08’
‘PRIV.OVERRIDE.RECORD.SECURITY’ Override record security. X‘04’

For CCASTAT users, privileges are defined to the CCASTAT user ID by the Model 204 LOGCTL command. The LOGCTL command contains an additional privilege bit (X‘10’) that indicates whether or not CCASTAT users can change their own login passwords at login time. This privilege bit is not required for the CA-ACF2 VM Interface, because you set this privilege for all CA-ACF2 users within CA-ACF2.

Security service machine

Once the security service machine is active, any MODEL204 machine can connect to it. You can set up multiple security service machines for test and production purposes. After a security service machine is initialized, it:

  • Allows MODEL204 machines to connect to the security service machine via IUCV
  • Performs all CA-ACF2 validation requests sent to it
  • Relays return codes, reason codes, and data back to Model 204 for each validation request
  • Allows MODEL204 machines to terminate and sever the IUCV connection

The IUCV connection between each MODEL204 machine and the security service machine is severed when the MODEL204 machine terminates.

The SECURID argument of the ACF2GEN macro specifies the Logonid of the security service machine to which the MODEL204 machine sends CA-ACF2 validation requests. If SECURID is left blank, CA-ACF2 diagnose commands are issued from within the MODEL204 virtual machine and a security service machine is not used.

Security service machine commands

The following commands control execution of the security service machine.

SECURITY

Use the SECURITY command to start execution of the security service machine.

The command format is:

EXEC SECURITY [datasetname fm | fn ft fm}

where:

datasetname fm Specify the name and file mode of a file on a variable-formatted disk
fn ft fm Specify the file name, file type, and file mode of a CMS data set

The security service machine writes information to the file including statistics for each MODEL204 machine connected with the security service machine, error messages, and terminal request commands.

STATUS

Use the STATUS command to request information while the security service machine is running. STATUS provides information on all MODEL204 machines connected and how many CA-ACF2 users are logged in through each Model 204 machine. For example:

STATUS ***** ***** STATUS: NUMBER OF CONNECTED MODEL204 MACHINES = 4 ***** ***** STATUS: MACHINES CONNECTED ARE: MODEL204 M204A ***** ***** STATUS: M204B M204C ***** ***** STATUS: MODEL204 NUMBER OF LOGGED IN USERS = 5 ***** ***** STATUS: M204A NUMBER OF LOGGED IN USERS = 50 ***** ***** STATUS: M204B NUMBER OF LOGGED IN USERS = 11 ***** ***** STATUS: M204C NUMBER OF LOGGED IN USERS = 8

STOP

To terminate security service machine processing in an orderly fashion, use the STOP command. STOP prevents MODEL204 machines from initializing and establishing new IUCV connections, but allows machines with existing connections to continue until those MODEL204 machines terminate.

The command format is:

STOP

START

If you terminated processing with the STOP command, the START command reverses the process and allows new MODEL204 connections onto the security service machine.

The command format is:

START

FORCE

To end the connection of a particular MODEL204 machine with the security service machine, use the FORCE command. FORCE severs the IUCV connection between the two machines and forces the MODEL204 machine to terminate.

The command format is:

FORCE virtual-machine-name

PURGE

CA-ACF2 VM keeps a copy of the CA-ACF2 Generalized Resource Rules used by Model 204 in the security service machine’s virtual storage.

When the Installation Security Officer (ISO) changes a rule for any Model 204 key name and reloads the resource code with the ACFSERV command, the old rule remains in virtual storage until a PURGE is issued.

PURGE flushes the old rule set from virtual storage. After a PURGE command is issued, CA-ACF2 acquires the new rule the next time the CA-ACF2 VM Interface asks CA-ACF2 to validate a Generalized Resource Request.

Note: To purge an old rule set from MODEL204 virtual storage when the CAACF2 VM Interface is running within the MODEL204 machine, you must terminate Model 204 and re-IPL the CMS virtual machine.

The command format is:

PURGE

EOJ

To terminate processing in the security service machine, use the EOJ command. Issue a STOP command first to prevent any new MODEL204 machines from establishing connections and give machines with existing connections time to terminate. If any machines have connections when you enter EOJ, the connections are severed and the MODEL204 machines terminate.

The command format is:

EOJ

CA-ACF2 statistics

For each MODEL204 machine, statistics are provided when Model 204 terminates. Information includes the number of:

  • Successful logins
  • Successful logouts
  • Failed logins
  • Successful and failed privilege requests

When the security service machine terminates, additional statistics include the maximum:

  • IUCV connections allowed as specified in the VM directory of the security service machine (MAXCONN)
  • IUCV connections established at any one time during execution
  • Number of outstanding IUCV messages that were queued and waiting to be processed for that MODEL204 machine in the security service machine at any one time
  • Number of messages allowed on a path as specified in the VM directory of the security service machine (MSGLIMIT)
  • Number of outstanding messages in the queue that existed at any one time for all paths

Check these statistics occasionally to ensure that you are not reaching the limits set by MAXCONN and MSGLIMIT. Reaching these limits may affect VM performance.

If the number of IUCV connections established during execution is often close to or equal to MAXCONN, increase MAXCONN. The default for MAXCONN is four.

If the number of IUCV messages queued and waiting for processing is often close to or equal to MSGLIMIT, increase MSGLIMIT. The maximum for MSGLIMIT is 255; the default is 10.

For more information about MAXCONN and MSGLIMIT, see Modifying the VM directory.

Preparing ACF2PARM with ACF2GEN

The ACF2PARM parameter module allows you to define CA-ACF2 arguments for your site. ACF2PARM consists of one or more ACF2GEN macros that are coded, assembled, and generated by your site.

ACF2PARM is both a text deck and a module. To activate the CA-ACF2 VM Interface, an ACF2PARM text deck must be available to be dynamically loaded by an ONLINE module. If Model 204 is IFAM1 or an Online saved segment, the ACF2PARM module must also be available.

If ACF2PARM is loaded, the CA-ACF2 VM Interface must initialize successfully before Model 204 can be initialized. If ACF2PARM is not available to be loaded, Model 204 initializes without the CA-ACF2 VM Interface active.

SECPLIST parameter

The SECPLIST User 0 parameter in CCAIN allows you to specify the name of the ACF2GEN argument set with which to initialize the interface. The name is defined by the assembler label name of the ACF2GEN macro.

CA-ACF2 does a Generalized Resource check to determine if a virtual machine running Model 204 is authorized to use a particular set of parameters specified by an ACF2GEN macro. CA-ACF2 looks at the resource code specified by the RESOURC argument of ACF2GEN and the key name PRIV.SECPLIST.name (where name is the name of an ACF2GEN macro). If the check fails, Model 204 cannot be initialized.

If the named set is not found in CCAIN, the default arguments of the ACF2GEN macro are automatically used, which allows Model 204 to try to initialize the Interface. However, Model 204 does not initialize under the following circumstances:

  • If the CA-ACF2 system components do not contain the Model 204 rules assumed by the ACF2GEN default arguments
  • If the MODEL204 machine is not authorized to use the default set of CAACF2 parameters

In the first example below, LOG1, the resource code is 204, and the key name is PRIV.SECPLIST.LOG1. In the second example, LOG2, the resource code is TST, and the key name is PRIV.SECPLIST.LOG2.

TITLE 'ACF2PARM MODULE' X LOG1 ACF2GEN SECURID=SECUR204, X RESOURC= 204 , X ACCOUNT=(X'0141',X'0A'), X VALIDAT=LOGON, X PASSWORD, X PRTY=X'0140', X LOGONID=

LOG2 ACF2GEN SECURID=, X RESOURC= TST , X ACCOUNT=(X'0204',X'08'), X VALIDAT=ACCOUNT, X ACCTRES=ACT, X NOPASSWORD, X RECSCTY=(X'020C',X'0A'), X PRTY=S, X LOGONID=VMID ACF2GEN TYPE=END END

If ACF2PARM is available on an accessed disk but no SECPLIST parameter was specified in CCAIN, the default values of ACF2GEN are used with a resource code of 204 and a key name of PRIV.SECPLIST.DEFAULT.

ACF2GEN macro

The ACF2GEN macro defines the way an installation uses the CA-ACF2 VM Interface. The arguments of the ACF2GEN macro are described in detail in this section.

Sample ACF2GEN macros are available with the distributed software in the ACF2PARM ASSEMBLE file. In the following example, all defaults are shown.

The format of the ACF2GEN macro is:

NAME ACF2GEN SECURID=, Security service machine RESOURC=204, CA-ACF2 resource type for M204 ACCOUNT=(0,0), Acct field position & length VALIDAT=, Validate login and/or acct ACCTRES=, CA-ACF2 resource type for acct NOPASSWORD/PASSWORD Password not req’d/req’d RECSCTY=(0,0), Record security pos. & length PRTY=S, Priority LOGONID=, CCASTAT UID allowed/not allowed TYPE= End of macro definitions

where:

  • NAME defines the name of this set of CA-ACF2 arguments. Each ACF2GEN macro must have a unique name. During Model 204 initialization, the name specified in the CCAIN parameter SECPLIST must identify a particular ACF2GEN macro with which to initialize the CA-ACF2 VM Interface. If SECPLIST is not defined in CCAIN, the default values of the ACF2GEN macro are used if ACF2PARM is loaded.
  • SECURID specifies the virtual machine name of the security service machine. If SECURID is not coded or left blank, the CA-ACF2 diagnoses are issued from within the MODEL204 machine and not sent to a security service machine.
  • RESOURC specifies the 3-character CA-ACF2 resource code for this installation. Model 204 user, login, and SECPLIST privileges are defined.

    The code must match the resource code described to CA-ACF2 in the ACFFDR @RESTYPE macro.

    The default code is 204.

  • ACCOUNT specifies the position and length of the field within the Logonid record where the user’s default account can be found. If a position is defined and the user does not enter an account on the LOGIN command, CA-ACF2 uses the default account in the user’s Logonid.

    If you do not specify the ACCOUNT argument, no account processing is performed.

    ACCOUNT must be 1–10 characters in length.

    The ACCOUNT argument must be specified if ACCTRES and VALIDAT=ACCOUNT are set.

    The rules for specifying position and length are as follows:

    • Position indicates the offset within the CA-ACF2 Logonid record where the data is stored. The field must be defined in the LIDREC dsect and by a @CFDE entry in the ACFFDR. Specify position as a 4-digit hexadecimal value (for example X‘0132’).
    • Length must be specified as a 2-digit hexadecimal value from 1–10 (X‘01’to X‘0A’).

  • VALIDAT has two options: LOGIN and ACCOUNT.

    You can specify parameters in any order, but they must be enclosed in parentheses and separated by a comma. For example:

    VALIDAT=(LOGIN,ACCOUNT) VALIDAT=(ACCOUNT,LOGIN) VALIDAT=ACCOUNT VALIDAT=LOGIN

    • LOGIN specifies that Model 204 determines if a user is authorized to log in to Model 204. If you do not specify VALIDAT=LOGIN, all users are allowed access, provided that they pass the Logonid/password and optional source and account validation. If LOGIN is specified, Model 204 performs a Generalized Resource check using the type specified in RESOURC and the ‘PRIV.LOGIN.M204’ key name.
    • ACCOUNT parameter (not to be confused with the ACCOUNT argument described previously) specifies that any account entered by the user during the login process is validated by CA-ACF2.

      VALIDAT=ACCOUNT causes the account value entered by the user to be compared against the account value found in the user’s Logonid record. If the values match, the user is allowed in to Model 204. If the values do not match, the account is validated using the ACCTRES resource type and the account value as the key name. If this validation is successful, the user is allowed in to Model 204. Otherwise, the login fails.

      The VALIDAT=ACCOUNT parameter can be specified only if both ACCTRES and the ACCOUNT arguments are specified.

  • ACCTRES specifies the 3-character CA-ACF2 resource code selected to validate the account value entered by the user during the login process. The code must match a resource code defined in the @RESTYPE macro of the ACFFDR for this installation. ACCOUNT and VALIDAT=ACCOUNT must be specified if ACCTRES is present.

    There is no default and it can be the same code defined by the RESOURC argument.

  • NOPASSWORD directs Model 204 to bypass the password prompt if the LOGIN command contains a user ID equal to the CMS user ID of the virtual machine on which the login originated.

    If they are not equal, Model 204 prompts for a password.

  • PASSWORD specifies that a password is always required.

    When the CA-ACF2 VM Interface is active, the NP CMS and P CMS options of the LOGCTL command are ignored for CA-ACF2 and CCASTAT user IDs.

    PASSWORD is the default.

  • RECSCTY specifies the position and length of the field in the Logonid record where the record security key can be found. This value overrides the default, which is the Model 204 user ID.

    The rules for specifying position and length are as follows:

    • Position indicates the offset within the CA-ACF2 Logonid record where the data is stored. The field must be defined in the LIDREC dsect and by a @CFDE entry in the ACFFDR. Specify position as a 4-digit hexadecimal value (for example X‘0132’).
    • Length must be specified as a 2-digit hexadecimal value from 1–10 (X‘01’ to X‘0A’).
  • PRTY specifies the default user priority. The options are as follows:

    • A 1-character value of H, S, or L for High, Standard, and Low, respectively, that defines the default user priority for all users logged in under CA-ACF2.
    • The position of a field in the Logonid record where the priority for each individual user is specified. Position must be specified as a 4-digit hexadecimal value (for example X‘0142’).

    The field must be defined in a @CFDE entry in the ACFFDR and the LIDREC dsect, and contain a 1-character value of either H, S, or L.

    The default priority is STANDARD if the PRTY keyword is omitted or if there is an invalid character at the specified position in the Logonid record.

  • LOGONID can be specified as VMID, JOBLID, or left blank. If left blank, only CA-ACF2 users can access the system; CCASTAT-defined users are not allowed to log in to Model 204.

    If LOGONID is specified as JOBLID or VMID, CCASTAT users can access Model 204.

  • TYPE indicates the end of the ACF2PARM module. TYPE must be coded only once, following all other ACF2GEN macros, and as the only argument in an ACF2GEN macro.

Sample ACFPARM module

The following sample ACF2PARM module contains two sets of CA-ACF2 parameters called LOG1 and LOG2.

TITLE 'ACF2PARM MODULE' LOG1 ACF2GEN SECURID=SECUR204, X RESOURC=204, X ACCOUNT=(X'0141',X'0A'), X VALIDAT=LOGON, X PASSWORD, X PRTY=X'0140', X LOGONID= LOG2 ACF2GEN SECURID=, X RESOURC=TST, X ACCOUNT=(X'0204',X'08'), X VALIDAT=ACCOUNT, X ACCTRES=ACT, X NOPASSWORD, X RECSCTY=(X'020C',X'0A'), X PRTY=S, X LOGONID=VMID ACF2GEN TYPE=END END

Installing the CA-ACF2 VM Interface

Follow these steps to install the Model 204 CA-ACF2 VM Interface. Each item in the list is discussed in more detail in later sections.

  1. Update the VM directory to include a new entry for SECUR204, the security service machine. Update the directory entries for MAINT204 and for all Model 204 service machines issuing CA-ACF2 diagnoses Online.
  2. Create a new PROFILE EXEC for SECUR204. Update the PROFILE EXEC for MAINT204 and for all the Model 204 service machines issuing CA-ACF2 diagnoses Online.
  3. Decrypt the object modules that comprise the CA-ACF2 VM Interface.
  4. Generate the ONLINE, IFAM1, and SECURITY modules.
  5. Apply a zap to the ACFDIAGC CSECT of the Model 204 SECURITY, ONLINE, and IFAM1 modules.
  6. Save the Model 204 saved segments again.
  7. Determine security requirements for each MODEL204 machine. Code the ACF2GEN macros. Assemble ACF2PARM and generate the ACF2PARM module.
  8. Insert a CA-ACF2 Logonid record for SECUR204. Update the Logonid records for each virtual machine running Model 204.
  9. Update the ACFFDR to include @SRF macros for the security service machine and any multiuser or single-user MODEL204 machines that authorize requests on behalf of other CA-ACF2 Logonids.
  10. Update the ACFFDR to include in the @RESTYPE macro the new resource codes required to write CA-ACF2 Generalized Resource Rules to validate user privileges, CCAIN SECPLIST values, and optional login and account validations.
  11. Update the ACFFDR to include @CFDE macro entries for three new fields on the Logonid record required for setting individual user default account values, priority, and record security keys. All three fields are optional depending on installation requirements.
  12. Update the LIDREC dsect to include any of the three new fields defined by @CFDE entries in the ACFFDR.
  13. Write CA-ACF2 Generalized Resource Rules for:
    • SECPLIST validations
    • Model 204 user privileges
    • Model 204 login privileges — optional
    • Account validations — optional
    • Terminal security — optional
  14. Update the EXEC1 and EXEC2 execs specified in the ONLINE command when invoking Model 204 and the EXECname on the IFAM1 command to include a FILEDEF for the CA-ACF2 VM loadlib named ACFSRF.
  15. Update the CCAIN files to increment NSUBTKS and include the SECPLIST parameter.

Modifying the VM directory

Before installing the interface, add a VM directory for the security service machine and modify the VM directories for the Model 204 maintenance machine and MODEL204 service machine. This section describes how to modify the directory entries needed for the CA-ACF2 VM Interface.

SECUR204 - Security Service Machine

Add a VM directory entry for the security service machine if CA-ACF2 diagnoses are to be made from a security service machine. A sample directory entry is:

USER SECUR204 password 2M 2M G OPTION BMX MIH MAXCONN nnnnn IUCV ALLOW MSGLIMIT limit ACCOUNT account distcode IPL CMS PARM AUTOCR CONSOLE 009 3210 T userid SPOOL 00C 2540 READER A SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A LINK CMSowner 190 190 RR LINK CMSowner 19E 19E RR LINK MAINT204 193 193 RR LINK CMSowner aaa bbb RR MDISK 191 type start size volser MR

where:

MAXCONN Is the maximum number of IUCV connections that can be open at one time. It represents the maximum number of MODEL204 machines that can communicating with the security service machine at the same time. The default is 4.
MSGLIMIT Is the maximum number of outstanding messages allowed on any path authorized by this IUCV directory control statement. MSGLIMIT depends upon the number of outstanding IUCV security requests for any one Online. VM performance might be affected if this limit is reached. The default is 10 and the maximum is 255.
ACFSRF LOADLIB (CMSowner aaa bbb) supplied by CA-ACF2 VM Must be available to the security service machine. Link to the appropriate minidisk by either providing a LINK entry in the VM directory entry or a LINK command in the PROFILE EXEC.

MAINT204 - Model 204 Maintenance Machine

The Model 204 maintenance machine requires the ACF2VM TXTLIB to be available on an accessed minidisk when generating the ONLINE, IFAM1, and SECURITY modules. Either the VM directory entry for MAINT204 must have a LINK statement or the PROFILE EXEC must include a LINK command to the minidisk containing ACF2VM TXTLIB.

MODEL204 - Model 204 Service Machines

Virtual machines running any configuration of Model 204 might or might not require an update to their VM directory entries. If a Model 204 virtual machine sends its security requests to the security service machine, no change is necessary. If, however, Model 204 issues the CA-ACF2 diagnoses itself Online, the ACFSRF LOADLIB must be available on an accessed disk. Either the VM directory entry for Model 204 must have a LINK statement or the PROFILE EXEC must include a LINK command to the minidisk containing the ACFSRF LOADLIB.

Creating the PROFILE EXECs

The next step is to create appropriate PROFILE EXECs for the security service machine, and modify the PROFILE EXECs for the MAINT204 and MODEL204 service machines. The commands needed in the PROFILE EXECs follow.

SECUR204 — Security service machine

The security service machine needs only to access the necessary disks and to start up the SECURITY EXEC. Therefore, a sample PROFILE EXEC for the security service machine is as follows:

/* SAMPLE PROFILE EXEC FOR SECURITY SERVICE MACHINE */ 'ACC 193 C' /* access MAINT204's 193 mdisk */ 'ACC bbb fm' /* access the mdisk containing ACFSRF LOADLIB */ 'EXEC SECURITY SECURITY CCAAUDIT A' 'LOGOUT' exit rc

MAINT204 — Model 204 maintenance machine

If the VM directory entry does not have a LINK statement linking to the minidisk that contains the ACF2VM TXTLIB, there must be a LINK command in the MAINT204 PROFILE EXEC. An ACCESS command to the minidisk must also be included in the PROFILE EXEC regardless of where the LINK is located.

MODEL204 — Model 204 service machines

If the VM directory entries do not have a LINK statement linking to the minidisk that contains the ACFSRF LOADLIB, the PROFILE EXEC for the virtual machines running Model 204 and issuing CA-ACF2 diagnoses Online requires a LINK command. An ACCESS command to the minidisk must be included in the PROFILE EXEC.

Decrypting object modules

The object modules that comprise the CA-ACF2 VM Interface are distributed with the Model 204 software in an encrypted format. To include the interface, you must decrypt the object modules using M204CRYP.

Using M204CRYP

You must have the decryption key for the CA-ACF2 VM Interface available. The key is located on the Authorization Form packaged with your distributed software.

The syntax for M204CRYP is:

M204CRYP DECODE ACF2 key

where:

key Is the decryption key on the authorization form included with the distributed software.

For more information about M204CRYP refer to the Rocket Model 204 Installation Guide for IBM z/VM.

Creating Model 204 modules and saved segments

To create the appropriate Model 204 modules for the CA-ACF2 VM Interface you must:

  • Generate the security, ONLINE, and IFAM1 modules
  • Apply appropriate Early Warnings and zaps
  • Save Model 204 saved segments

This section discusses these steps in detail.

Generating the Model 204 modules

Regenerate the modules for the following Model 204 configurations:

  • CMS
  • ONLINE
  • IFAM1

For more information about how to regenerate modules, refer to the Rocket Model 204 Installation Guide for IBM z/VM.

Note: The ACF2VM TXTLIB must be on an accessed minidisk when generating the ONLINE and IFAM1 modules or the ACFDIAGC object module is not linked in.

Generating the security module

If you did not generate an M204SCTY module for a previous release, you need to create it. M204SCTY runs the security service machine. M204GEN EXEC generates this module with the command:

M204GEN SECURITY

For more information about the M204GEN command, refer to the Rocket Model 204 Installation Guide for IBM z/VM.

Note: The ACF2VM TXTLIB must be available on an accessed minidisk when generating the SECURITY module or the ACFDIAGC text deck is not linked into M204SCTY.

Applying ACFDIAGC

Apply the following zap to the SECURITY, ONLINE, and IFAM1 modules. This is a special zap that is applied against the CA-ACF2 VM Release 3.1 ACFDIAGC CSECT. This zap allows the Model 204 MVS Interface to run with CA-ACF2 VM:

NAME xxxx ACFDIAGC VER 0054 0ACA REP 0054 4700,0000,0700 VER 0066 0ACA REP 0066 4700,0000,0700

Note: The name of the new security module is M204SCTY.

Saving Model 204 saved segments

The CMS, ONLINE, and IFAM1 saved segments must be saved if the Saved Segment facility is used. For more information about saving a Model 204 saved segment again, refer to the Rocket Model 204 Installation Guide for IBM z/VM.

Creating ACF2PARM

To activate the CA-ACF2 VM Interface during Model 204 initialization, ACF2PARM must be available on an accessed minidisk. If Model 204 is running as an ONLINE module, ACF2PARM must be a text deck. If the Model 204 configuration is IFAM1 or Online running as a saved segment, ACF2PARM must be a module. See ACF2GEN macro for information on coding the ACF2GEN macros that comprise ACF2PARM.

A sample ACF2PARM ASSEMBLE is provided on the maintenance machine’s 194 disk.

Code the ACF2GEN macros for your security environment. When you finish, issue the following commands to assemble ACF2PARM and generate a module:

VMFASM ACF2PARM NCMS 204 COPY ACF2PARM TXT220 A = TEXT C LOAD ACF2PARM (ORIGIN TRANS GENMOD ACF2PARM MODULE C

Inserting the SECUR204 CA-ACF2 Logonid

The following CA-ACF2 Logonid record for the security service machine must be added to the Logonid database using the ACF2 subcommand INSERT:

INSERT SECUR204 NAME(SECURITY 204 SERVER) - PASSWORD(xxxxxxxx) - SRF ACCOUNT

The security service machine requires the SRF privilege. The SRF privilege allows a virtual machine to issue CA-ACF2 requests on behalf of other users.

SECURITY, ACCOUNT, or both privileges must be given to the security service machine. ACCOUNT is usually sufficient. SECURITY privilege is necessary only if a security officer logs in to Model 204 using a Logonid having the SECURITY privilege. The ACCOUNT privilege is required by the ACALT parameter block from the SRF, which the CA-ACF2 VM Interface issues.

Updating Model 204 CA-ACF2 Logonids

For each MODEL204 machine, decide whether it can issue its own CA-ACF2 diagnoses or whether you want it to send the CA-ACF2 diagnoses to the security service machine. You do not need to change the Logonid records for MODEL 204 machines sending CA-ACF2 diagnoses to the security service machine.

MODEL 204 machines issuing their own diagnoses might need the SRF and ACCOUNT (and possibly SECURITY, see above) privileges depending upon the Model 204 configuration they are executing. A multiuser Online requires the SRF and ACCOUNT privileges:

  • Batch or IFAM1 job does not need any of these privileges.
  • Single-user Online might or might not need these special privileges depending upon whether or not the user ID in a single-user Online logs in using a CA-ACF2 Logonid different from its z/OS virtual machine user ID.

See Single-user Onlines for more information on executing single-user Onlines.

Writing execute-only rules

Writing CA-ACF2 access rules to protect ACF2PARM TEXT and MODULE, M204SCTY MODULE, SECURITY EXEC, M204XFER, and the M204ONLN MODULE prevents users from bypassing CA-ACF2 security in Model 204. These rules ensure that, when required, Model 204 initializes with the CAACF2 VM Interface active. Execute-only rules ensure that ordinary users cannot thwart security.

Sample rules

The following sample rules provide execute privileges to all users and read, write, and execute privileges only to MAINT204.

$KEY(MAINT204) $MODE(ABORT) ...... * Control link access to MAINT204's 193 MDISK V193.VOLUME UID(MAINT204) READ(A) WRITE(L) EXEC(A) V193.VOLUME UID(MODEL204) READ(A) EXEC(A) V193.VOLUME UID(*) READ(A) EXEC(A) * Control access to ACF2PARM TEXT and MODULE V193.ACF2PARM.* UID(MAINT204) READ(A) WRITE(L) EXEC(A) V193.ACF2PARM.* UID(MODEL204) EXEC(A) V193.ACF2PARM.* UID(*) EXEC(A) * Control access to M204SCTY MODULE V193.M204SCTY.MODULE UID(MAINT204) READ(A) WRITE(L) EXEC(A) V193.M204SCTY.MODULE UID(MODEL204) EXEC(A) V193.M204SCTY.MODULE UID(*) EXEC(A) * Control access to SECURITY EXEC V193.SECURITY.EXEC UID(MAINT204) READ(A) WRITE(L) EXEC(A) V193.SECURITY.EXEC UID(MODEL204) EXEC(A) V193.SECURITY.EXEC UID(*) EXEC(A) * Control access to the M204ONLN MODULE V193.M204ONLN.MODULE UID(MAINT204) READ(A) WRITE(L) EXEC(A) V193.M204ONLN.MODULE UID(MODEL204) EXEC(A) V193.M204ONLN.MODULE UID(*) EXEC(A) * Control access to the M204XFER MODULE V193.M204XFER.MODULE UID(MAINT204) READ(A) WRITE(L) EXEC(A) V193.M204XFER.MODULE UID(MODEL204) EXEC(A) V193.M204XFER.MODULE UID(*) EXEC(A)

M204IFM1 is not protected, because it can execute only as a saved segment. X204ONLN is most likely executed as a saved segment only. But if a user’s virtual machine is large enough, it can run X204ONLN as a module and, therefore, needs to be protected.

Updating the ACFFDR and LIDREC DSECT

The CA-ACF2 VM Interface requires updates to the ACFFDR (ACF Field Definition Record). Change the @SRF and @RESTYPE macros as discussed here. Adding @CFDE macros and updating the LIDREC dsect is optional depending upon parameters coded in the ACF2GEN macro of ACF2PARM.

Adding @SRF macros

An @SRF macro must be added to the ACFFDR for the security service machine and for each MODEL204 machine that issues in-line CA-ACF2 requests on behalf of other users. The requirement for the @SRF macro is the same as that for the SRF Logonid privilege. The following sample @SRF macro is for the security service machine:

@SRF SECUR204,MLID=VM,MODE=ABORT

For more information about @SRF, see the refer to the CA Technologies CA-ACF2 VM documentation.

Updating @RESTYPE macro

Add the resource codes specified in the RESOURC and ACCTRES parameters of the ACF2GEN macro to the @RESTYPE macro in the ACFFDR. The following example defines 204 and ACT as the new resource codes along with the standard CA-ACF2 codes for VM:

@RESTYPE SIZE=64K,KEYTYPE=(204,ACT,ALG,GRP,DIA,IUC,VMC)

For more information about the @RESTYPE macro, refer to the CA Technologies CA-ACF2 VM documentation.

Adding @CFDE macros

An @CFDE macro must be coded in the ACFFDR for each new Logonid record field specified in the ACCOUNT, RECSCTY, and PRTY parameters of ACF2GEN. The @CFDE macro defines both an external Logonid record field name used, for example, in the ACF command and the symbolic label given to the Logonid field in the LIDREC dsect. A sample follows illustrating how to code the @CFDE macros for the three fields.

The ACFFDR contains the following @CFDE macro entries:

@CFDE MACCOUNT,M204ACCT,CHAR, ALTER=SECURITY+ACCOUNT, LIST=ALL, FLAGS=RESTRICT,PRTN=1,RRTN=1 @CFDE MRECSCTY,M204SCTY,CHAR, ALTER=SECURITY, LIST=ALL, FLAGS=RESTRICT,PRTN=1,RRTN=1 @CFDE MPRTY,M204PRTY,CHAR, ALTER=SECURITY, LIST=ALL, FLAGS=RESTRICT,PRTN=1,RRTN=1

Note: M204ACCT, M204SCTY, and M204PRTY are symbolic names defined in the LIDREC dsect representing fields on the Logonid record. MACCOUNT, MRECSCTY, and MPRTY are the field names recognized by the ACF command.

For information about updating the LIDREC dsect, see the section Updating the LIDREC dsect. For more information about the @CFDE macro, refer to the CA Technologies CA-ACF2 VM documentation.

Updating the LIDREC dsect

The symbolic names described in the @CFDE macros must be added to the LIDREC dsect. These new fields are added to the user definition section by updating the USERLID or USERXLID copy members (or both) and saving the copy members in the ACF2VM MACLIB.

Continuing with the sample given above defining @CFDE entries, the following example defines the three fields in the LIDREC. Update the LIDREC dsect to include the following:

M204ACCT DS CL10 M204SCTY DS CL8 M204PRTY DS C

For more information about updating the user definition refer to the CA Technologies CA-ACF2 VM documentation.

Note: The ACF2GEN macro requires a position on the LIDREC where the ACCOUNT, RECSCTY, and PRTY fields are defined. After the ACFFDR has been assembled (the next step), the hexadecimal positions of the fields can be determined by reviewing the ACFFDR assembled listing.

Assembling and reloading the ACFFDR

After the ACFFDR has been updated and the LIDREC dsect changed, the ACFFDR is reassembled and reloaded in order for the new ACFFDR options to take effect. Reload the ACFFDR with the command:

ACFSERV RELOAD FDR

For more information about how to assemble and reload the ACFFDR, refer to the CA Technologies CA-ACF2 VM documentation.

Giving values to Model 204 Logonid record fields

After the ACFFDR has been reassembled and reloaded, the ACCOUNT, RECSCTY, and PRTY Logonid record fields need values that correspond with security requirements. Use the CA-ACF2 subcommand CHANGE to give values to these new fields. For example:

CHANGE M204USR1 MACCOUNT(ACCOUNTING) - MRECSCTY(RECSECKEY) - PRTY(S)

Writing rules

The CA-ACF2 VM Interface provides up to five types of rules for validating Model 204 user requests:

  • CCAIN SECPLIST parameter name (required)
  • Model 204 user privileges (required)
  • Login privilege (optional)
  • Account validation (optional)
  • Source entry rules for terminal security (optional)

CA-ACF2 Generalized Resource Rules are stored on the Information Storage database and consist of a 3-character type code, a 1-40 character name that identifies a particular resource, and a set of individual rule entries defining who can access the resource.

For SECPLIST, login, and user privileges, the 3-character type code defaults to 204 unless specified differently in the ACF2GEN parameter RESOURC. Account validation has no default resource code and is specified by ACCTRES. The 1- to 4-character name is the $KEY parameter specifying one of the fixed key names that describe Model 204 privileges or an account value. The UID string defines the users who can access the resource identified by the $KEY.

The resource code and key names for each of the four types of CA-ACF2 Generalized Resource Rules are detailed below. The source entry rules for terminal security are also explained.

For more information about ACF2GEN, refer to ACF2GEN macro. For more information about writing CA-ACF2 Generalized Resource and Source Entry Rules, refer to the CA-ACF2 VM documentation.

Writing SECPLIST rules

SECPLIST is a CCAIN parameter that identifies what ACF2GEN macro in ACF2PARM to use for a particular Model 204 job. All Model 204 jobs that activate the CA-ACF2 VM Interface go through SECPLIST validation. A virtual machine must be authorized to run Model 204 with a particular set of security parameters delineated by an ACF2GEN macro.

The resource code to validate SECPLIST is defined by the RESOURC parameter of ACF2GEN. RESOURC and defaults to 204 if not specified. The key name is PRIV.SECPLIST.DEFAULT or PRIV.SECPLIST.name. If CCAIN does not contain SECPLIST or the SECPLIST name is not found in ACF2PARM, the PRIV.SECPLIST.DEFAULT key name is used. If the name is found in ACF2PARM, it becomes part of the key name.

The following sample ACF session uses 204 as the resource code and the SECPLIST names of PROD, TEST and the default:

ACF SET RESOURCE(204) COMPILE $KEY(PRIV.SECPLIST.PROD) TYPE(204) UID(authorized user) ALLOW .... $KEY(PRIV.SECPLIST.TEST) TYPE(204) UID(authorized user) ALLOW .... $KEY(PRIV.SECPLIST.DEFAULT) TYPE(204) UID(authorized user) ALLOW .... STORE

Defining Model 204 user privileges

Rules that define Model 204 user privileges use the type code defined by the RESOURC parameter of ACF2GEN or default to 204. The five key names are for the five types of Model 204 privileges. Five sets of rules must be written. The fixed key names are:

  • PRIV.SUPER.USER
  • PRIV.SYSTEM.ADMIN
  • PRIV.CHANGE.FILE.PASSWORD
  • PRIV.SYSTEM.MANAGER
  • PRIV.OVERRIDE.RECORD.SECURITY

Commands for entering user privileges are similar to CA-ACF2 rules shown in the sample ACF session.

Validating the login

Validating a CA-ACF2 user’s privilege to log in to Model 204 is optional. This feature is activated if VALIDAT=LOGIN is coded in the ACF2GEN macro and results in a Generalized Resource Call. The resource code depends upon the RESOURC parameter of ACF2GEN. The fixed key name is: PRIV.LOGIN.M204.

Validating the account

The optional account validation feature is activated if ACCTRES, ACCOUNT, and VALIDAT=ACCOUNT are specified in the ACF2GEN macro. ACCTRES defines the resource code for the Generalized Resource Call. The key names are the account values themselves. For example, if a CA-ACF2 user entered FINANCE for an account, the key name is FINANCE.

ACF SET RESOURCE(ACT) COMPILE $KEY(FINANCE) TYPE(ACT) UID(authorized user) ALLOW .... $KEY(ACCOUNTING) TYPE(204) UID(authorized user) ALLOW .... STORE

Writing source entry rules

The CA-ACF2 VM Interface uses the z/OS virtual machine name as the physical terminal source of the user at Model 204 login time. If the CA-ACF2 Logonid specified on the Model 204 LOGIN command does not have a SOURCE field on its Logonid record, then no source entry rules are necessary. If the SOURCE field is present, source entry rules are required or else CAACF2 VM prevents the login.

A source entry rule correlates a physical source to a logical name. At login CAACF2 VM translates the physical source name to a logical name and then compares the logical name with the SOURCE field on the CA-ACF2 Logonid record. If the logical name and the SOURCE field match, login processing continues. If they do not match or no rule exists defining the physical source, the login is prevented.

For example, say z/OS user ID PSELLERS tries to log in to Model 204 using two different CA-ACF2 Logonids. The first time PSELLERS uses JANEDOE as the Model 204 user ID. If the JANEDOE Logonid record does not have a SOURCE field, CA-ACF2 VM does not perform terminal security validation and PSELLERS can log in to Model 204 if he knows the password and passes all other tests.

The second time PSELLERS enters the Logonid SMANAGER in the LOGIN command. The SMANAGER Logonid record has a SOURCE field with the value RM200. PSELLERS is denied entry to Model 204 unless an input source record or source group record is created that translates the physical source name of PSELLERS to the logical name of RM200. The following sample demonstrates the rule required:

ACF SET ENTRY(SRC) INSERT PSELLERS NEWDATA(RM200)

For more information about adding source entry rules, refer to the CA Technologies CA-ACF2 VM documentation.

Updating Model 204 EXECs

If Model 204 issues its own CA-ACF2 diagnoses Online and does not send its CA-ACF2 requests to the security service machine, a FILEDEF for the ACFSRF LOADLIB is required. Add the FILEDEF for the ACFSRF LOADLIB to the EXEC1 and EXEC2 EXECs that are part of the EXEC ONLINE command, and the EXECname EXECs that are part of the EXEC IFAM1 command:

FILEDEF ACFSRF DISK ACFSRF LOADLIB *

Without the FILEDEF, Model 204 receives the following messages:

DMSNXL589E MISSING FILEDEF FOR DDNAME ACFSRF ACFV8028 NUCXLOAD FAILED - R0 HAS RC FROM CMS

For more information about the ONLINE and IFAM1 EXEC, refer to the Rocket Model 204 Installation Guide for IBM z/VM.

Updating Model 204 CCAIN files

The CCAIN files for ONLINE and IFAM1 configurations might require the following changes:

  • Increase NSUBTKS by 1 if Model 204 is using the security service machine to issue CA-ACF2 diagnoses.
  • Include the new parameter SECPLIST to specify which set of Interface parameters to use to run Model 204.
Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=CA-ACF2_VM_interface&oldid=74005"