I've been working with a customer recently who ran into an interesting issue which I thought I'd share as it might affect others.
The customer originally had the following configuration:
With this configuration, Listener Ports running inside of the application server were able to successfully connect to the queue manager using an authentication alias that mapped to a user called "mqm".
The customer then upgraded their application server to the 9.0.5.20 level, which also upgraded the version of the MQ resource adapter (RA) embedded within it, as shown in the diagram below:
After doing this, the Listener Ports reported WMSG0019E error containing MQ reason code 2035 (MQRC_NOT_AUTHORIZED) when they tried to connect to the queue manager, as shown in the example below:
WMSG0019E: Unable to start MDB Listener MDBListener1, JMSDestination jms/Q1 : com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for queue manager 'QM1' with connection mode 'Client' and host name 'localhost(1414)'. Please check if the supplied username and password are correct on the queue manager to which you are connecting. For further information, review the queue manager error logs and the Securing IBM MQ topic within IBM Documentation.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:531)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:458)
........
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:203) ... 56 more
The queue manager logs showed that the Listener Ports were flowing the user ID that started the application server process ("wasuser") to it instead of "mqm":
AMQ9557E: Queue Manager User ID initialization failed for 'wasuser'.
EXPLANATION:
The call to initialize the User ID 'wasuser' failed with CompCode 2 and Reason 2035. If an MQCSP block was used, the User ID in the MQCSP block was 'mqm'. If a userID flow was used, the User ID in the UID header was 'wasuser' and any CHLAUTH rules applied prior to user adoption were evaluated case-sensitively
Understandably, the customer wanted to know what had caused this and what could be done to get the Listener Ports to connect again.
Now, the WebSphere Application Server (WAS) upgrade here is significant.
WAS 9.0.5.17 embeds the MQ 9.1.0.16 RA and uses that whenever it needs to communicate with a queue manager. This version of the MQ RA uses connection authentication compatibility mode when authenticating with a queue manager by default.
As shown in the diagrams above, WAS 9.0.5.20 embeds the MQ 9.3.0.20 RA. In this version of the MQ RA, the default connection authentication mode has been changed to MQCSP authentication.
As a result of this change, the user IDs that are flowed between the application server and the queue manager are different.
When using compatibility mode, the MQ resource adapter will just send the user ID specified in the authentication alias to the queue manager. The queue manager then performs some authorization checks on this ID.
In the customer's case, this resulted in the user ID "mqm" being flowed to the queue manager. The user had the required authority, so the checks passed and the Listener Port was able to connect OK.
When the application server is upgraded to the 9.0.5.20 level and the MQ 9.3.0.20 RA is using MQCSP authentication, the MQ RA sends two user IDs to the queue manager. These are:
- The user ID that started the application server.
- The user ID specified in the authentication alias (this is sent, along with the password in the alias, in an MQCSP structure).
For the customer, this meant that both "mqm" and "wasuser" were flowed to the queue manager. Because "wasuser" did not exist on the queue manager system, the authorization check for it failed and the queue manager returned reason code 2035 (MQRC_NOT_AUTHORIZED) back to WAS.
Hopefully this makes sense!
To resolve this, the customer set the Java system property -Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=N on their WAS server as a Generic JVM Argument:
This caused the MQ RA to go back to using connection authentication compatibility mode when talking to the queue manager (which meant that it just flowed the "mqm" user ID to it when the Listener Port started up) rather than using MQCSP authentication.
Now, the customer could have chosen to modify the queue manager configuration to allow the "wasuser" user ID the necessary authority to access the queue manager. However, they decided to keep things simple and just change things on the WAS side.
Oh, and there is one other thing to note. Although this particular customer was using a Listener Port, the change in behaviour will also affect activation specifications that connect to MQ, as well as any enterprise applications that perform outbound messaging too (such as message-driven beans, or MDBs).
As always, I hope this helps! If you want to know more about connection authentication and how it works with the MQ resource adapter, it's worth having a read through the "Connection authentication with the Java client" topic in the MQ sections of the IBM Documentation site. There is a lot of useful detail in there which should help you understand the differences between MQCSP authentication mode and compatibility mode.
Also, if you're interested in knowing more about authentication aliases and how they work with MQ, I'd suggest checking out the Configuring authentication aliases to secure WebSphere Application Server connection to IBM MQ topic in the MQ sections of the IBM Documentation site. That topic goes into them in a lot of detail, and helps explain what user IDs are flowed to the queue manager in different configurations.