有沒有人遇到過連接到Websphere MQ資源時WAS不使用Windows用戶名的問題？過去，我們的開發人員盒子都沒有遇到過這個問題，他們已經能夠通過MQ發送用戶名來進行授權。但是我們有一臺新的開發人員機器，似乎沒有發送用戶名，因此無法連接到MQ。WebSphere Application Server 7.0在連接到MQ時忽略Windows userId
我們嘗試使用DefaultPrincipalMapping爲QCF指定一個J2C認證別名，但這不起作用。
SOLUTION：發現問題在於服務器已安裝並作爲Windows服務運行。當我們創建一個由用戶運行而不是作爲服務的新服務器配置文件時，它在連接到MQ時使用了Windows用戶名。
我懷疑這個問題實際上可能與你所描述的相反。在WAS的舊版本中，如果User ID field of the Connection Factory panel保留空白，WAS將發送一個空白ID。 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會議的演示文稿。