2

我正在尝试使用 Hermes JMS 连接到 Websphere MQ 7.1，但我无法连接。我按照他们的指导，毫无问题地加载了所有罐子，设置插件，设置所有变量（主机名、端口、传输类型、队列管理器），选中底部的用户框并输入用户名和密码，然后确认我试图发现但是我收到以下消息：

com.ibm.mq.MQException：MQJE001：完成代码“2”，原因“2035”。在 com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:233) 在 com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553) 在 com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)在 com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:95) 在 com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198) 在 com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)在 com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:770) 在 com.ibm.mq.MQQueueManagerFactory。

经过几个小时的试验和错误以及在网上的研究，问题似乎是由于授权错误而无法连接但是我能够使用 Java 代码（使用相同的 lib MQQueueConnectionFactory）进行连接，并且我也能够连接将 QueueZee 与完全相同的库一起使用，获取所有队列的列表并浏览它们，因此我知道用户授权问题不应该是问题。

我正在运行 Hermes JMS 1.14，并尝试同时使用 Java 1.6.0_33 和 1.7.0_5。Websphere MQ 在版本 7.1.0.0 上运行，并且这些库是从远程服务器上的此安装中获取的。

我尝试将通道变量设置为 SYSTEM.DEF.SVRCONN，这是我在 QueueZee 中用来让它工作的，但仍然是同样的问题。

有没有人以前见过这个问题，希望能对这种情况有所了解？

4

2 回答 2

1

在 V7.1 中，新的 CHLAUTH 规则默认关闭对除 SYSTEM.ADMIN.SVRCONN 之外的所有 SYSTEM.* 通道的访问，并且默认情况下不允许对任何 SVRCONN 通道进行任何管理访问。为了诊断这一点，有必要知道使用了什么通道、设置的 CHLAUTH 规则、通道定义（特别是 MCAUSER 值）以及使用的 ID 是否在 mqm 组中。

您没有提到 QueueZee 设置是否也适用于 V7.1 QMgr 或者特别是这个。大胆猜测一下，我会说 CHLAUTH 规则已启用，而 SYSTEM.DEF.SVRCONN 通道此时已禁用。推荐的步骤是定义一个名称不以 SYSTEM 开头的新通道。并确保使用的 ID 不在 mqm 组中，而是被授权为非管理员 ID。

或者，可以使用 mqm 组中的 ID，但您必须定义 CHLAUTH 规则才能使其工作。例如，使用默认 CHLAUTH 规则CHANNEL(*) BLOCKUSER(*MQADMIN)，您可以将其更改为CHANNEL(THE.NEW.CHL.NAME) BLOCKUSER('nobody'). 新规则将比旧规则更具体，因此在您的频道上具有优先权。它告诉 QMgr 阻止用户 ID 'nobody'，但忽略任何提及 *MQADMIN。由于 'nobody' 无论如何都没有访问权限，但由于没有提及 *MQADMIN（因此没有被 i 规则阻止），因此该规则的效果是允许管理员访问该频道。

作为一种快速、肮脏和临时的措施，您还ALTER QMGR CHLAUTH(DISABLED)可以获得与 v7.0 和更早的 QMgrs 相同的行为。请注意，这允许匿名远程管理员和使用 mqm 用户 ID 执行远程代码。这就是更改默认设置的原因。现在，如果需要，您必须明确提供远程管理员访问权限。

有关此主题的更多信息，我推荐 IMPACT 会议上的Securing Your QMgr演示文稿。

请注意，QMgr 不会检查应用程序发送的密码。该字段存在以便通道出口可以根据 AD、LDAP 等验证密码。如果没有这样的出口，密码将被忽略。客户端传入的用户 ID 要么按面值接受，要么被通道的 MCAUSER 或 CHLAUTH 规则修改。

最后，当遇到授权问题时，最简单的诊断方法是ALTER QMGR AUTHOREV(ENABLED)使用SupportPac MS0P在 WMQ Explorer 中解码 PCF 消息。auths 错误最终出现在 QMgr 事件队列中。每条消息都会告诉您身份验证失败的对象、对该对象进行的 API 调用、调用的选项以及进行调用的 ID。我们经常发现拨打电话的 ID 不是我们想要的，或者程序正在使用未经授权的选项，因此这非常有帮助。

于 2012-09-17T21:49:44.807 回答
0

不是真正的答案，只是对这个问题的一点研究。大约一小时前我遇到了同样的问题。我正在传递类似 domain\sortoflongusername 的用户名，而我在 WSMQ 服务器上的系统日志中看到的是我的用户名被截断为 12 个符号。我对hermesJMS 和soapui 一点都不熟悉（只是想把它提供给我们的测试人员以将其作为测试平台进行检查），所以也许这里的任何人都知道这个问题的根源。

于 2012-09-25T11:03:05.663 回答