WebSphere 7, setting up a JMS Q connection factory without user ID: MQRC_NOT_AUTHORIZED

Question

I have an instance of WebSphere 6 and an instance of WebSphere 7. Each of them has a WebSphere MQ message provider, a connection in the factory queue, and a queue configured in a similar way. All user ID fields remain blank, and authentication aliases are "none".

In WAS6, it works great.

In WAS7, I get the error message:

JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'. Please check if the supplied username and password are correct on the QueueManager you are connecting to; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

What could be different in how WAS7 connects to MQ compared to WAS6 if no user ID is specified?

I have no visibility or access to this MQ (version 7), it does not require a user ID when accessing with WAS 6, so I need to get WAS7 to work the same.

Answer 1

In WAS 6, if you left the user ID in the admin panel blank, the space was passed to WMQ. WMQ will start the channel, even if it cannot determine the remote user, in which case the channel works with the authority of the Message Channel Agent (MCA), which is always administrative. Therefore, in V6 it works.

As in the case of V7, the WMQ client will try to make it a little more difficult to determine which identifier should pass if you leave it blank in the WAS admin panel and get the JVM ID and pass it on a CONNECT call. This is the source of 2035.

The correct way to fix this is for the WMQ administrator to put the low priority identifier in the MCACUSER field of the SVRCONN channel. The identifier must be authorized in any queues that are required by the Java EE server, but not in the command queue and in other administrative queues. This will fix the problem where WAS 7 sends an unrecognized identifier, and prevents any type of remote client access from administrator access to this channel.

An alternative is to go to the WAS control panel to connect WMQ and set the user ID on mqm . (This works if WMQ is running on a distributed system other than Windows. If WMQ is running on Windows, z / OS or something else, replace the equivalent platform identifier here.) Although this will work with WAS, it does not address that fact QMgr provides administrative access.

Please view the WMQ Hardening presentation and lab at http://t-rob.net/links for a more complete explanation of how to identify and address the underlying security impact on QMgr.