WebSphere 7, configuring JMS Q connection factory without user id: MQRC_NOT_AUTHORIZED

I have an instance of WebSphere 6 and an instance of WebSphere 7. Each has a WebSphere MQ messaging provider, a queue connection factory and a queue configured in a similar way. All user ID fields are left empty and Authentication aliases left at "none".

In WAS6 it works fine.

In WAS7 I get an error:

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 au开发者_JAVA技巧thentication 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 may be different in the way WAS7 connects to MQ compared to WAS6 if no user ID is supplied?

I don't have any visibility or access to that MQ (version 7), it doesn't require user ID when accessing from WAS 6 so I need to get WAS7 to work the same.

In WAS 6 if you left the user ID in the administration panel blank, a blank was passed to WMQ. WMQ will run the channel even if it cannot determine the remote user and in that case the channel runs with the authority of the Message Channel Agent (MCA), which is always administrative. Hence, in V6, it works.

As of V7, the WMQ client will try a little harder to determine what ID to pass if you leave it blank in the WAS admin panel and will obtain the JVM ID and pass that on the CONNECT call. This is the source of the 2035.

The right way to fix this is that the WMQ administrator should place a low-privileged ID in the SVRCONN channel's MCAUSER field. The ID should be authorized to whatever queues the Java EE server needs but not to the command queue and various other administrative queues. This will resolve the problem that WAS 7 is sending an unrecognized ID and it prevents remote clients of any type from gaining admin access on that channel.

The alternative is to go to the WAS admin panel for the WMQ connection and set the user ID to mqm. (This works if if WMQ runs on a distributed non-Windows system. If WMQ is running on Windows, z/OS or something else, substitute the platform equivalent ID here.) Although this will get WAS up and running, it does not address the fact that the QMgr exposes administrative access.

Please see the WMQ Hardening presentation and lab at http://t-rob.net/links for a more comprehensive explanation of how to identify and remediate the underlying security exposure at the QMgr.