WAS 升级到 V7 后，WebSphere MQ 抛出 2035 Auths 错误
我们将 WebSphere Application Server 升级到 V7，以前工作的应用程序现在在连接到 WebSphere MQ 时出现 2035 授权错误。有什么不同以及我们如何解决它？
We upgraded WebSphere Application Server to V7 and previously working applications now get 2035 authorization errors connecting to WebSphere MQ. What is different and how do we fix it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个有趣的问题。在 V6 及更早版本中，如果 WMQ 的 WAS 配置面板上的用户 ID 字段留空，WAS 将使用该值（NULL 或空白）作为它在连接上向 WMQ 提供的 ID。当 WMQ 收到缺少用户 ID 的连接请求时，它会使用与 WMQ 通道关联的 ID 进行连接 - 这始终是管理性的，因此始终有效。
从 V7 开始，WMQ 已更改为更努力地查找要与连接请求一起发送的用户 ID。对于 Java/JMS 程序，如果未提供其他 ID，WMQ 客户端将在连接请求中显示 JVM 的 ID。在您的情况下，应用程序服务器现在提供一个 ID，而之前没有提供任何 ID，并且所提供的 ID 未授权给 WebSphere MQ。
发生这种情况的事实意味着您的队列管理器被配置为接受匿名管理连接。这里要做的第一件事是锁定所有未使用的入站通道（名为 SYSTEM.* 的 RCVR、RQSTR、CLUSRCVR 和 SVRCONN 类型的通道）。接下来，确保用于管理访问的任何通道（例如 SYSTEM.ADMIN.SVRCONN）使用退出和/或 SSL 对连接进行身份验证。如果使用 SSL，请确保还使用 SSLPEER 来限制可以连接的证书。
最后，一旦管理员访问权限被锁定，获取应该用于 WAS 的 ID，相应地对其组进行授权，然后将该 ID 放入通道的 MCAUSER 属性中。这将阻止应用程序以管理员身份连接到频道。如果您想确保没有人可以冒充该应用程序，请设置 SSL 和/或退出，就像您对管理通道所做的那样。
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.