Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hello,

No problem with RESLEVEL. We have RACF errors on other local queues . 

I created QA on MQT0 points to cluster queue ( and I got warning there) . I would like to restrict the access to cluster queue thru this QA only. 

As far as I understand I also can remove access permission for users  from cluster XMIT queue .

Yulia.

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hi Yulia,

It is hard to guess when I don't get to see what you can see. To help me be able to guess a little more accurately could you answer these outstanding questions.

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N)
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier.
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier.
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N)
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N)

You should have no need to grant any application user access to the cluster transmit queue directly. 

Cheers,
Morag

Hello,

No problem with RESLEVEL. We have RACF errors on other local queues . 

I created QA on MQT0 points to cluster queue ( and I got warning there) . I would like to restrict the access to cluster queue thru this QA only. 

As far as I understand I also can remove access permission for users  from cluster XMIT queue .

Yulia.

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N) Yes
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier. I expected to see a warning "temporary access" but I cannot see it. 
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier. Yes. And a warning "temporary access" is displayed . 
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N) Yes
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N) Yes but with warningI would like to understand what to define in order to close an access to cluster local name from ZOS. As far as I understand I should get permission  writing to transmit queue to MQ master user only and writing to cluster local name to anyone. Is it write ? Yulia

Hi Yulia,

It is hard to guess when I don't get to see what you can see. To help me be able to guess a little more accurately could you answer these outstanding questions.

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N)
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier.
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier.
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N)
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N)

You should have no need to grant any application user access to the cluster transmit queue directly. 

Cheers,
Morag

Hello,

No problem with RESLEVEL. We have RACF errors on other local queues . 

I created QA on MQT0 points to cluster queue ( and I got warning there) . I would like to restrict the access to cluster queue thru this QA only. 

As far as I understand I also can remove access permission for users  from cluster XMIT queue .

Yulia.

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hi Yulia,

Still missing one important fact here. Question 2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - I need to know whether the application is failing or not.

I am guessing that the answer is no, and that the application receives a zero reason code when it opens the queue using the QLOCAL name. Please could you confirm this?

Going with the guess that the application is succeeding to open the queue using the QLOCAL name, and the fact that there are generic profiles that would match the QLOCAL name, we should take a look at those next.

Could you please tell us if there are permissions that would match the user id in question on the generic profiles that match the QLOCAL name. This is where I suspect the access is allowed. Could you confirm?

You have asked a couple of times what you need to define, but I think you already have what you need defined. You just need to remove some permissions that are granted on the profile that is already defined.

As far as permissions on the transmission queue, these should not be needed by an application user id.

You last sentence says something about "writing to cluster local name to anyone". I think what we're trying to do is to NOT allow everyone to have put access (UPDATE) to the local queue name. I think you want to restrict access to that queue and only allow access through the QALIAS name? Perhaps you can confirm again that this is your intent?

Cheers,
Morag

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N) Yes
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier. I expected to see a warning "temporary access" but I cannot see it. 
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier. Yes. And a warning "temporary access" is displayed . 
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N) Yes
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N) Yes but with warningI would like to understand what to define in order to close an access to cluster local name from ZOS. As far as I understand I should get permission  writing to transmit queue to MQ master user only and writing to cluster local name to anyone. Is it write ? Yulia

Hi Yulia,

It is hard to guess when I don't get to see what you can see. To help me be able to guess a little more accurately could you answer these outstanding questions.

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N)
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier.
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier.
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N)
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N)

You should have no need to grant any application user access to the cluster transmit queue directly. 

Cheers,
Morag

Hello,

No problem with RESLEVEL. We have RACF errors on other local queues . 

I created QA on MQT0 points to cluster queue ( and I got warning there) . I would like to restrict the access to cluster queue thru this QA only. 

As far as I understand I also can remove access permission for users  from cluster XMIT queue .

Yulia.

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

Hello,

NOT allow everyone to have put access (UPDATE) to the local queue name. I think you want to restrict access to that queue and only allow access through the QALIAS name. Yes this is the idea.

I only need to verify that profile MQT0.<cluster local name> should prevent putting messages w/o QALIAS . So I can ask RACF guys to recheck what they defined. 

Thanks for your help.

Yulia 

Hi Yulia,

Still missing one important fact here. Question 2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - I need to know whether the application is failing or not.

I am guessing that the answer is no, and that the application receives a zero reason code when it opens the queue using the QLOCAL name. Please could you confirm this?

Going with the guess that the application is succeeding to open the queue using the QLOCAL name, and the fact that there are generic profiles that would match the QLOCAL name, we should take a look at those next.

Could you please tell us if there are permissions that would match the user id in question on the generic profiles that match the QLOCAL name. This is where I suspect the access is allowed. Could you confirm?

You have asked a couple of times what you need to define, but I think you already have what you need defined. You just need to remove some permissions that are granted on the profile that is already defined.

