2035 MQRC NOT AUTHORIZED

http://www-01.ibm.com/support/docview.wss?uid=swg21166937

1、The svrconn channel which u r using to connect will have one acl file to that file we need to add ips 

2、give the permission to the queue under the some group

 

You are getting MQRC 2035. You need to understand what causes this failure.

2035 0x000007f3 MQRC_NOT_AUTHORIZED

Cause

MQRC 2035 is returned when a user is not authorized to perform the function that is attempted.

Resolving the problem

MQRC 2035 is returned when a user is not authorized to perform the function.Determine which object the user cannot access and provide the user access to the object.

 

如果没有设置通道的MCAUSER，使用执行应用的username作为权限的验证，而该用户名没有在mqm组里，所以是没有权限去访问MQ的。

如果设置了通道的MCAUSER为mqm组的用户，则会使用该用户去执行想要的操作。

 

Debugging techniques: 
Use the dspmqaut (display authority command), to determine if the user has the authorization to access the intended object. 




For more difficult problems a trace of the failure may be necessary. See "Additional information" for trace debugging pointers.

For more details on how to take a trace, see:
MustGather: Directions to start, end, and format trace


Corrective action: 
Use the setmqaut (set or reset authority) command, to grant access to WebSphere MQ objects. 




You will then need to restart the queue manager to refresh the security cache, or via runmqsc run "REFRESH SECURITY(*)" to do the same.

In some cases you may want to make the user a member of the "mqm" group. That will give the user full access to WebSphere MQ. 

For further details regarding the WebSphere MQ authority commands, refer to: 
WebSphere(R) MQ System Administration Guide

• Chapter 17. The control commands
  • dspmqaut (display authority)
    setmqaut (set or reset authority)

Additional information
Here's a quick overview of MQSeries security:

Users in the 'mqm' group and the 'mqm' userid (on UNIX) have full authority. Other users and groups need to be given limited authority through the OAM using 'setmqaut'.

Imagine that an MQSeries application issues an MQOPEN. Here is the sequence of events as that MQOPEN is handled by the application and its agent:

Application​		Agent (amqzlaa0)​
-->   MQOPEN​
---->   zstMQOPEN​
------>   ziiMQOPEN​
-------->   zcpSendReceiveAgent​	Pass request​
	--> by IPC -->​	-->   zlaProcessMessage​
		---->   zlaProcessMQIRequest​
		------>   zlaMQOPEN​
		-------->   zsqMQOPEN​
		---------->   kpiMQOPEN​
		.....​
		------------>   kqiAuthorityChecks​
		-------------->   zfu_as_calculate_authority​
		​*** Print useful info! ***​
		<--------------   zfu_as_calculate_authority​
		<------------   kqiAuthorityChecks​
		.....​
		<----------   kpiMQOPEN​
		<--------   zsqMQOPEN​
		<------   zlaMQOPEN​
		<----   zlaProcessMQIRequest​
	Pass response​	<--   zlaProcessMessage​
<--------   zcpSendReceiveAgent​	<-- by IPC <--​
<------   ziiMQOPEN​
<----   zstMQOPEN​
<--   MQOPEN​

The application packages up the MQOPEN request, sends it to the agent, and waits until it gets a response. The agent does the MQOPEN processing, including all authority checking. The most important thing to understand is that if there is an authorization problem, it is the agent who will discover that 99% of the time. The function 'kqiAuthorityChecks' does this work, and happily for us it calls a function 'zfu_as_calculate_authority' which prints out the results of the authority testing.

Here is what the "useful info" looks like in the trace:

Principal(guest     ) EntityType(1)
ObjectName(SYSTEM.DEAD.LETTER.QUEUE                        ) ObjectType(5)
PrimaryOnly(0) AccessTemplate(8) Authorization(100018)

Principal: What is the name of the user or group being authorized?
EntityType: Is this principal a user or a group name?

MQZAET_PRINCIPAL    0x00000001
MQZAET_GROUP        0x00000002

ObjectName: What is the name of the object being accessed?
ObjectType: Is this a queue, a process, the queue manager, ... ?

