MCS Console Support Using External Security
Article ID: 57021
Updated On:
Products
Issue/Introduction
If your site wants to implement controls over the use of the MCS consoles, this document discusses how to accomplish this in an CA-ACF2 environment. These controls are applied to all consoles including SMCS and EMCS consoles. With support active, you can then control which logonids can use the consoles and which operator commands these users are allowed access to. The following procedure is needed to activate console controls.
Environment
Component: ACF2MS
Resolution
You control the status of the consoles from SYS1.PARMLIB. The CONSOLxx member has an operand, LOGON. LOGON has three settings OPTIONAL, REQUIRED and AUTO with the default being OPTIONAL. Select the setting appropriate to your security needs. From the external security standpoint, these settings have the following meaning:
OPTIONAL indicates that no signon of the console is required. Under this setting validation of commands coming from the console is ignored unless the operator has actually signed on. In this case, processing occurs normally. In CA-ACF2 processing a console that is not signed on receives a default logonid of +CONSOLE.
REQUIRED indicates that the console must sign on with a valid logonid in order to process commands.
AUTO indicates that consoles will automatically obtain a security environment at IPL (sign on). The consoles will have a logonid equal to their console name. This means that you have to define the appropriate logonids for the consoles if you select AUTO.
If AUTO is selected, create logonids for each console. The following command is an example of this:
INSERT console_name NAME(SYSA CONSOLE ) RESTRICT
Once you select either REQUIRED or AUTO, the CONSOLE resource class validates which logonids are allowed to access a console. This means that you have to create CA-ACF2 resource rules for each console in your environment allowing the designated logonids access to that console. The CONSOLE resource class defaults to a type code of SAF.
It is recommended that you give each protected resource its own unique type code. This means that you will have to create a GSO CLASMAP record to change this. For example:
SET CONTROL(GSO)
INSERT CLASMAP.console RESOURCE(CONSOLE) RSRCTYPE(CNS) ENTITYLN(8)
Once the CLASMAP is in place, you can then write the resource rules to allow users access to the consoles. An example of a rule allowing this access follows:
SET RESOURCE(CNS)
RECKEY SYSA0001 ADD($USERDATA(SYSA0001 Console Rule))
RECKEY SYSA0001 ADD(UID(user_uid) ALLOW))
Note: if you specify LOGON(AUTO), remember to allow the console name logonids access to the appropriate consoles.
After allowing the users to access the consoles themselves, you can control the operator commands that a user can issue. By default CA-ACF2 ignores this aspect of validation so if you want operator command validation active, you have to tell CA-ACF2 to do this. This requires that you create a SAFDEF record that overrides the OPERAUTH (MODE=IGNORE) SAFDEF. An example of the required record follows:
SET CONTROL(GSO)
INSERT SAFDEF.opercmd ID(OPERCMD) MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=OPERCMDS)
The same thing is needed to override the internal CONSOLE SAFDEF record:
INSERT SAFDEF.CONSOLE ID(CONSOLE) MODE(GLOBAL) RACROUTE(REQUEST=AUTH REQSTOR=ACF9CSFV CLASS=CONSOLE)
This SAFDEF requires that you write rules for the OPERCMDS resource class. As with the CONSOLE resource class, the OPERCMDS resource class defaults to a type code of SAF. We recommend that you add a CLASMAP for OPERCMDS to assign a unique type code to this class. For example:
SET CONTROL(GSO)
INSERT CLASMAP.opcmds RESOURCE(OPERCMDS) RSRCTYPE(OPR) ENTITYLN(39)
You must then write resource rules for the various operator commands under the type code of OPR so that the appropriate users can have access to use the commands. For example, controlling MVS commands might look something like this:
SET RESOURCE(OPR)
RECKEY MVS ADD(command_name UID(user_uid string) ALLOW)
RECKEY MVS ADD(- UID(operators uid string) ALLOW) <== this allows operators to issue all commands
Note: See the ACF2 Administrators Guide for more information on securing operator commands
For the purpose of efficiency and or if you have any masking in the $KEY of the resource rules, you may need to add type codes to the INFODIR record to allow CA-ACF2 to create in core directories for the rules. To do this, the following commands would be necessary:
SET CONTROL(GSO)
CHANGE INFODIR TYPES(R-RCNS,R-ROPR) ADD
To activate all of these changes in CA-ACF2, the following operator commands are necessary:
F ACF2,REFRESH(ALL)
F ACF2,REBUILD(OPR)
F ACF2,REBUILD(CNS)
Feedback
