1

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 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

Edleno
  • 11
  • 2

1 Answers1

0

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.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Yes, we have our V7 conversion under way. Don't you find it odd that the client behavior changes depending on .Net versus Java? I would expect the base MQCONN behavior came out of the native binaries and should have passed a SID. All of the MQ7 documentation says that passing a userid and SID is normal Windows client behavior - nothing is said about Java being a lesser client. I've looked into seeing if the real problem is a failed call to the OS to get the SID, but so far I haven't found any reason for getting a SID to fail under Java. – Edleno Feb 16 '11 at 05:04
  • I just updated my response after doing some more digging in the Infocenters. You are right, the behavior should be consistent but it took me a while to find a page that stated as much (and even that page only implies it). – T.Rob Feb 16 '11 at 06:06
  • I did track down that the channel exit was doing a reject. So now I have to track down why that happened (I've got the source for the channel exit, so should be ok there). It could be that the SID isn't returned in the network trace because we didn't get to the point where the SID is provided. Between traces and the code I should be able to figure it out. Thanks for the confirmation. – Edleno Feb 16 '11 at 20:57