2

Hermes JMS を使用して Websphere MQ 7.1 に接続しようとしていますが、接続できません。私は彼らのガイドに従い、問題なくすべての jar をロードし、プラグインを設定し、すべての変数 (ホスト名、ポート、transportType、queuemanager) を設定し、下部にあるユーザーと表示されているボックスをチェックし、ユーザー名とパスワードを入力しました。発見しようとしましたが、次のメッセージが返されました。

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.1QMgrに対するものなのか、特にこれに対するものなのかについては言及していません。大まかに推測すると、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以前のQMgrと同じ動作を取得することもできます。ただし、これにより、mqmユーザーIDを使用した匿名のリモート管理者およびリモートコード実行が可能になることに注意してください。そのため、デフォルト設定が変更されました。ここで、必要に応じてリモート管理者アクセスを明示的にプロビジョニングする必要があります。

このトピックの詳細については、IMPACT会議からのQMgrプレゼンテーションの保護をお勧めします。

アプリが送信するパスワードはQMgrによってチェックされないことに注意してください。このフィールドは、チャネル出口がAD、LDAPなどに対してパスワードを検証できるようにするために存在します。このような出口がない場合、パスワードは無視されます。クライアントから渡されたユーザーIDは、額面どおりに受け入れられるか、チャネルのMCAUSERまたはCHLAUTHルールによって変更されます。

最後に、認証の問題がある場合、診断する最も簡単な方法は、SupportPac MS0PALTER QMGR AUTHOREV(ENABLED)を使用して、WMQエクスプローラーでPCFメッセージをデコードすることです。authsエラーはQMgrイベントキューに入れられます。各メッセージは、認証に失敗したオブジェクト、そのオブジェクトに対して行われたAPI呼び出し、呼び出しのオプション、および呼び出しを行ったIDを示します。多くの場合、呼び出しを行うIDが目的のIDではないか、プログラムが許可されていないオプションを使用していることがわかります。これは非常に役立ちます。

于 2012-09-17T21:49:44.807 に答える
0

実際には答えではなく、問題について少し調べただけです。私は約1時間前に同じ問題に直面しました。domain\sortoflongusername のようなユーザー名を渡していますが、WSMQ サーバーのシステム ログに表示されるのは、ユーザー名が 12 個の記号に切り詰められていることです。私は hermesJMS と soapui についてはまったく詳しくありません (テスト プラットフォームとしてテストするためにテスターに​​提供したかっただけです) ので、ここにいる誰かがこの問題の根源について知っているかもしれません。

于 2012-09-25T11:03:05.663 に答える