在连接到Websphere MQ资源时，是否有人遇到过WAS不使用Windows用户名的问题？我们的开发人员盒子过去都没有遇到过这个问题，他们已经能够通过MQ发送用户名进行授权。但是我们有一个新的开发人员机器似乎没有发送用户名，因此无法建立与MQ的连接。
我们尝试使用DefaultPrincipalMapping为QCF指定J2C身份验证别名，但这不起作用。
解决方案：发现问题是服务器已安装并作为Windows服务运行。当我们创建一个由用户而不是作为服务运行的新服务器配置文件时，它在连接到MQ时使用了Windows用户名。
答案 0 :(得分：3)
我怀疑问题实际上可能与你所描述的相反。在旧版本的WAS中，如果User ID field of the Connection Factory panel留空，WAS将发送空白ID。 WebSphere MQ没有任何值传递给Object Authority Manager，因此该通道将在Message Channel Agent的进程的权限下运行 - 该进程始终是管理的。因此，旧版本的WAS通常具有管理权限，尽管这并未得到广泛认可。您可以通过查看正在运行的频道的状态来验证这一点，并查看MCAUSER字段是否为空白。
如果配置面板为空，现在更新版本的WAS会更难找到要发送到WMQ的ID。由于这种新安装和现有安装的升级，通常无法使用之前工作的相同通道授权WMQ。
所有这一切的有趣之处在于，这是一个问题的唯一方法是，如果QMgr在MCAUSER通道属性上有空白值。如果QMgr有一个空白的MCAUSER并且在CONNECT时没有退出设置MCAUSER，则该通道允许管理访问。如果通道没有设置SSLPEER的SSL或退出以验证连接，则匿名用户可以使用该管理访问权限。为什么这是一个问题？因为WebSphere MQ具有基于消息到达启动OS命令的能力。这意味着具有WMQ管理员权限的任何用户都可以远程执行任意操作系统命令作为软件的功能。因此，如果要对流经网络的消息负责，即使是合法的应用程序，也必须锁定此功能。
您的应用程序能够呈现成功的ID以及另一个失败的ID似乎表明QMgr允许管理访问这一事实，我打算这样做是为了匿名连接。 d＆＃39;哦！更好地修复QMgr的安全性，而不是通过设置＆＃34;右键＆＃34;来解决连接问题。 WAS中的ID。有关详情，请参阅IMPACT会议上的 Hardening WebSphere MQ 演示文稿。