The RESLEVEL security profile

We can define a special profile in the MQADMIN or MXADMIN class to control the number of user IDs checked for API-resource security. This profile is called the RESLEVEL profile. How this profile affects API-resource security depends on how you access IBM MQ .

hlq.RESLEVEL

Where hlq can be either ssid (subsystem ID) or qsg (queue sharing group ID).

• The user ID of the connecting task for batch connections
• The CICS address space user ID for CICS connections
• The IMS region address space user ID for IMS connections
• The channel initiator address space user ID for channel initiator connections

Attention: RESLEVEL is a very powerful option; it can cause the bypassing of all resource security checks for a particular connection.

If we do not have a RESLEVEL profile defined, we must be careful that no other profile in the MQADMIN class matches hlq.RESLEVEL. For example, if you have a profile in MQADMIN called hlq.** and no hlq.RESLEVEL profile, beware of the consequences of the hlq.** profile because it is used for the RESLEVEL check.

Define an hlq.RESLEVEL profile and set the UACC to NONE, rather than have no RESLEVEL profile at all. Have as few users or groups in the access list as possible. For details about how to audit RESLEVEL access, see Auditing considerations on z/OS.

If we are using queue manager level security only, IBM MQ performs RESLEVEL checks against the qmgr-name.RESLEVEL profile. If we are using queue sharing group level security only, IBM MQ performs RESLEVEL checks against the qsg-name.RESLEVEL profile. If we are using a combination of both queue manager and queue sharing group level security, IBM MQ first checks for the existence of a RESLEVEL profile at queue manager level. If it does not find one, it checks for a RESLEVEL profile at queue sharing group level.

If it cannot find a RESLEVEL profile, IBM MQ enables checking of both the job and task (or alternate user) ID for a CICS or an IMS connection. For a batch connection, IBM MQ enables checking of the job (or alternate) user ID. For the channel initiator, IBM MQ enables checking of the channel user ID and the MCA (or alternate) user ID.

If there is a RESLEVEL profile, the level of checking depends on the environment and access level for the profile.

Remember that if your queue manager is a member of a queue sharing group and we do not define this profile at queue manager level, there might be one defined at queue sharing group level that will affect the level of checking.To activate the checking of two user IDs, you define a RESLEVEL profile (prefixed with either the queue manager name of the queue sharing group name) with a UACC(NONE) and ensure that the relevant users do not have access granted against this profile.

When you consider the access that the channel initiator's user ID has to RESLEVEL, remember that the connection established by the channel initiator is also the connection used by the channels. A setting that causes the bypassing of all resource security checks for the channel initiator's user ID effectively bypasses security checks for all channels. If the channel initiator's user ID access to RESLEVEL is something other than NONE, then only one user ID (for an access level of READ or UPDATE) or no user IDs (for an access level of CONTROL or ALTER) is checked for access. If you grant the channel initiator's user ID an access level other than NONE to RESLEVEL, be sure that you understand the effect of this setting on the security checks done for channels.

Use the RESLEVEL profile means that normal security audit records are not taken. For example, if you put UAUDIT on a user, the access to the hlq.RESLEVEL profile in MQADMIN is not audited.

If we use the RACF WARNING option on the hlq.RESLEVEL profile, no RACF warning messages are produced for profiles in the RESLEVEL class.

Security checking for report messages such as CODs are controlled by the RESLEVEL profile associated with the originating application. For example, if a batch job's userid has CONTROL or ALTER authority to a RESLEVEL profile, then all resource checking performed by the batch job are bypassed, including the security check of report messages.

If we change the RESLEVEL profile, users must disconnect and connect again before the change takes place. (This includes stopping and restarting the channel initiator if the access that the distributed queuing address space user ID has to the RESLEVEL profile is changed.)

To switch RESLEVEL auditing off, use the RESAUDIT system parameter.

• RESLEVEL and batch connections
  By default, when an IBM MQ resource is being accessed through batch and batch-type connections, the user must be authorized to access that resource for the particular operation. We can bypass the security check by setting up an appropriate RESLEVEL definition.
• RESLEVEL and system functions
  The application of RESLEVEL to the operation and control panels, and to CSQUTIL.
• RESLEVEL and CICS connections
  By default, when an API-resource security check is made on a CICS connection, two user IDs are checked. We can change which user IDs are checked by setting up a RESLEVEL profile.
• RESLEVEL and IMS connections
  By default, when an API-resource security check is made for an IMS connection, two user IDs are checked. We can change which user IDs are checked by setting up a RESLEVEL profile.
• RESLEVEL and the channel initiator connection
  By default, when an API-resource security check is made by the channel initiator, two user IDs are checked. We can change which user IDs are checked by setting up a RESLEVEL profile.
• RESLEVEL and intra-group queuing
  By default, when an API-resource security check is made by the intra-group queuing agent, two user IDs are checked to see if access is allowed to the resource. We can change which user IDs are checked by setting up an RESLEVEL profile.
• RESLEVEL and the user IDs checked
  Example of setting a RESLEVEL profile and granting access to it.

Parent topic: Set up security on z/OS