WebSphere MQ windows-to-windows authentication with Java classes

Connecting from a Vista workstation to Windows Server 2003 with WebSphere MQ version 6.x, client is version 7.0.1.3. I can write a very simple .Net program to connect using the AMQMDNET interface to a channel and queue manager, but when doing the same using Java and the com.ibm.mq classes I get a 2537 channel not available. A wire trace shows that the .Net code provides the user SID along with the user id, but the Java invoked code does not fill out the SID. I suspect our admins have set the channel up with the property NTSIDsRequired on the channel (waiting to hear back from the 开发者_JS百科admin).

Anyone know why the Java interfaces wouldn't send the SID by default? I can't find a paramater to use to force this behavior.

Ed

I suspect our admins have set the channel up with the property NTSIDsRequired on the channel...

Actually, if this is the cause it is probably just the opposite. With the default configuration the queue manager will use the SID if provided but otherwise will use the string representation of the account name. If it were to use the string representation and that failed you would get back a 2035 Not Authorized error. On the other hand if NTSIDsRequired were set and a connection attempt was made without a SID then that would result in a refused connection. A 2035 error would be expected, at least at the QMgr side, but it is entirely possible the client would see a 2537 for this.

Note that NTSIDsRequired is not a channel setting. It does apply when a connection request is made but the behavior functions at the Object Authority Manager (OAM) and is exercised for every OAM check made on behalf of the connected client, including OPEN, CLOSE, and SUBSCRIBE. It operates entirely on the queue manager side.

Ordinarily a 2537 is seen if the channel has an exit that refuses the connection. For example the BlockIP2 exit can be set to refuse connections if the User ID is blank, contains an administrative account or originates at an unauthorized IP address (hence the name). Alternatively, the channel may have reached it's max instances or be stopped but neither of these matches your description. The channel exit is a real possibility, though.

The two possibilities are 1) NTSIDsRequired is set and the QMgr is refusing the connection because the SID is not present; or 2) a channel exit is refusing the connection. Because security error messages are intentionally sparse at the client side, diagnosing these will require looking at the messages in the queue manager's error log or Windows Event log on the queue manager's server. If an exit is installed, it might be necessary to review the exit logs as well. If this is due to NTSIDsRequired and authorization events are enabled on the queue manager, I would expect an authorization event to be generated as well. If it is due to an exit or one of the channel instance limits there will be log entries.

Edit:
Doing a little more research I found an Infocenter page stating that the SID is always passed and no distinction is made as to the type of Windows client. Based on this the behavior you are seeing is contrary to the documented behavior and so you should be able to open a PMR on it. The page appears to have been copied verbatim from the same page in the v6 Infocenter so a version mismatch should not present a problem.