MQOT_Q                   0x00000001
MQOT_NAMELIST            0x00000002
MQOT_PROCESS             0x00000003
MQOT_Q_MGR               0x00000005
MQOT_CHANNEL             0x00000006
MQOT_RESERVED_1          0x00000007
MQOT_ALL                 0x00001001
MQOT_ALIAS_Q             0x00001002
MQOT_MODEL_Q             0x00001003
MQOT_LOCAL_Q             0x00001004
MQOT_REMOTE_Q            0x00001005
MQOT_SENDER_CHANNEL      0x00001007
MQOT_SERVER_CHANNEL      0x00001008
MQOT_REQUESTER_CHANNEL   0x00001009
MQOT_RECEIVER_CHANNEL    0x00001010
MQOT_CURRENT_CHANNEL     0x00001011
MQOT_SAVED_CHANNEL       0x00001012

PrimaryOnly: Should secondary groups be used when calculating authority?
AccessTemplate: What authorities are we asking for?
Authorization: What authorities do we really have?

MQZAO_CONNECT                  0x00000001
MQZAO_BROWSE                   0x00000002
MQZAO_INPUT                    0x00000004
MQZAO_OUTPUT                   0x00000008
MQZAO_INQUIRE                  0x00000010
MQZAO_SET                      0x00000020
MQZAO_PASS_IDENTITY_CONTEXT    0x00000040
MQZAO_PASS_ALL_CONTEXT         0x00000080
MQZAO_SET_IDENTITY_CONTEXT     0x00000100
MQZAO_SET_ALL_CONTEXT          0x00000200
MQZAO_ALTERNATE_USER_AUTHORITY 0x00000400
MQZAO_ALL_MQI                  0x000007FF
MQZAO_CREATE                   0x00010000
MQZAO_DELETE                   0x00020000
MQZAO_DISPLAY                  0x00040000
MQZAO_CHANGE                   0x00080000
MQZAO_CLEAR                    0x00100000
MQZAO_AUTHORIZE                0x00800000
MQZAO_ALL_ADMIN                0x009E0000
MQZAO_NONE                     0x00000000
MQZAO_ALL                      0x009E07FF

The constants come from MQSeries header files--cmqc.h for the MQO_* constants, cmqzc.h for the others. All of the constants are defined in hex. To avoid any confusion, the constants used for AccessTemplate and Authorization are in fact the same.

So let us look at my example again and see what we can see:

Principal(guest     ) EntityType(1)
ObjectName(SYSTEM.DEAD.LETTER.QUEUE                        ) ObjectType(1)
PrimaryOnly(0) AccessTemplate(8) Authorization(100018)

In this case, we have 'guest' which is a user, not a group, based on the EntityType. The principal 'guest' is trying to access the object 'SYSTEM.DEAD.LETTER.QUEUE' which is a queue, based on the ObjectType. The authority 'guest' has includes all of the authorities given to him by his primary group as well as his supplemental groups. Finally, 'guest' is requesting the authority to MQPUT to the queue (output messages to it), based on the AccessTemplate. The authorities that 'guest' has include the abilities to clear the queue, put messages to it, and inquire on its attributes, based on the Authorization:

  MQZAO_OUTPUT    0x00000008
  MQZAO_INQUIRE   0x00000010
+ MQZAO_CLEAR     0x00100000
============================
  Authorization   0x00100018

Based on this analysis, we can see that 'guest' has permission to put messages to this queue, which is what it wants to do. So the MQI call (in this case, an MQOPEN) would get a return code of MQRC_OK, provided that nothing else goes wrong.


For a complete list of the reason codes that includes detailed information, refer to the WebSphere MQ Messages manual.

Note: When user namesare passed over a channel they should be12 characters or less. If you have user names that are longer then 12 characters you can use the MCA user id setting on the receiving channel to get around this MQ restriction.

See: Message channel agent user identifier (MCAUSER)



Additional information for iSeries™ customers:


Examples of the iSeries commands to display and grant MQ Object Authority: 

DSPMQMAUT OBJ(SVR.LQ) OBJTYPE(*LCLQ) MQMNAME(MQAS04) 






GRTMQMAUT OBJ(SVR.LQ) OBJTYPE(*LCLQ) USER(*PUBLIC) AUT(*PUT) MQMNAME(SVR)

Product Alias/Synonym

WMQ MQ