MQ Error: 2035 MQRC_NOT_AUTHORIZED or AMQ4036 or JMSWMQ2013
Problem: If we create a new queue manager in WebSphere MQ 7.1, 7.5, 8.0 or 9.0 or later and try to use a user id(commonly mqm for UNIX and MUSR_MQADMIN on Windows) that is an MQ Administrator to access the queue manager via a server-connection channel (remotely from another host, or locally from the same host and not using bindings mode). You get an error with reason code 2035:
2035 MQRC_NOT_AUTHORIZED
Related error codes:
MQ Explorer => AMQ4036
MQ classes for JMS => JMSWMQ2013
org.springframework.jms.JmsSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager '' with connection mode 'Client' and host name 'localhost(1417)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager '' with connection mode 'Client' and host name 'localhost(1417)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
Note: The MQ Administrator can remotely access (via a server-connection channel) without problems other MQ queue managers at version 6 or 7.0.x.
1a. We can add the following two Channel Authentication Records:
The first rule blocks administrative users and the MCAUSER "nobody" (which prevents someone from creating a user ID "nobody" and putting it into an authorized group).
$ runmqsc QmgrName
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('nobody','*MQADMIN')
The second rule provides a reduced blacklist for SYSTEM.ADMIN channels that allows administrators to use these. It is assumed here that some other CHLAUTH rule such as an SSLPEERMAP has validated the administrator’s connection or that an exit has done so.
SET CHLAUTH(SYSTEM.ADMIN.*) TYPE(BLOCKUSER) USERLIST('nobody')
The above rules apply to SYSTEM.ADMIN.SVRCONN which is used by the MQ Explorer.
If you are using another user-defined channel, such as MY.ADMIN.SVRCONN, then you need to add the following two records:
SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')
Note: it is not advisable to use SYSTEM.DEF.* channels for active connections. The system default channels are the objects from which all user-defined channels inherit properties. The recommended practice is that SYSTEM.DEF.* and SYSTEM.AUTO.* channels should NOT be configured to be usable.
1b. This is a variation of (1a) but allowing the MQ Administrator to only use a particular host.
The first rule blocks MCAUSER "nobody".
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')
The second rule removes all access to SYSTEM.ADMIN.SVRCONN ...
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)
And the third rule adds an entry for the server that needs access.
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(9.xx.xx.8y) USERSRC(CHANNEL)
1c. Disable the Channel Authentication Records feature:
DISPLAY QMGR CHLAUTH
AMQ8408: Display Queue Manager details.
QMNAME(TEST01) CHLAUTH(ENABLED)
ALTER QMGR CHLAUTH(DISABLED)
Note that disabling CHLAUTH results in a policy that accepts administrative connections by default. The administrative effort to lock down administrative access with CHLAUTH(DISABLED) is much greater than to do so with CHLAUTH(ENABLED). It is therefore recommended to leave CHLAUTH(ENABLED) and use the other security features of WebSphere MQ V7.1 to authenticate administrator connections.
We're trying to develop our first "IBM MQ classes for JMS" application to put messages on a remote client's queue. We have have no prior experience with IBM MQ, but we are digging in to learn. I have installed a trial version of IBM MQ 9 on a Windows 10 Pro machine, and have created a Queue Manager, Queue and associated JMS objects. I'm now trying to run one of the simple sample Java programs that uses IBM JMS extensions to connect and send a message, but I get the following error:
ReplyDeletecom.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MM_QM_1' with connection mode 'Client' and host name 'localhost(1414)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.
Inner exception(s):
com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
FAILURE
I have read your article above, but being new to IBM MQ (and JMS), I am completely lost as to what to do to fix our problem. Can you help? The connection code we are using from the sample client application is as follows, falling with the above Exception at the call to cf.createConnection():
// Create a connection factory
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER);
JmsConnectionFactory cf = ff.createConnectionFactory();
// Set the properties
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, "localhost");
cf.setIntProperty(WMQConstants.WMQ_PORT, 1414);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, "SYSTEM.DEF.SVRCONN");
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, "MM_QM_1");
cf.setStringProperty(WMQConstants.WMQ_APPLICATIONNAME, "SimplePTP (JMS)");
// Create JMS objects
connection = cf.createConnection();
I am very late to reply this question. had you tried
Delete$ runmqsc QmgrName
DISPLAY QMGR CHLAUTH
AMQ8408: Display Queue Manager details.
QMNAME(TEST01) CHLAUTH(ENABLED)
ALTER QMGR CHLAUTH(DISABLED)
Thank you, your post was very helpfull!
ReplyDeleteEvent though its disabled for me still the issue coming.
ReplyDeletesame here, please let me know if you find a solution for that
ReplyDelete