In simple terms how to deploy command group security via SAF.
The documentation says that SAF can only override internal security if internal security allows the access. In other words, if internal security forbids the access then SAF cannot override that. Is that correct?
So to give SAF (RACF) full control, then, internally, grant all user groups access to all command groups. Then set up RACF profiles of the form SV.RESN.CMDGROUP.xxx ??
If not setting up the internal defintions, it never gets as far as RACF ?
Release : 16.0
To use external security with SYSVIEW command groups. The following steps may be able to accomplish that.
1. Run job *.CNM4BSAM(GSVUDEFR), which will add field GSVUSER to the CSDATA segment for the User's profile. Point the user to a specific User Group in SYSVIEW. This can be set up to something like CICSGRP so the folks that support CICS will have the same User Group and then specific Command Groups can be assigned to that User Group.
2. Set 'Security-Validation' in the System Configuration file to USERDEF.
3. Specify in SYSVIEW a 'SAF Entity Class Name' in the External Security Options for the User Group to point the users to.
4. In the External Security Options, insure 'Bypass internal security call' is set to YES.
5. In the Security Miscellaneous section, verify it's having 'Fail command if failed in any CMDGROUP' set to NO.
To use command groups be specified in the Command Groups Section must be in a User Group. The SV.RESN.CMDGROUP.xxxxx call will be made for any groups listed there.
If everyone needs to end up eventually in the DEFAULT group (because nobody should be in a separated out into several other SYSVIEW User Groups), then in DEFAULT specify the whole list of command group names, all with A, then code RACF accordingly to control which ones they really get access to.
So in RACF maybe have something like this:
SV.RESN.CMDGROUP.* UACC(NONE) to disallow all of them
SV.RESN.CMDGROUP.GSVCTG UACC(READ) and so on for whatever other groups you want them to have.
'Fail command if failed in any CMDGROUP' only comes into play when the same command is included in multiple command groups (the GSVxxxx ones we provide are not like this, each command is only in one group). If creating two command groups and included CTGSET command in both of them, and added both cmd groups to a user group but one with A and one with F, should CTGSET be allowed or failed? That's what this option answers.
Regarding CMDGROUP access vs. CMND access:
The purpose of command groups is to spare the pain of authorizing hundreds of commands one by one. So when having access to a CMDGROUP by extension have access to all the commands included within it. Those commands will not be checked individually (no SV.CMND call will be made).
Be aware of not having SAF calls for users in the DEFAULT group. Because it showed showed at the External security section for DEFAULT:
SAF Entity Class Name NONE
NONE says don't make SAF calls. That may have been the one that changed to FACILITY.
That is why it wasnt showing the GSV4204I diagnostic warn mode messages either, until switching to the ADMIN group that already had that class name specified.
Additional note regarding Command Groups; to use them with SAF it's needed to specify 'Bypass internal security call' NO in the External Security Section, else the SAF checks for CMDGROUP will not occur.
This is the help for that field:
| Bypass internal | Specify a value of YES if you want access to be |
| security call | determined by external security only. Internal |
| | security will not be called prior to external security.|
| | Normally access that was failed by internal security |
| | can not be overridden and allowed by external security.|
| | This option allows you to use external security |
| | exclusively without having to allow all access in |
| | the DEFAULT internal security group. |
| | |
| | Note, when you set this option, Command Groups defined |
| | in internal security do not participate in |
| | determining command/subcommand access. |
| | |
| | Default = NO |
| | |
This also means it's needed to ensure all Internal security defs allow access to everything, so that the SAF call result governs.
The STIG states
"To complete the identification and remediation tasks in this article, the user that performs the audits must possess a SYSVIEW administrator user ID or a user ID that is a member of the SYSVIEW ADMIN group. The user must also possess READ permission to the SYSVIEW CNM4BSEC file. To determine if the user ID possesses the required permissions, see STIG ID - BSYSR007: Protect the SYSVIEW SECURITY Command and CNM4BSEC Data Set Using RACF."
And once the tasks are completed, remove the access to CNM4BSEC so no one else can update security.