As far as permissions on the transmission queue, these should not be needed by an application user id.

You last sentence says something about "writing to cluster local name to anyone". I think what we're trying to do is to NOT allow everyone to have put access (UPDATE) to the local queue name. I think you want to restrict access to that queue and only allow access through the QALIAS name? Perhaps you can confirm again that this is your intent?

Cheers,
Morag

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N) Yes
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier. I expected to see a warning "temporary access" but I cannot see it. 
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier. Yes. And a warning "temporary access" is displayed . 
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N) Yes
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N) Yes but with warningI would like to understand what to define in order to close an access to cluster local name from ZOS. As far as I understand I should get permission  writing to transmit queue to MQ master user only and writing to cluster local name to anyone. Is it write ? Yulia

Hi Yulia,

It is hard to guess when I don't get to see what you can see. To help me be able to guess a little more accurately could you answer these outstanding questions.

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N)
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier.
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier.
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N)
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N)

You should have no need to grant any application user access to the cluster transmit queue directly. 

Cheers,
Morag

Hello,

No problem with RESLEVEL. We have RACF errors on other local queues . 

I created QA on MQT0 points to cluster queue ( and I got warning there) . I would like to restrict the access to cluster queue thru this QA only. 

As far as I understand I also can remove access permission for users  from cluster XMIT queue .

Yulia.

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia

The MQQUEUE class profile called MQT0.clusterqueuename is what you grant access on. It does not PREVENT access, it ALLOWS access.

I have to assume, although I can't easily tell since you haven't shown any of your definitions, that either the profile called MQT0.clusterqueuename or some generic profile that would match for the same queue name, has permitted the user ID in question the UPDATE access it needs to MQOPEN the queue.

Please remember that MQ RACF profiles only allow access, they do not deny access. The lack of permitted access is what denies a user the ability to MQOPEN the queue. So you have to remove any granted access. You cannot add something that denies access.

Cheers,
Morag

Hello,

NOT allow everyone to have put access (UPDATE) to the local queue name. I think you want to restrict access to that queue and only allow access through the QALIAS name. Yes this is the idea.

I only need to verify that profile MQT0.<cluster local name> should prevent putting messages w/o QALIAS . So I can ask RACF guys to recheck what they defined. 

Thanks for your help.

Yulia 

Hi Yulia,

Still missing one important fact here. Question 2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - I need to know whether the application is failing or not.

I am guessing that the answer is no, and that the application receives a zero reason code when it opens the queue using the QLOCAL name. Please could you confirm this?

Going with the guess that the application is succeeding to open the queue using the QLOCAL name, and the fact that there are generic profiles that would match the QLOCAL name, we should take a look at those next.

Could you please tell us if there are permissions that would match the user id in question on the generic profiles that match the QLOCAL name. This is where I suspect the access is allowed. Could you confirm?

You have asked a couple of times what you need to define, but I think you already have what you need defined. You just need to remove some permissions that are granted on the profile that is already defined.

As far as permissions on the transmission queue, these should not be needed by an application user id.

You last sentence says something about "writing to cluster local name to anyone". I think what we're trying to do is to NOT allow everyone to have put access (UPDATE) to the local queue name. I think you want to restrict access to that queue and only allow access through the QALIAS name? Perhaps you can confirm again that this is your intent?

Cheers,
Morag

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N) Yes
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier. I expected to see a warning "temporary access" but I cannot see it. 
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier. Yes. And a warning "temporary access" is displayed . 
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N) Yes
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N) Yes but with warningI would like to understand what to define in order to close an access to cluster local name from ZOS. As far as I understand I should get permission  writing to transmit queue to MQ master user only and writing to cluster local name to anyone. Is it write ? Yulia

Hi Yulia,

It is hard to guess when I don't get to see what you can see. To help me be able to guess a little more accurately could you answer these outstanding questions.

1. Is the application opening the queue by name only with a blank MQOD.ObjectQMgrName (Y/N)
2. Does the application receive a 2035 when it opens the queue by the QLOCAL name (Y/N) - feel free to give an actual name for us to use to make discussions easier.
3. Does the application receive a RC of zero when it opens the queue by the QALIAS name (Y/N) - feel free to give an actual name for the alias for us to use to make discussions easier.
4. Are there any generic MQQUEUE profiles that would match the QLOCAL name (Y/N)
5. Are any permissions granted to any user or group on the MQQUEUE profile that would match the QLOCAL name (Y/N)

You should have no need to grant any application user access to the cluster transmit queue directly. 

Cheers,
Morag

Hello,

No problem with RESLEVEL. We have RACF errors on other local queues . 

I created QA on MQT0 points to cluster queue ( and I got warning there) . I would like to restrict the access to cluster queue thru this QA only. 

As far as I understand I also can remove access permission for users  from cluster XMIT queue .

Yulia.

Is your application opening the queue by name with a blank queue manager name in the MQOD? If yes, then the profile is MQ0T.clusterqname.

