Has anyone experienced an issue where WAS does not use the Windows username when connecting to a Websphere MQ resource? None of our developer boxes have ever experienced this problem in the past, they’ve been able to send the username through for MQ to do authorization. But we have a new developer machine that does not appear to be sending the username, and thus the connection to MQ can’t be made.
We tried specifying a J2C authentication alias to the QCF with a DefaultPrincipalMapping, but that didn’t work.
SOLUTION: Found out that the problem was that the server was installed and running as a Windows service. When we created a new server profile which was run by the user and not as a service, it used the Windows username when connecting to MQ.
I suspect the problem might actually be the opposite of what you are describing. In older versions of WAS if the User ID field of the Connection Factory panel was left blank, WAS would send a blank ID. WebSphere MQ would have no value to pass along to the Object Authority Manager and so the channel would run under authority of the Message Channel Agent’s process – which is always administrative. Thus, older versions of WAS commonly ran with administrative rights, although this was not widely recognized as such. You can verify this by looking at the status of the running channel and see if the MCAUSER field is blank.
Newer versions of WAS now try a bit harder to find an ID to send to WMQ if the configuration panel is blank. Because of this new installations and upgrades of existing installations often fail to authorize to WMQ using the same channel that previously worked.
The interesting part of all this is that the only way this is an issue is if the QMgr has a blank value on the MCAUSER channel attribute. If the QMgr has a blank MCAUSER and no exit is setting MCAUSER at CONNECT time, then the channel allows administrative access. If the channel does not have SSL with SSLPEER set or an exit to authenticate the connection then that administrative access is available to anonymous users. Why is this an issue? Because WebSphere MQ comes with the ability to initiate OS commands based on arrival of a message. This means that any user with WMQ admin rights can remotely execute arbitrary OS commands as a feature of the software. It follows that this capability MUST be locked down, even from legitimate applications if there is to be any accountability of the messages flowing through the network.
The fact that your app is able to present an ID that succeeds and another ID that fails would seem to indicate that the QMgr is allowing administrative access and, I would wager, doing so for anonymous connections. D’oh! MUCH better to fix the QMgr’s security than to fix the connection problem by setting the “right” ID in WAS. For more on this, see the Hardening WebSphere MQ presentation from the IMPACT conference.