6

I am trying to connect to IBM Websphere MQ Server from IBM Websphere Application Server.

I am getting the following error:

MQJMS2013: invalid security authentication supplied for MQQueueManager

What I understand is, this is because of invalid security credentials by WAS while connecting to MQ Manager.

I have tried different combination of providing the MQ admin password e.g.

  1. Provide J2C authentication to MQ Connection Factory.
  2. Provide MQ admin username and password to Queues.
  3. Providing Blank username.
  4. Combination of all three above.

Also, as mentioned in some of the posts, I have tried the Transport Type as 'Binding' as well as 'Client' for QueueConnectionFactory.

Please suggest.

Rob Kielty
  • 7,958
  • 8
  • 39
  • 51
Sandeep Jindal
  • 14,510
  • 18
  • 83
  • 121

2 Answers2

2

One problem is that the MQJMS2013 may have nothing to do with the QMgr. It could be config file permission problems, LDAP credentials doing JNDI lookups, problems with a keystore, etc.

One way to determine whether this really is a WMQ authorization exception is to enable authorization events on the QMgr and recreate the error. If it is a WMQ auth problem, the event message will land in SYSTEM.ADMIN.QMGR.EVENT queue. It will contain the ID of the user, the object the call failed on, the API call that failed and all of the options used on the call. If you use SupportPac MO71 then it will format the event message for you. If you use WMQ Explorer then you can install SupportPac MS0P to format the event messages.

If you do not get an event message then the connection is not reaching WMQ! In that case, nothing you do with accounts, groups, setmqaut and other WMQ-specific configuration will help and I'd suggest enabling tracing.

In bindings mode, the ID presented must match the ID the JVM runs as. In client mode another way to diagnose is to set the channel's MCAUSER to a known good value. The channel's MCAUSER overrides any ID passed in by the app server and should always be set to a low-privileged account. For diagnostics, set it TEMPORARILY to 'mqm' and if the connection works that isolates the problem to being WMQ auth issues.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Seems this information is quite useful. I have found message on SYSTEM.ADMIN.QMGR.EVENT queue. But the details of message is "MQGET ended with reason code 2080". Trying to remove the message and do it again! – Sandeep Jindal Dec 16 '10 at 08:10
  • 1
    The 2080 is MQRC_TRUNCATED_MSG_FAILED which means you are probably using amqsget. If you use the tools mentioned above they will get the whole message *and* format it into human-readable text (event messages are PCF). If you want a quick-and-dirty way to get the message, use amqsbcg which will give you a hex dump and then you can use the C header files and a hex calculator to decode it. – T.Rob Dec 16 '10 at 12:49
2

Finally got it working, after 2 days of applying combinations.

To help other (and probably myself also in future), following was the issue:

We were configuring IBM Websphere Application Server with IBM Websphere MQ server. We created queue connection factory, queues and listener ports right. We were getting the exception in question repeatedly.

How did it work is: When you start your application server, the user that is starting the server should have access for MQ. i.e. the user should be part of group MQM. Just to add, after adding the group to the user, do remember to restart MQ server because MQ server refreshes the rights after restart only.

Hope this helps.

Sandeep Jindal
  • 14,510
  • 18
  • 83
  • 121
  • 1
    Bindings or client mode? At best (bindings mode) you have just given the app server authorization to administer WMQ and execute OS commands as the mqm user ID. This is OK in trivial applications but it is equivalent to giving an application full DBA admin rights which most shops would never do. Why they do it with WMQ is a mystery to me. In the worst case (client bindings) you have just given that administrative privilege to anonymous remote users. Basically *anyone* with an IP route to the QMgr can administer it and execute OS commands. Was that what you intended? See http://bit.ly/17oKEc – T.Rob Dec 16 '10 at 12:48
  • 1
    By the way, with either of the tools I linked to in my response you would have sorted this out in two minutes instead of two days. So to help other (and probably yourself also in future), install one or both of these tools now so you don't spin your wheels next time. And if you have *any* interest in securing WMQ, use low-privileged IDs and setmqaut commands rather than sticking the app in the mqm group and lock down all the inbound channels with low-privileged MCAUSER! What you did "works" in the sense that the app can now send messages but it is almost never the right answer. – T.Rob Dec 16 '10 at 13:03
  • +1 Got you! Unfortunately, I am not the expert of MQ server and configuration. Working in services industry, where everything is CRITICAL, we just need to get the things working. In general, understand the Security aspect you mentioned, but as you mentioned, its not very important for my environment as of now! Thanks again! – Sandeep Jindal Dec 17 '10 at 12:10