1
votes

Recently we were migrated our websphere application server v8.0.0.3 to 8.5.5.8. One application was running which is using IBM MQ java API to connect one third party machine through MQ server connection channel.

Same application working good in v8.0.0.3, but same application is not connecting with MQ in v8.5.5.8. We are getting "MQRC 2035"(NOT AUTHORIZED).

Exact Error:

Could be configuarion, network or service availability issue. Root Cause: MQJE001: Completion Code '2', Reason '2035'

Both older and newer version of application server running as "SYSTEM" user(Windows service).

It can be solve by adding the setmqauth at third party side. but we need some clarification why same application is not working on v8.5.5.8

2

2 Answers

1
votes

WAS v8.0.0.3 comes with IBM MQ RA v7.0.1.7. WAS v8.5.5.8 comes with IBM MQ RA v7.1.0.6.

The behavior of IBM MQ MQ changed in v7.1 to not flow a blank MCAUSER. This is documented in the IBM Technote "Changes in the default user identifier between WebSphere MQ V7.0.1 classes for JMS and WebSphere MQ V7.1 classes for JMS".

Answer

WebSphere MQ access control is based on user identifiers. There is a deliberate change in the default behaviour between the WebSphere MQ V7.0.1 classes for JMS and the WebSphere MQ V7.1 (and later) classes for JMS regarding the default user identifier flowed to the queue manager. From the WebSphere MQ V7.1 classes for JMS onwards, a non-blank user identifier is always flowed to the queue manager when creating a connection to WebSphere MQ.

If the third party side is allowing a blank MCAUSER with WAS v8.0.0.3, it would indicate that third party side is not validating what you pass and worse is likely letting you connect as a MQ admin giving you access to all queues including SYSTEM queues on the queue manager.

0
votes

The issue got resolved after explicitly added the user id in MQEnvironment.

Hashtable mqht = new Hashtable(); mqht.put(CMQC.USER_ID_PROPERTY, userID);

http://www-01.ibm.com/support/docview.wss?uid=swg21138961