WebSphere 7，配置没有用户 ID 的 JMS Q 连接工厂：MQRC_NOT_AUTHORIZED
我有一个 WebSphere 6 实例和一个 WebSphere 7 实例。每个实例都有一个 WebSphere MQ 消息传递提供程序、一个队列连接工厂和一个以类似方式配置的队列。所有用户 ID 字段均保留为空，身份验证别名保留为“none”。
在 WAS6 中它工作得很好。
在 WAS7 中我收到错误：
JMSWMQ2013：为连接模式为“客户端”且主机名为“10.11.22.33(51001)”的 QueueManager“MYQMNGR”提供的安全身份验证无效。嵌套异常是 com.ibm.msg.client.jms.DetailedJMSSecurityException：JMSWMQ2013：为具有连接模式“Client”和主机名“10.11.22.33(51001)”的 QueueManager“MYQMNGR”提供的安全身份验证无效。请检查您所连接的 QueueManager 上提供的用户名和密码是否正确；嵌套异常为 com.ibm.mq.MQException：JMSCMQ0001：WebSphere MQ 调用失败，代码为“2”（“MQCC_FAILED”），原因为“2035”（“MQRC_NOT_AUTHORIZED”）。
如果未提供用户 ID，WAS7 连接 MQ 的方式与 WAS6 有何不同？
我对该 MQ（版本 7）没有任何可见性或访问权限，从 WAS 6 访问时不需要用户 ID，因此我需要让 WAS7 才能正常工作。
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 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 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 WAS 6 中，如果您将管理面板中的用户 ID 留空，则会将空白传递给 WMQ。即使 WMQ 无法确定远程用户，它也会运行该通道，在这种情况下，该通道以消息通道代理 (MCA) 的权限运行，该权限始终是管理性的。因此，在 V6 中，它可以工作。
从 V7 开始，如果您在 WAS 管理面板中将 ID 留空，WMQ 客户端将更加努力地尝试确定要传递的 ID，并将获取 JVM ID 并在
CONNECT调用中传递该 ID。这就是 2035 的来源。解决此问题的正确方法是 WMQ 管理员应在 SVRCONN 通道的 MCAUSER 字段中放置一个低特权 ID。该 ID 应该被授权给 Java EE 服务器需要的任何队列，但不能被授权给命令队列和各种其他管理队列。这将解决 WAS 7 发送无法识别的 ID 的问题，并防止任何类型的远程客户端获得该通道的管理员访问权限。
另一种方法是转至 WAS 管理面板进行 WMQ 连接并将用户 ID 设置为
mqm。 （如果 WMQ 在分布式非 Windows 系统上运行，则此方法有效。如果 WMQ 在 Windows、z/OS 或其他系统上运行，请在此处替换平台等效 ID。）虽然这将使 WAS 启动并运行，但它并没有解决事实上，QMgr 公开了管理访问权限。请参阅 http://t-rob.net/links 上的 WMQ 强化演示和实验室，了解更多信息全面解释如何识别和修复 QMgr 的潜在安全漏洞。
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
CONNECTcall. 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.