The only time when the profile being checked would be different is if it is a non-cluster queue being opened in a fully-qualified manner, with the MQOD queue manager name field being non-blank. Then you would need a profile MQ0T.remoteqmgrname.

The first four characters of the profile name is always going to be MQ0T in your setup though. What might change is what comes after the dot.

However, you have yet to say anything that suggests your profile name is wrong. You have not shown me your profile though, so I cannot comment further there.

You also have only mentioned that you do not see "temporary access is given" and you have not either confirmed or refuted whether your application has received the 2035 MQ reason code or not.

I also suggested in my previous reply that your problem may be that the check is being bypassed altogether as a result of RESLEVEL checks and asked you to show me those profiles. Could you look at that now?

Cheers,
Morag

Hello,

Yes we defined MQQUEUE MQT0.clusterqname with temporary access to test user . So I expect to see a racf warning "temporary access is given" . But I cannot see it. 

You wrote "MQQUEUE profile with the name of the specified Remote Queue Manager name" .

Is the profile name should be MQT0.clusterqname (  MQT0 is the name of MF QMGR where application is running) or <MQ OPEN QMGR>. clusterqname   ( <MQ OPEN QMGR> is the name of QMGR where cluster queue is defined ) ?          

Hi Yulia,

In your initial post you said, "We tried to set an access warning for actual cluster queue ..  but got no warning".

If you already have a profile in place for your actual cluster queue, e.g.

RDEFINE MQQUEUE MQT0.clusterqname UACC(NONE)

then if the user in question does not have UPDATE access to this profile, they should be receiving a 2035 reason code.

Is this what you have in place? What access does the user ID in question have to this profile?

You say "in order to close a direct put to cluster queue" which suggests that currently the user in question does have access? This implies that there is some profile granting access.

To just ensure that you are checking profiles at all, please also check what your RESLEVEL profile (or any wildcarded profile such as MQT0.* or MQT0.**) in the MQADMIN class has permitted. The way you are asking the question sounds a little like something might be configured to allow this user id to bypass this check.

Cheers,
Morag

Hello Morag,

MQT0 is a name of MQ QSG and MQT1/MQT2 are names of QMGR. All RACF profiles are MQT0.<QNAME>. 

So in order to close a direct put to cluster queue we should create a profile QmOpenQmgrName.*  ?

CSQH015I +MQT1 Security timeout = 54 minutes                             
CSQH016I +MQT1 Security interval = 12 minutes                            
CSQH037I +MQT1 Security using uppercase classes                          
CSQH030I +MQT1 Security switches ...                                     
CSQH034I +MQT1 SUBSYSTEM: ON, 'MQT0.NO.SUBSYS.SECURITY' not found        
CSQH031I +MQT1 QMGR: OFF, 'MQT0.NO.QMGR.CHECKS' found                    
CSQH034I +MQT1 QSG: ON, 'MQT0.NO.QSG.CHECKS' not found                   
CSQH034I +MQT1 CONNECTION: ON, 'MQT0.NO.CONNECT.CHECKS' not found        
CSQH034I +MQT1 COMMAND: ON, 'MQT0.NO.CMD.CHECKS' not found               
CSQH031I +MQT1 CONTEXT: OFF, 'MQT0.NO.CONTEXT.CHECKS' found              
CSQH031I +MQT1 ALTERNATE USER: OFF, 'MQT0.NO.ALTERNATE.USER.CHECKS'      
found                                                                    
CSQH035I +MQT1 PROCESS: OFF, internal error                              
CSQH035I +MQT1 NAMELIST: OFF, internal error                             
CSQH034I +MQT1 QUEUE: ON, 'MQT0.NO.QUEUE.CHECKS' not found               
CSQH035I +MQT1 TOPIC: OFF, internal error                                
CSQH034I +MQT1 COMMAND RESOURCES: ON, 'MQT0.NO.CMD.RESC.CHECKS' not      
found                                                                    
CSQH040I +MQT1 Connection authentication ...                             
CSQH041I +MQT1 Client checks: NONE                                       
CSQH042I +MQT1 Local bindings checks: NONE                               
CSQ9022I +MQT1 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION            

Hi Yulia,

There is no equivalent setting because the z/OS platform already behaved in the way that the ClusterQueueAccessControl=RQMName setting provided, namely it will check an MQQUEUE profile with the name of the specified Remote Queue Manager name, if you MQOPEN a fully qualified queue.

You haven't shown the MQQUEUE class profiles you have setup for me to make any comment on that.

Could you also provide the output of a DISPLAY SECURITY command on your queue manager.

Cheers,
Morag

Hello,

What is an alternative to queue manager stanza, ClusterQueueAccessControl setting on ZOS? We would like to restrict cluster queues access from ZOS thru local QALIAS only. We tried to set an access warning for actual cluster queue and for xmitq name but got no warning .

Thanks

Yulia