WebSphere MQ throws 2035 Auths errors after WAS upgrade to V7

We upgraded WebSphere Application Server to V7 and previously workin开发者_开发问答g applications now get 2035 authorization errors connecting to WebSphere MQ. What is different and how do we fix it?

This is an interesting question. In V6 and earlier if the User ID field on the WAS configuration panel for WMQ was left blank, WAS would use that value (NULL or blanks) as the ID it presented to WMQ on a connection. When WMQ receives a connection request that lacks a User ID it connects using the ID associated with the WMQ channel - which is always administrative and therefore always works.

As of V7, WMQ was changed to try harder to locate a User ID to send with the connection request. In the case of Java/JMS programs, the WMQ client will present the ID of the JVM on a connection request if no other ID was provided. In your case, the app server is now providing an ID whereas before it provided none, and the ID provided is not authorized to WebSphere MQ.

The very fact that this has happened means that your queue manager is configured to accept anonymous administrative connections. The first thing to do here is to lock down all unused inbound channels (those named SYSTEM.* of type RCVR, RQSTR, CLUSRCVR and SVRCONN). Next, make sure that any channels intended for administrative access (SYSTEM.ADMIN.SVRCONN for example) authenticate connections using an exit and/or SSL. If SSL is used, insure that SSLPEER is also used to limit the certificates that can connect.

Finally, once admin access is locked down, take the ID that is supposed to e used for WAS, authorize it's group accordingly and then put that ID in the channel's MCAUSER attribute. This will prevent the app from connecting to the channel as an administrator. If you want to be sure nobody can impersonate the app, set up SSL and/or an exit, the same way you did for the administrative channels.