有没有人遇到过连接到Websphere MQ资源时WAS不使用Windows用户名的问题？ 过去，我们的开发者盒子都没有经历过这个问题，他们已经能够通过MQ发送用户名来进行授权。 但是我们有一台新的开发人员机器，似乎没有发送用户名，因此无法连接到MQ。
我们尝试用DefaultPrincipalMapping为QCF指定一个J2Cauthentication别名，但这不起作用。
解决scheme：发现问题在于服务器已安装并作为Windows服务运行。 当我们创build一个由用户运行而不是作为服务的新服务器configuration文件时，它在连接到MQ时使用了Windows用户名。
我怀疑这个问题实际上可能与你所描述的相反。 在旧版本的WAS中，如果“ 连接工厂”面板的“ 用户标识”字段留空，则WAS将发送一个空白标识。 WebSphere MQ将没有任何价值传递给对象管理器管理器，因此通道将在消息通道代理程序的权限下运行 – 始终是管理的。 因此，WAS的旧版本通常具有管理权限，尽管这并不被广泛认可。 您可以通过查看正在运行的通道的状态来验证，并查看MCAUSER字段是否为空。
如果配置面板为空，WAS的较新版本现在尝试更难以找到要发送到WMQ的ID。 由于这种新的安装和现有安装升级往往无法使用以前工作的相同通道授权给WMQ。
所有这一切的有趣的部分是，这是一个问题的唯一方法是，如果QMgr在MCAUSER通道属性上有一个空值。 如果QMgr有一个空白的MCAUSER，并且在CONNECT时间没有出口正在设置MCAUSER，那么该通道允许管理访问。 如果通道没有设置了SSLPEER的SSL或用于验证连接的退出，则匿名用户可以使用该管理访问。 为什么这是一个问题？ 因为WebSphere MQ具有根据消息到达发起操作系统命令的功能。 这意味着任何具有WMQ管理权限的用户都可以远程执行任意操作系统命令作为该软件的一个功能 。 因此，如果要对通过网络的消息进行任何责任，则必须锁定此功能，即使是合法的应用程序也是如此。
事实上，你的应用程序能够呈现一个成功的ID和另一个ID失败似乎表明，QMgr允许管理访问，我敢打赌，这样做的匿名连接。 D'哦！ 更好地修复QMgr的安全性，而不是通过在WAS中设置“正确的”ID来解决连接问题。 有关更多信息，请参阅IMPACT会议中的Hardening WebSphere MQ演示文稿。