【发布时间】：2011-07-03 09:03:12
【问题描述】：
我在连接到 IBM MQ 时遇到此错误。我知道这是因为特权，但是有什么方法可以检查与 IBM MQ 的连接吗？
请提出建议。
【问题讨论】：
【发布时间】：2011-07-03 09:03:12
【问题描述】：
我也为此苦苦挣扎多年。最终我找到了这个解决方案。 （如果您可以将关闭身份验证称为解决方案。）
我正在使用版本 - IBM Websphere 9.1.0.201807091223
在 IBM 的网站上，他们建议关闭连接身份验证！！！
解决问题禁用通道认证
您至少需要禁用连接身份验证 暂时地。 FTM for Check 中存在关于以下方面的已知问题 使用 MQ 连接授权。这些问题正在积极解决 已解决，并且修复将出现在未来的修复包中。目标是 修复包 3.0.0.8。
禁用连接认证的步骤：打开 MQ 命令控制台 并输入 runmqsc ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE) CHCKLOCL(NONE) 为此重新启动队列管理器 更改生效。
【讨论】：
您可以使用 dspmqaut 来检查授权。 下面是让用户 poc 访问队列管理器 QM1 和队列 LQ1 的示例
# check the access right of user POC to QM1
dspmqaut -m QM1 -n LQ1 -t q -p poc
# if you want to give access, you should use
setmqaut -m QM1 -n LQ1 -t q -p poc <access Types>
# eg (put everything - in the real live scenario, choose only what you want to grant) :
setmqaut -m QM1 -n LQ1 -t q -p poc +put +get +browse +inq +set +crt +dlt +chg +dsp +passid +setid +setall +clr
然后别忘了用
重启 QM1 endmqm -i QM1
strmqm QM1
最后，您应该能够继续进行，而不会出现错误 2035。
【讨论】：
-
添加新的 OAM 规则后不需要重新启动队列管理器。
-
除非您在 Windows 上使用 MQ 或在 Unix/Linux 上使用带有
SecurityPolicy=user的 MQv8 或更高版本，否则不建议使用-p标志授予权限。这是因为在 v8 之前的 Unix/Linux 上，默认情况下在 v8 和更高版本中，生成的 OAM 规则实际上被授予指定的用户的主要组，而不是用户本身。许多情况会导致这种情况变得糟糕，例如，如果默认情况下大量用户具有相同的主要组（例如：组users）。
你也可以通过设置 mcauser('mqm') 来解决这个问题。我能够克服 2035 错误。
Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)
感谢我的SENIOR Bilal Ahmad (PSE)
【讨论】：
-
这个答案中的建议不好用。您将通过设置
MCAUSER('mqm')为应用程序授予完整的MQ 管理权限。另请注意，在 MQ v7.1 及更高版本中，默认情况下 CHLAUTH 规则将阻止此连接正常工作。
对于在 Windows 上运行的 Q/Q-manager，您可能必须在 Q/Q-manager 机器上创建用户 [即在 Q 机器上创建一个用户以匹配 Q 客户端机器上的用户]，然后将该用户添加到该机器上的 'mqm' 组。
步骤：
-
确保用于创建 Q CLIENT 的域用户 [i.e. Q-client 应用程序正在运行的用户] 也存在于带有 Q/Q-manager 的盒子上。您可能只能在 Q/Q 管理器框中创建一个本地用户 [，或者您可能需要创建一些更复杂的 Active Directory 用户 - 我无法帮助您]。
在 Q/Q 管理器框中，将您刚刚创建的用户 [或现有用户，如果它已经存在] 添加到 mqm 组。 [在 Windows 服务器上，您需要使用 Microsoft 管理控制台（1. 命令行中的“mmc”，2. 文件 > 添加/删除 SnapOn > 本地用户和组，3. 将用户添加到组）]。 'mqm' 组应该已经存在于 Q/Q-manager 机器上。
【讨论】：
-
通过将用户添加到 mqm 组，您将授予该用户完整的 MQ 管理权限（不推荐），应授予应用程序执行其功能所需的最少权限。另请注意，在 MQ v7.1 及更高版本中，默认情况下 CHLAUTH 规则将阻止解析为 MQ 管理员用户的连接工作。
-
@JoshMc 那么推荐的分辨率是多少？
-
在 Windows 上，您可以直接将权限授予用户。在 v8 之前的 unix 上，您可以将用户添加到 mqm 以外的组并授予该组权限。在 v8 及更高版本的 unix 上，您可以在 qm.ini 中设置
SecurityPolicy=user并将权限直接授予用户。
如果您启用授权消息，则 2035 将显示在事件队列中。然后您可以查看消息并查看用于连接的 ID 以及还使用了哪些选项。 2035 可能是因为您要求在队列管理器上设置权限或其他您不应该拥有的权限。授权消息会告诉你。
【讨论】：
-
您有描述如何执行此操作的链接吗？
2035 表明您的连接正在连接到 QMgr。如果您输入了错误的频道名称、主机或端口，您将返回 2059。2035 表示连接已连接到侦听器，找到了所请求名称的频道并尝试连接。
如果您想通过这一点进行测试，则需要授权您用于连接的 ID 或将授权 ID 放入通道的 MCAUSER 属性中。
有关 WMQ 安全性如何在客户端通道上工作的详细说明，请参阅 http://t-rob.net/links 上的 WMQ Base Hardening 演示文稿。
【讨论】：
-
天啊！多么糟糕的技术说明！我将联系 IBM，看看是否可以让他们修复它。请注意，列出的缺陷是 IBM FTM 而不是 MQ 本身。我的建议是正确授权尝试连接的用户。 IBM 是禁用
CONNAUTH。由于CONNAUTH被严重破坏，这是一个很好的建议，但假设有人遵循它，他们仍然需要连接的 ID 才能在 MQ 上得到正确授权。感谢您的链接！
您必须向 MQ 管理员检查权限。
【讨论】：