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
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.