Authorize the CICS DA client IDs
About this task
- Authorize the CICS DA client IDs
- Authorize the CICS DA client IDs
- The authority to run jobs on the MVS™ images to be discovered MVS console access
- A TSO segment is required
- The authority to issue the "DISPLAY TCPIP" z/OS® command
- To obtain CICSplex connection and other CPSM data, the authority to log into and query any web user interface servers that DA will connect to
Procedure
- If CICS DA
command protection is enabled, the CICS DA
user must be authorized to run the discovery function.
The CICS DA command protection is in addition to any underlying ESM checks that exist on data sets or within the CICSPlex® SM.
To enable this checking, the FACILITY class must be activated on the target MVS system. See the appropriate documentation for your external security manager for details. When the class is activated, you can define security profiles to start protecting the discovery utility.
For example, RACF® users might use the following TSO commands:
where server_id is the CICS DA server ID.RDEFINE FACILITY CPH.server_id.MODEL.POLICY.** UACC(NONE) PERMIT CPH.server_id.MODEL.POLICY.** CLASS(FACILITY) ID(SYSPROG) ACCESS(UPDATE) RDEFINE FACILITY CPH.server_id.MODEL.POLICY.APPL1 UACC(NONE) PERMIT CPH.server_id.MODEL.POLICY.APPL1 CLASS(FACILITY) ID(SYSPROG,TSTUSR1) ACCESS(UPDATE) SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH
In the example, the first pair of commands defines a generic profile that grants access for user, or group, SYSPROG to modify any start or stop policy. The second pair of commands defines a discrete profile that protects CICS model entities with an APPLID of APPL1. The users, or groups, SYSPROG, and TSTUSR1, are given access to change the start and stop policy for CICS model entities with an APPLID of APPL1.
The sequence of commands in the example grant permission for the user, or group, SYSPROG to change any start or stop policy on CICS DA servers with an identity of server_id, and the user TSTUSR1 to change the start or stop policy only on CICS model entities with an APPLID of APPL1.
The following table lists the CICS DA FACILITY class profiles in the ESM FACILITY classes, and their uses:Note: If you did not specify a server identifier in the DA properties file, then the profiles must start with CPH. instead of CPH.server_idTable 1. CICS DA FACILITY class profiles in the ESM FACILITY classes, and their uses FACILITY class profile Use CPH.server_id.DISCOVER.MVS This FACILITY class profile is not part of command protection. However, it is used by the server process during discovery. READ access level is required. CPH.server_id.** Enable/disable all user command actions. ALTER access level is required. CPH.server_id.DISCOVER Enables clients to invoke discovery for the named server. READ access level is required. CPH.server_id.MODEL Enables clients to read, or act on, the CICS DA model. This profile can have different access levels: - READ
- Enables clients to obtain the discovered model.
- UPDATE
- Enables clients to change discovered model elements. (UPDATE is required to change JES member name, change CMAS network name, and add and remove tags).
- ALTER
- Enables clients to delete discovered model elements.
CPH.server_id.MODEL.POLICY.* Enables clients to change the start and stop policies with specific APPLIDs (or * for all). UPDATE access level is required. CPH.server_id.MODEL.TAG.CREATE Enables clients to create new tags. This class requires UPDATE access. CPH.server_id.MODEL.TRANSFRM Enables clients to create, update, and delete the name transform rule sets. This profile can have different access levels: - UPDATE
- Enables clients to create or update name transform rule sets.
- ALTER
- Enables clients to delete name transform rule sets.
CPH.server_id.REGION.CLONE Enables clients to clone regions. This class requires READ access. CPH.server_id.REGION.PLEXIFY Enables clients to add a region to a CICSplex. This class requires READ access. CPH.server_id.REGION.CREATE Enables clients to create new regions. This class requires READ access. - The CICS DA
user must be authorized to run the discovery function on MVS images. The CICS DA user must have authority to discover subsystems on all MVS images. If the user does not have authority to access an MVS image, the subsystems on that MVS image are not shown in the model.Important:If two CICS DA users run the discovery function and they have different MVS image access authority, the discovery function results might be different. You can define a CICS DA discovery group and add the relevant CICS DA users to ensure that they all have the same authority.
The CICS DA user requires READ access to a FACILITY class resource called CPH.server_id.DISCOVER.MVS.system_name where system_name is the name of the z/OS system, and server-id is the optional server identity name. The server identity name is specified in the CICS DA properties file. You can use the server identity name to specify different command protection on multiple servers that are running in the same Sysplex. If you did not specify a server identity in the properties file, you can omit server-id from the following commands.
To enable this checking, the FACILITY class must be activated on the target MVS system. See the appropriate documentation for your external security manager for details. When the class is activated, you can define security profiles to start protecting the discovery utility.
For example, RACF users might enter the following TSO commands:
where server_id is the CICS DA server ID.RDEFINE FACILITY CPH.server_id.DISCOVER.MVS.** UACC(NONE) PERMIT CPH.server_id.DISCOVER.MVS.** CLASS(FACILITY) ID(SYSPROG) ACCESS(READ) RDEFINE FACILITY CPH.server_id.DISCOVER.MVS.TST1 UACC(NONE) PERMIT CPH.server_id.DISCOVER.MVS.TST1 CLASS(FACILITY) ID(SYSPROG,TSTUSR1) ACCESS(READ) SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH
In the example, the first pair of commands defines a generic profile that grants access for user, or group, SYSPROG to run discovery on any system. The second pair of commands defines a discrete profile that protects a system that is called TST1. The users, or groups, SYSPROG, and TSTUSR1, are given access to TST1.
The sequence of commands in the example grant permission for the user, or group, SYSPROG to run discovery on any system, and the user TSTUSR1 to run discovery only on system TST1.
CICS DA uses the UNIX System Services host service to query the domain name server and resolve the IP address to a name. You must ensure that any running discovery has authority to start the UNIX System Services host command.
- The CICS DA
user must have MVS console access.
CICS DA uses the MVS console interface for some actions, so the CICS DA users, require access to the commands issued by CICS DA, and also authority to access the console. RACF users can control access to the console by using a suitable profile in the OPERCMDS class. For example:
RDEFINE OPERCMDS MVS.MCSOPER.console_name UACC(NONE) PERMIT MVS.MCSOPER.console_name CLASS(OPERCMDS) ID(cics-da-user) ACCESS(READ) SETROPTS RACLIST(OPERCMDS) GENERIC(OPERCMDS) REFRESH
console_name is the name of the console, and cics-da-user is the user authorized to use the console.
The console name that is used by the CICS DA user is specified on the CICS DA connection in the z/OS console setting.
You must ensure that only the specified user is allowed to use the console, especially if CICS terminal definitions or autoinstalled consoles use preset security.
- The CICS DA
user must have a TSO segment. Create a TSO segment for the user
ID that the CICS DA server
job is running under, and make the user ID a member of the TSOAUTH
class. The length of the user ID must be 7 characters or less
before you can define the TSO segment. CONSOLE COMMAND authority is
granted by using the CONSOLE profile in the TSOAUTH class. For
example:
RDEFINE TSOAUTH CONSOLE UACC(NONE) SETROPTS RACLIST(TSOAUTH) PERMIT CONSOLE CLASS(TSOAUTH) ID(...) ACCESS(READ) SETROPTS RACLIST(TSOAUTH) REFRESH
Depending on your security manager, more setup might be required to use the console. For example, RACF users might require an OPERPARM segment that is associated with the TSO user ID. For more information, see z/OS MVS Planning: Operations.
- The CICS DA user must have the authority to
issue certain z/OS commands. To run the discovery operation, the CICS DA user must have access to the following z/OS commands:
- DISPLAY TCPIP
- Class: OPERCMDS resource name
- Resource name: MVS.DISPLAY.TCPIP
- Access required: READ
To initiate a shutdown of a CICS region from CICS DA, users must have access to:- Modify cics_jobname
- Class: OPERCMDS
- Resource name: MVS.MODIFY.cics_jobname
- Access required: UPDATE
Note: For started tasks and started jobs, the profile name might be slightly different. For more information, see z/OS MVS Planning: Operations. - The CICS DA user must have full access to all CICSPlex SM and CICS objects in the external security manager. This authorization step is required to run the discovery function. The CICS DA user requires authorization to access all CICSPlex SM resources, otherwise the discovery operation might fail, or return unexpected results. For more information about implementing CICSPlex SM security, see CICSPlex SM security.
- Authorize CICS DA client IDs to submit jobs when
provisioning.
Every user that submits jobs through the CICS DA server, for example to clone CICS regions, must have access to the CICS DA server SUBMIT profile in the SURROGAT class.
The following example shows the RACF commands that you might use to enable this access, where CPHSRV is the CICS DA server user ID and cics-da-user is the client user ID:RDEFINE SURROGAT cics-da-user.SUBMIT OWNER(cics-da-user) (UACC(NONE) PERMIT cics-da-user.SUBMIT CLASS(SURROGAT) ID(CPHSRV) ACCESS(READ) SETR RACLIST(SURROGAT) REFRESH
For more information about SURROGAT job submission, see the related links.
What to do next
authorize_users_cicsda_clientid.html |
