本文主要是介绍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)
- dspmqaut (display 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
这篇关于2035 MQRC NOT AUTHORIZED的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!