我正在尝试从WebSphere App Server 7创建JMS连接，但继续获取JMSWMQ2013（使用MQ原因代码2035）。很明显，这是一个身份验证问题，我可以see many other similar reports，因此我对一般问题有了大致的了解。
我正在等待运营团队对渠道确切配置的反馈，但与此同时，我有一个非常令人费解的观察结果。如果我使用WebSphere的JAAS身份验证来提供用户标识，那么我总是会收到JMSWMQ2013错误。但是，如果明确地将相同的用户标识传递给JMS队列连接工厂调用createQueueConnection()，那么我就不会收到验证错误。
说实话，我希望这两种技术都能保持一致。使用JAAS为JMS队列连接工厂提供凭据时，是否存在一些细微之处？
编辑：我使用*=info: JMSApi=all: JMSServer=all: Messaging=all: JMS_WASTraceAdapter=all: com.ibm.mq.*=all: jmsApi=all启用了WAS中的JMS跟踪，并逐行比较输出。
当使用JAAS时，我可以看到JmsXAQueueConnectionImpl的内容深处它实际上正在调用WMQConnection.getProcessUserId()，它返回我的WAS实例正在运行的用户ID（这肯定是不是< / strong>在频道的MCAUSER中定义的用户。）
这一切都很奇怪......似乎根本没有拿起JAAS身份验证条目。我的QCF肯定使用带有DefaultPrincipalMapping的映射配置别名的CLIENT传输，但由于某种原因，它仍然使用进程的用户ID而不是JAAS用户ID。
感谢。 克雷格
答案 0 :(得分：0)
2035肯定是身份验证问题。尝试连接的用户标识无法访问MQ资源。
关于你的以下评论：
如果我使用WebSphere的JAAS身份验证来提供用户ID，那么我 总是得到JMSWMQ2013错误。但是，如果明确地通过了 与JMS队列连接工厂的调用相同的用户ID createQueueConnection（），然后我没有收到身份验证错误。
您的期望是正确的。两种技术都应该以相同的方式运行。如果用户id有访问权限，那么两者都应该连接，如果没有，则两者都应该抛出错误。
只有您的问题的解释可能是，您在不知不觉中在这些应用中发送了不同的用户ID。
就像，您的用户ID是＆＃34; User123＆＃34;，并且它可以访问MQ资源。
然而，可能是WebSphere的JAAS身份验证正在发送域以及用户ID。 比如说，您的用户ID在＆＃34; Developer＆＃34;域，然后发送的用户ID是＆＃34; Developer \ User123＆＃34;，可能无法访问该资源。
答案 1 :(得分：0)
以OS管理员身份运行IBM WebSphere MQ Explorer。 在队列管理器属性中禁用通道的标识记录（菜单链接/连接或类似的smth）。