IBM Support

2035 MQRC_NOT_AUTHORIZED in WMQ

Troubleshooting


Problem

You are getting MQRC 2035, Not Authorized in your WebSphere MQ application or channel. You need to understand what causes this failure. 2035 0x000007f3 MQRC_NOT_AUTHORIZED

Cause

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

Resolving The Problem

MQRC 2035 (MQRC_NOT_AUTHORIZED) 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.

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:



Additional information
Here's a quick overview of WMQ 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 a WMQ application issues a MQOPEN. Here is the sequence of events as that MQOPEN is handled by the application and its agent (note: this is a general flow. The internal routine names or the specific interactions between routines could change without any notification.)


Application

Agent (amqzlaa0)



-->   MQOPEN

---->   zstMQOPEN

------>   ziiMQOPEN

-------->   zcpSendReceiveAgent
Pass request


--> by IPC -->
-->   zlaProcessMessage


---->   zlaProcessMQIRequest


------>   zlaMQOPEN


-------->   zsqMQOPEN


---------->   kpiMQOPEN


.....


------------>   kqiAuthorityChecks


-------------->   zfu_as_calculateauthority


                 *** Print useful info! ***


<--------------   zfu_as_calculateauthority


<------------   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 most of the time. The function 'kqiAuthorityChecks' does this work, and happily for us it calls a function 'zfu_as_calculateauthority' 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(1)
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 WMQ 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 API completion and reason codes

Note: When user names are passed over a channel they should be 12 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":{"code":"SSFKSJ","label":"WebSphere MQ"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.0;8.0;7.5;7.1;7.0.1;7.0;6.0.2;6.0;5.3","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Product Synonym

WMQ MQ

Document Information

Modified date:
22 June 2018

UID

swg21166937