Confusion with the CA Cleanup Database Reload 'ALL' function.

book

Article ID: 36168

calendar_today

Updated On:

Products

CA Cleanup

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

Release: ACFCLN00200-12.1-Cleanup-for CA-ACF2
Component: