Step 1. Implement IOA Security

Use the following steps that correspond to the installation steps in ICE, to implement IOA security.

Step 1.1 Grant Access Permissions

Authorizations to access IOA datasets are optionally defined during IOA installation. It is recommended that this step be completed before proceeding with security implementation. For information about how to grant users access to IOA datasets, see the IOA installation chapter in the INCONTROL for z/OS Installation Guide: Installing.

Step 1.2 Customize Security Parameters

The following table describes the required parameters and their values:

Table 11 Customized Security Parameters

Parameter	Description
DEFMCHKI	When choosing a definition mode as COND to any of the IOA security modules, use qname together with the value given to this parameter as the high level qualifier, to determine the real definition mode to be used.
SECTOLI	Determines the IOA action to perform if your security product is inactive or a specific resource is not defined to the security product. Valid values are: YES – Perform the action. NO – Do not perform the action.
IOACLASS	Indicates the FACILITY class or a user‑defined class. This is the class used by the IOA security interface for authority checks of IOA protected elements. Note: To use a user-defined class, you must define the class to your security product. For more information on how to define a resource class, see the IBM RACF:SPL Guide, TopSecret Implementation Guide, or CA-ACF2 Administrator’s Guide.
IOAXCLAS	Indicates the extended FACILITY class or a user-defined class. This class must support long entity names and used by the IOA security interface for authority checks of IOA protected elements. Note: To use a user-defined class, you must define the class to your security product. For more information on how to define a resource class, see the IBM RACF:SPL Guide, TopSecret Implementation Guide, or CA-ACF2 Administrator’s Guide.
IOAXCLAS
IOATCBS	IOA Online monitor task level security NO – Operate all tasks in the IOA Online monitor with the IOAOMON or CTDOMON user ID authority. YES – Set each task in the IOA Online monitor to be activated with the logged on user authorizations.
IOACLNT	Determines the type of Login to the mainframe for the CONTROL-D/Web Access Server Communication users. NO – Single Login YES – Automatic Login For more information see the Control-D WebAccess Server Administrator's Guide.
Mode Definition	Specify one of the following values to determine the definition mode for the IOA security modules: COND – Conditional Definition mode. Default. BASIC – Basic Definition mode. EXTEND – Extended Definition mode.
DFMI06	Definition mode for the IOASE06 IOA security module
DFMI07	Definition mode for the IOASE07 IOA security module
DFMI09	Definition mode for the IOASE09 IOA security module
DFMI12	Definition mode for the IOASE12 IOA security module
DFMI16	Definition mode for the IOASE16 IOA security module
DFMI32	Definition mode for the IOASE32 IOA security module
DFMI40	Definition mode for the IOASE40 IOA security module
DFMI42	Definition mode for the IOASE42 IOA security module. This module is always in EXTEND mode.
ASAPPL	Name of Control-D Application Server started task. Add this parameter if you want to use the PassTicket feature for Control-D Application Server users.
VMONAPPL	Name of IOAVMON started task. Add this parameter if you want to use the PassTicket feature for VMON users.
UNIQID	Specify one of the following values to determine the uniqueness of the user ID: Y – User ID is unique, so that no more than one user can logon to an IOA application server with the same user ID. N, or left blank – User ID is not unique, so that more than one user can logon to an IOA application server with the same user ID. Default.

Step 1.3 Save Security Parameters into Product

This step saves all the security parameters specified for IOA.

When this step is completed, the Status column is automatically updated to COMPLETE.

Step 1.4 Select Security Product Interface

The IOA installation supports RACF, TopSecret, and ACF2. The IOA security interface automatically determines which security product is being used at runtime. More than one security product can be selected.

Specify the security products you want to support, and follow the instructions in this step.

Step 1.5 Build IOA RACF Interface

The IOASRACF job in the IOA INSTWORK library creates the IOA security interface module for RACF.

Submit the job. All steps of this job must end with a condition code of 4 or less.

Step 1.6 Build IOA TopSecret Interface

The IOASTSS job in the IOA INSTWORK library creates the IOA security interface module for TopSecret.

Submit the job. All steps of this job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and ensure that the proper dataset names are set.

Step 1.7 Build IOA ACF2 Interface

The IOASSAF job in the IOA INSTWORK library creates the IOA security interface module for ACF2.

Submit the job. All steps of this job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and ensure that the proper dataset names are set.

Step 1.8 Activating IOA and INCONTROL Product Security

To activate the IOA security or any INCONTROL product security, the security administrator must define the following entities in the relevant security product:

For IOA, define entity $$SECIOA.qname
For Control‑M, define entity $$SECCTM.qname
For Control‑D, define entity $$SECCTD.qname
For Control‑O, define entity $$SECCTO.qname
For Control‑M/Analyzer, define entity $$SECCTB.qname
For Control‑M/Tape, define entity $$SECCTT.qname

where qname is defined during the IOA installation process.

BMC recommends that you define the entities as fully qualified in order to distinguish between different environments, and define the entities with universal READ access.

The class which these entities must be defined are as follows:

RACF — The class is FACILITY
TopSecret — The class is IBMFAC
ACF2 — The resource type is CMF

Parent Topic

Implementing IOA Security