MQ 安全性 - 在一个队列上获得 2035答案

【问题标题】：MQ security - getting a 2035 on one queueMQ 安全性 - 在一个队列上获得 2035
【发布时间】：2014-03-03 19:15:50
【问题描述】：

我有一个应用程序正在尝试将消息放入远程队列管理器上的队列 (LOG.TRANSACTION.IN)。消息以 2035 告终，并被放在本地队列管理器的 DLQ 上。在本地队列管理器 (QMLOCAL) 上，应用程序将消息直接放在 SCTQ 上，因为没有远程队列定义。应用程序在对 MQ 具有完全访问权限的 ID 下运行。我知道这并不理想，但这是另一个讨论。我们在远程端 (QMREMOTE) 的 clusrcvr 通道上有一个 mcauser，它已被授予访问本地队列的权限。我以为我已经解决了安全问题，但事实并非如此。这是安全信息

QMLOCAL：

Entity application_id has the following authorizations for object SYSTEM.CLUSTER.TRANSMIT.QUEUE:  
            get  
            browse  
            put  
            inq  
            set  
            crt  
            dlt  
            chg  
            dsp  
            passid  
            passall  
            setid  
            setall  
            clr

QMREMOTE：

Entity MY_MCAUSER has the following authorizations for object LOG.TRANSACTION.IN:  
        put  
        crt  
        setall

对此的任何帮助将不胜感激。

【问题讨论】：

标签： ibm-mq

【解决方案1】：

这里有几种可能性。由于消息在 DLQ 中结束，因此我们知道问题出在远程端。如果您的放置应用程序生成了 2035，那么该消息将永远不会被放置。

这意味着 CLUSRCVR 频道中的 MCAUSER 是问题所在。为了让它工作，它需要具备以下条件（假设 MY_MCAUSER 在组 mqmmca 中）：

setmqaut -m QMREMOTE -g mqmmca -t qmgr -all +connect +inq +setall
setmqaut -m QMREMOTE -g mqmmca -n 'LOG.TRANSACTION.IN' -t queue -all +put +setall

与你的2035无关，频道也需要
setmqaut -m QMREMOTE -g mqmmca -n 'SYSTEM.CLUSTER.COMMAND.QUEUE' -t queue -all +put +setall
只是为了在集群中发挥作用。根据您的版本，MCAUSER 频道可能还需要访问 SYSTEM.CHANNEL.SYNCQ（v7 变体）。

一个简单的确定方法是启用授权事件。
ALTER QMGR AUTHOREV(ENABLED)

授权事件告诉您失败的 ID、失败的对象（QMgr、队列等）、进行的 API 调用以及使用的选项。

然后将SupportPac MS0P 安装到 WMQ Explorer 中。这会将二进制 PCF 事件消息格式化为人类可读的形式，这将非常明显问题到底出在哪里。

在这种情况下，很可能 a) MCAUSER 在 QMgr 上缺少 +setall 或 b) 它是 v7 并且 MCAUSER 在 S.C.SQ 上缺少适当的权限，如上所述。

【讨论】：

我正在安装最新的 MQ 资源管理器，并将让您了解安全性。奇怪的是，我们使用具有您网站提供的权限的组 MQMMCA，全面拥有相同的权限。这是我们的环境中唯一一个队列管理器放入远程队列的实例，该队列既不是集群的，也不是本地定义的 qr。
另外，这是 AIX 上的 MQ 6.0.2.8。
我真的很想知道您在查看活动消息时会发现什么。远程 QMgr 上的 WMQ 版本和修复包是什么？
哈！什么时间。好的，至少这不是 S.C.SQ 问题。您知道 v6.0 将于 2011 年 9 月终止服务，对吧？请鼓励迁移到 v7，这样您就不会在明年得不到支持。
我们正在进行一个迁移到 v7 的活动项目。这是一个巨大的过程！

【解决方案2】：

我做了一张小照片。希望这能让它更清楚一点。

【讨论】：

嗨，马特，在图片中，顶部框显示了 amqrmppa 的进程名称，并且我认为 ID MQMCA 是 CLUSRCVR 的 MCAUSER 中的 ID。由于 amqrmppa 是运行 inbound 通道的进程，这都指向回复消息的授权问题，而不是请求。（假设流程是从上到下请求，然后从下到上回复。）
在底部框中，DataFlowEngine64 的进程 ID 表明它是代理在打开输出队列时遇到问题。我猜代理会将输出重新排队到 DLQ，因为通常本地应用程序不会自动重新排队输出消息。总而言之，我认为从上到下的消息流是正常的，只是回复流似乎被淹没了。

【解决方案3】：

您也可以通过设置 mcauser('mqm') 来解决此问题。我能够克服 2035 错误。

Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)

感谢我的 Bilal Ahmad (PSE)

【讨论】：