Hermes JMS無法連接到Websphere MQ 7.1（2035錯誤）

Question

我試圖用Hermes JMS連接到Websphere MQ 7.1，但我無法連接。我已經按照他們的慣例，加載所有罐子沒有問題，設置插件，設置所有變量（主機名，端口，transportType，queuemanager），檢查底部表示用戶並輸入用戶名和密碼的框，並在確認I試圖發現但是我收到以下消息：

com.ibm.mq.MQException：MQJE001：完成代碼'2'，原因'2035'。 在 com.ibm.mq.MQManagedConnectionJ11。（MQManagedConnectionJ11.java:233） 處 com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection（MQClientManagedConnectionFactoryJ11.java:553）（MQClientManagedConnectionFactoryJ11的.java：593） 在 com.ibm.mq.StoredManagedConnection（StoredManagedConnection.java:95） 在 com.ibm.mq.MQSimpleConnectionManager.allocateConnection（MQSimpleConnectionManager.java:198） 在 com.ibm.mq。 .QQueueManagerFactory.obtainBaseMQQueueManager（MQQueueManagerFactory.java:882） at co m.ibm.mq.MQQueueManagerFactory.procure（MQQueueManagerFactory.java:770） 在 com.ibm.mq.MQQueueManagerFactory.constructQueueManager（MQQueueManagerFactory.java:719） 在 com.ibm.mq.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.discoverDestinationConfigs（HermesAdminAdapter.java:82） 在 hermes.impl.DefaultHermesImpl.discoverDestinationConfigs（Defau ltHermesImpl.java:1126） 在 hermes.browser.tasks.DiscoverDestinationsTask.invoke（DiscoverDestinationsTask.java:77） 在hermes.browser.tasks.TaskSupport.run（TaskSupport.java:175）在 hermes.browser.tasks .ThreadPool.run（ThreadPool.java:170）在 java.lang.Thread.run（Thread.java:662）

摸索與研究網的幾個小時之後，似乎問題是它由於授權不良而無法連接，但是我可以使用Java代碼進行連接（使用相同的lib MQQueueConnectionFactory），並且我也能夠使用QueueZee與完全相同的庫進行連接，獲取所有隊列的列表並瀏覽它們所以我知道用戶授權問題sh不應該是問題。

我正在運行Hermes JMS 1.14，我嘗試使用Java 1.6.0_33和1.7.0_5。 Websphere MQ在版本7.1.0.0上運行，並且這些庫是從遠程服務器上的此安裝獲取的。

我試圖設置通道變量爲SYSTEM.DEF.SVRCONN，這是我在QueueZee中使用它得到它的工作，但仍然是同一個問題。

以前有沒有人看過這個問題，希望能對這種情況有所瞭解？

Answer 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用戶標識匿名遠程管理和遠程代碼執行。這就是爲什麼默認設置發生了變化。現在，如果您需要遠程管理訪問權限，您必須明確規定。

有關此主題的更多信息，我建議IMPACT會議的Securing Your QMgr演示文稿。

請注意，應用程序發送的密碼未被QMgr檢查。該字段存在以便通道出口可以根據AD，LDAP等驗證密碼。如果沒有這樣的退出，密碼將被忽略。客戶端傳入的用戶ID或者通過面值接受，或者由通道的MCAUSER或CHLAUTH規則修改。

最後，有授權的問題時，診斷的最簡單方法是ALTER QMGR AUTHOREV(ENABLED)然後用SupportPac MS0P來解碼WMQ Explorer中的PCF消息。身份驗證錯誤最終在QMgr事件隊列中。每條消息都會告訴您失敗auths的對象，針對該對象的API調用，調用的選項以及調用的ID。通常情況下，我們發現身份證打電話不是我們想要的，或者該程序正在使用它未授權的選項，因此這可能非常有用。

Answer 2

不是一個真正的答案，只是對問題的一點研究。 我在小時前面臨同樣的問題。我傳遞的用戶名如domain \ sortoflongusername，而我在WSMQ服務器上的系統日誌中看到的是我的用戶名被截斷爲12個符號。 我真的不熟悉hermesJMS和soapui（只是想給我們的測試人員把它作爲測試平臺），所以也許任何人都知道這個問題的根源。