WebSphereMQは認証を実行しません。ローカルアプリケーションはオペレーティングシステムによって認証されるため、IDを信頼できます。(定義上、ローカルOS認証を信頼できない場合、サーバー全体が危険にさらされます。)ローカル接続と同様に、WMQはリモート接続しているIDが本物であると信頼します。使用する認証のレベルを決定するのは、WMQ管理者の責任です。WMQ v7には、SSL / TLSチャネルで認証するか、チャネル出口を使用して認証するかの2つの選択肢があります。
いずれの場合も、許可に使用されるIDを決定するのはチャネルのMCAUSER値です。MCAUSERを空白のままにすると、チャネルはクライアントが送信するユーザーIDを使用します。あなたの場合、クライアントが管理(mqm)グループにないIDを送信したため、2035エラーが発生しました。クライアントがID'mqm'(またはWindowsの場合は'MUSR_MQADMIN')を送信した場合、接続は成功します。プログラムがJavaまたはJMSの場合、提示されたIDを選択する機能はAPIの一部です。QMgrにあなたが誰になりたいかを伝えてください。
リモート接続でサーバー上でOSコマンドを実行できるようにする場合は、チャネルのMCAUSERに管理者IDを入力するだけです。(たとえば、UNIX / Linuxの場合はMCAUSER('mqm')、Windowsの場合は通常MCAUSER('MUSR_MQADMIN')です。)ただし、管理者権限を持つリモートユーザーは、QMgrを使用して任意のOSコマンドラインコードをリモートで実行できることに注意してください。これはWMQの機能であり、バグではないため、本番環境では決してお勧めしません。実際、私は個人的に、開発環境でセキュリティを有効にすることをお勧めします。本番環境で接続を認証する方法と必要な権限を把握するまで待つと、多くの場合、不要な展開の遅延が発生します。
IPフィルタリングを使用してその脅威を軽減する場合は、この機能をネイティブに含むWMQ v7.1に移行するか、BlockIP2などの出口を使用できます。これらのソリューションのいずれかを使用すると、IPアドレスやユーザーIDなどで着信接続要求をフィルタリングするルールを作成できます。
v7.0 QMgrでは、すべてのチャネルがデフォルトで保護されていないことに注意してください。したがって、1つのチャネルで着信要求をフィルタリングしても、他のチャネルがデフォルトの状態のままである場合は、誰でも接続して管理者としてコマンドを実行できます。これらすべての包括的なレビューについては、t-rob.netのHardeningWebSphereMQプレゼンテーションをご覧ください。v7.0プレゼンテーションまで下にスクロールします。