Hermes JMS无法连接到Websphere MQ 7.1(2035错误)

Hermes JMS无法连接到Websphere MQ 7.1(2035错误),jms,ibm-mq,Jms,Ibm Mq,我正在尝试使用Hermes JMS连接到Websphere MQ 7.1,但无法。我按照他们的指示,加载了所有JAR,没有问题,设置了插件,设置了所有变量(主机名、端口、传输类型、队列管理器),选中了底部的“用户”框,输入了用户名和密码,在确认后,我尝试发现,但我收到了以下消息: com.ibm.mq.MQException:MQJE001:完成代码“2”,原因“2035”。 在 MQManagedConnectionJ11。(MQManagedConnectionJ11.java:233) 在

我正在尝试使用Hermes JMS连接到Websphere MQ 7.1,但无法。我按照他们的指示,加载了所有JAR,没有问题,设置了插件,设置了所有变量(主机名、端口、传输类型、队列管理器),选中了底部的“用户”框,输入了用户名和密码,在确认后,我尝试发现,但我收到了以下消息:

com.ibm.mq.MQException:MQJE001:完成代码“2”,原因“2035”。 在 MQManagedConnectionJ11。(MQManagedConnectionJ11.java:233) 在 MQClientManagedConnectionFactoryJ11.\u createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)位于 MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593) 在 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) 在 MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:719) 在 MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:175) 位于com.ibm.mq.MQQueueManager.(MQQueueManager.java:647) hermes.ext.mq.MQSeriesAdmin.getQueueManager(MQSeriesAdmin.java:107) 在 hermes.ext.mq.MQSeriesAdmin.discoverDestinationConfigs(MQSeriesAdmin.java:280) 在 hermes.impl.HermesAdminAdapter.discoverdensitionConfigs(HermesAdminAdapter.java:82) 在 hermes.impl.DefaultHermesImpl.discoverDestinationConfigs(DefaultHermesImpl.java:1126) 在 hermes.browser.tasks.DiscoverDestinationsTask.invoke(DiscoverDestinationsTask.java:77) 运行(TaskSupport.java:175) 运行(ThreadPool.java:170) run(Thread.java:662)

在网上经过几个小时的反复试验和研究后,问题似乎是由于授权不正确而无法连接,但是我可以使用Java代码(使用相同的库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中使用的使其工作的方法,但仍然存在相同的问题


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

在V7.1中,新的CHLAUTH规则默认情况下关闭对所有系统的访问。*默认情况下除了SYSTEM.ADMIN.SVRCONN之外的通道,并且默认情况下不允许对任何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规则阻止),因此该规则的作用是允许管理员在此通道上访问

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

有关此主题的更多信息,我推荐IMPACT会议的演示

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


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

不是真正的答案,只是对问题进行了一点研究。 大约一小时前,我也遇到过同样的问题。我正在传递类似domain\sortoflongusername的用户名,我在WSMQ服务器的systemlog中看到的是我的用户名是b