Confusion with the CA Cleanup Database Reload 'ALL' function.
Article ID: 36168
Updated On:
Products
Issue/Introduction
Summary:
Confusion with the CA Cleanup Database Reload 'ALL' function. The scenario, a Department Acid, 'EDVSYS', is Owner of 'MQADMIN(TMQ)'. ACID A40TMQ2 has the following MQADMIN Permissions:
============================================
MQADMIN(TMQH.ASFDASDF ) ACCESS(NONE)
MQADMIN(TMQH.NO. ) ACCESS(NONE)
MQADMIN(TMQH.NO.QMGR. ) ACCESS(NONE)
MQADMIN(TMQ2. ) ACCESS(NONE)
MQADMIN(TMQ2.ASFDSAFSAFSAFD) ACCESS(READ)
MQADMIN(TMQ2.N ) ACCESS(NONE)
MQADMIN(TMQ2.NO. ) ACCESS(NONE)
MQADMIN(TMQ2.NO.QMGR. ) ACCESS(NONE)
MQADMIN(TMQ2.NO.QMGR. ) ACCESS(READ)
MQADMIN(TMQ2.NO.QMGR.CHECKS) ACCESS(READ)
MQADMIN(TMQ2.NX. ) ACCESS(NONE)
MQADMIN(TMQ2.X.NO ) ACCESS(NONE)
MQADMIN(TMQ2.X.NONE.QMGR. ) ACCESS(READ)
MQADMIN(TMQ2.X.NONE.QMGR. ) ACCESS(NONE)
MQADMIN(TMQ2.XNO.QMGR. ) ACCESS(NONE)
MQADMIN(TMQ2.XXX.NO.XXXX. ) ACCESS(NONE)
MQADMIN(TMQ2.XZZZ.NO ) ACCESS(NONE)
MQADMIN(TMQ2.ZZZ ) ACCESS(NONE)
MQADMIN(TMQ2NO ) ACCESS(NONE)
MQADMIN(TMQ2XNOX ) ACCESS(NONE)
============================================
After a RELOAD by the Central Administrator User, only the following Permissions seem to exist in the Cleanup Database:
================================================
15008* A40TMQT MQADMIN TMQH.ASFDASDF
15008* A40TMQT MQADMIN TMQ2.
15008* A40TMQT MQADMIN TMQ2.ASFDSAFSAFSAFD
15008* A40TMQT MQADMIN TMQ2.N
15008* A40TMQT MQADMIN TMQ2.NX.
15008* A40TMQT MQADMIN TMQ2.X.NO
15008* A40TMQT MQADMIN TMQ2.X.NONE.QMGR.
15008* A40TMQT MQADMIN TMQ2.X.NONE.QMGR.
15008* A40TMQT MQADMIN TMQ2.XNO.QMGR.
15008* A40TMQT MQADMIN TMQ2.XXX.NO.XXXX.
15008* A40TMQT MQADMIN TMQ2.XZZZ.NO
15008* A40TMQT MQADMIN TMQ2.ZZZ
15008* A40TMQT MQADMIN TMQ2NO
15008* A40TMQT MQADMIN TMQ2XNOX
================================================
If the String is 'TMQx.NO.xxxxx', then it's not added. Characters 'NO' are in positions six and seven. This behavior exists for other similar Strings also, and some Strings are missing altogether in the Cleanup Database.
Instructions:
The behavior you are seeing exhibited by the Cleanup Database Reload 'ALL' function is due to the following code in Cleanup:
===========================================================================
*
CLC DBCLASS,=CL8'MQADMIN' Special case ? $R21
BNE PP550 N, skip it $R21
LA R1,DBRESN+1 Point to name + 1 $R21
LA R0,5 Max possible $R21
PP520 CLC =C'.NO.',0(R1) Found switch profile? $R21
BE PP800 Y, skip it $R21
===========================================================================
...basically:
===============================================================================
"Each 'NO.*' Switch Profile that WebSphere MQ detects, turns off the checking for that type of Resource. Switch Profiles are 'activated' during the Startup of the Queue Manager."
If you change the Switch Profiles while any affected Queue Managers are running, you can get WebSphere MQ to recognise the changes by issuing the WebSphere 'MQ REFRESH SECURITY' command."
===============================================================================
So it would appear that these are not used as actual PERMITs, and therefore their usage is not tracked, but is 'excluded' from the Cleanup Database.
The following two IBM references explain this further, see:
===========================================================================
www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqsav.doc/z
s12140_.htm
------------------------------------------------------------------------------------------------------------------------------------------
How switches work
To set off a security switch, define a NO.* switch profile for it. You can override a NO.* profile set at the queue-sharing group level by defining a YES.* profile for a queue manager.
To set off a security switch, you need to define a NO.* switch profile for it. The existence of a NO.* profile means that security checks are not performed for that type of resource, unless you choose to override a queue-sharing group level setting on a particular queue manager. This is described in Overriding queue-sharing group level settings.
If your queue manager is not a member of a queue-sharing group, you do not need to define any queue-sharing group level profiles or any override profiles. However, you must remember to define these profiles if the queue manager joins a queue-sharing group at a later date.
Each NO.* switch profile that WebSphere MQ detects turns off the checking for that type of resource. Switch profiles are activated during startup of the queue manager. If you change the switch profiles while any affected queue managers are running, you can get WebSphere MQ to recognize the changes by issuing the WebSphere MQ REFRESH SECURITY command.
The switch profiles must always be defined in the MQADMIN or MXADMIN class. Do not define them in the GMQADMIN or GMXADMIN class. Tables Table 1 and Table 1 show the valid switch profiles and the security type they control.
Overriding queue-sharing group level settings
You can override queue-sharing group level security settings for a particular queue manager that is a member of that group. If you want to perform queue manager checks on an individual queue manager that are not performed on other queue managers in the group, use the (qmgr-name.YES.*) switch profiles.
Conversely, if you do not want to perform a certain check on one particular queue manager within a queue-sharing group, define a (qmgr-name.NO.*) profile for that particular resource type on the queue manager, and do not define a profile for the queue-sharing group. (WebSphere MQ only checks for a queue-sharing group level profile if it does not find a queue manager level profile.)
------------------------------------------------------------------------------------------------------------------------------------------
...and:
www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqsav.doc/z
s12200_.htm
-----------------------------------------------------------------------------------------------------------------------------------------
An example of defining switches
Different WebSphere MQ subsystems have different security requirements, which can be implemented using different switch profiles.
Four WebSphere MQ subsystems have been defined:
MQP1 (a production system)
MQP2 (a production system)
MQD1 (a development system)
MQT1 (a test system)
All four queue managers are members of queue-sharing group QS01. All WebSphere MQ RACF classes have been defined and activated.
These subsystems have different security requirements:
* The production systems require full WebSphere MQ security checking to
be active at queue-sharing group level on both systems.
This is done by specifying the following profile:
RDEFINE MQADMIN QS01.NO.QMGR.CHECKS
This sets queue-sharing group level checking for all the queue managers in the queue-sharing group.
You do not need to define any other switch profiles for the production queue managers because you
want to check everything for these systems.
* Test queue manager MQT1 also requires full security checking. However, because you might want to
change this later, security can be defined at queue-manager level so that you can change the security
settings for this queue manager without affecting the other members of the queue-sharing group.
This is done by defining the NO.QSG.CHECKS profile for MQT1 as follows:
RDEFINE MQADMIN MQT1.NO.QSG.CHECKS
* Development queue manager MQD1 has different security requirements from the rest of the queue-
sharing group. It requires only connection and queue security to be active.
This is done by defining a MQD1.YES.QMGR.CHECKS profile for this queue manager, and then defining
the following profiles to switch off security checking for the resources that do not need to be checked:
RDEFINE MQADMIN MQD1.NO.CMD.CHECKS
RDEFINE MQADMIN MQD1.NO.CMD.RESC.CHECKS
RDEFINE MQADMIN MQD1.NO.PROCESS.CHECKS
RDEFINE MQADMIN MQD1.NO.NLIST.CHECKS
RDEFINE MQADMIN MQD1.NO.CONTEXT.CHECKS
RDEFINE MQADMIN MQD1.NO.ALTERNATE.USER.CHECKS
When the queue manager is active, you can display the current security settings by issuing the DISPLAY
SECURITY MQSC command.
You can also change the switch settings when the queue manager is running by defining or deleting the appropriate switch profile in the MQADMIN class. To make the changes to the switch settings active, you must issue the REFRESH SECURITY command for the MQADMIN class.
See Refreshing queue manager security on z/OS for more details about using the DISPLAY SECURITY and REFRESH SECURITY commands.
-----------------------------------------------------------------------------------------------------------------------------------------
Additional Information:
Please refer to the IBM web site for the following:
www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqsav.doc/z
s12140_.htm
…and…
www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqsav.doc/z
s12200_.htm
Environment
Component:
Feedback
