使用 Java 类的 WebSphere MQ 窗口到窗口身份验证
使用 WebSphere MQ 版本 6.x 从 Vista 工作站连接到 Windows Server 2003，客户端版本为 7.0.1.3。我可以编写一个非常简单的 .Net 程序来使用 AMQMDNET 接口连接到通道和队列管理器，但是当使用 Java 和 com.ibm.mq 类执行相同操作时，我得到 2537 通道不可用。线路跟踪显示 .Net 代码提供了用户 SID 以及用户 ID，但 Java 调用的代码未填写 SID。我怀疑我们的管理员已在频道上使用属性 NTSIDsRequired 设置频道（等待管理员的回复）。
有人知道为什么 Java 接口默认不发送 SID 吗？我找不到用于强制此行为的参数。
埃德
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
实际上，如果这是原因，则可能恰恰相反。使用默认配置时，队列管理器将使用 SID（如果提供），否则将使用帐户名的字符串表示形式。如果它使用字符串表示形式并且失败，您将收到
2035 Not Authorized错误。另一方面，如果设置了NTSIDsRequired并且在没有SID的情况下进行连接尝试，那么将导致连接被拒绝。至少在 QMgr 端，预计会出现 2035 错误，但客户端完全有可能会看到 2537 错误。请注意，
NTSIDsRequired不是通道设置。当发出连接请求时，它确实适用，但行为在对象权限管理器 (OAM) 上起作用，并且针对代表连接的客户端进行的每一次 OAM 检查（包括 OPEN）执行代码>、<代码>关闭和<代码>订阅。它完全在队列管理器端运行。通常，如果通道有拒绝连接的出口，则会看到 2537。例如，BlockIP2 exit 可以设置为在用户 ID 为空、包含管理帐户或源自未经授权的情况下拒绝连接IP 地址（因此得名）。或者，通道可能已达到最大实例数或已停止，但这些都不符合您的描述。不过，退出渠道确实有可能。
两种可能性是 1) 设置了 NTSIDsRequired，并且 QMgr 由于 SID 不存在而拒绝连接；或 2) 通道出口拒绝连接。由于安全错误消息在客户端故意稀疏，因此诊断这些消息需要查看队列管理器的错误日志或队列管理器服务器上的 Windows 事件日志中的消息。如果安装了出口，则可能还需要检查出口日志。如果这是由于
NTSIDsRequired造成的，并且在队列管理器上启用了授权事件，我希望也会生成授权事件。如果是由于退出或通道实例限制之一导致的，则会出现日志条目。编辑：
做了更多研究，我发现 信息中心页面指出始终传递 SID，并且不区分 Windows 客户端的类型。基于此，您看到的行为与记录的行为相反，因此您应该能够在其上打开 PMR。该页面似乎是从 v6 信息中心中的同一页面，因此版本不匹配不会出现问题。
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 Authorizederror. On the other hand ifNTSIDsRequiredwere 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
NTSIDsRequiredis 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, includingOPEN,CLOSE, andSUBSCRIBE. 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)
NTSIDsRequiredis 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 toNTSIDsRequiredand 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.