从mq客户端运行Linux/MQSC命令

A23*_*577 6 linux ibm-mq

好的,我想检查一下我是否可以远程在MQ服务器中运行一些OS或MQSC命令.只要我知道,这可以完成SYSTEM.ADMIN.SVRCONN.为此,我将一个远程队列管理器添加到我的WebSphere MQ客户端.我将队列管理器名称放在具有适当IP的服务器上,但是当我SYSTEM.ADMIN.SVRCONN用作通道名称时,我得到:Channel name not recognized (AMQ4871)错误.

另外,如果我有一个像MY.CHANNEL.NAME频道名称,它是一个服务器连接通道mqm作为它MCAUSER,我可以通过在服务器上该通道运行一些命令(MQSC或OS)?

谢谢.

EDIT1


我正在使用WebSphere MQ v.7.0

通过"我将远程队列管理器添加到我的WebSphere MQ客户端",我的意思是我向MQ Explorer添加了一个远程队列管理器.

EDIT2


我想在这个编辑中更准确地解释我的问题.我想通过MQ Explorer连接到远程Qmanager.我知道Qmanager的名字和它的知识产权.此外,远程Qmanager有两个SYSTEM.ADMIN.SVRCONNSYSTEM.AUTO.SVRCONN频道可用.当我检查CHLAUTH这些频道时,我得到了:

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
     6 : dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
AMQ8414: Display Channel details.
   CHANNEL(SYSTEM.AUTO.SVRCONN)            CHLTYPE(SVRCONN)
   MCAUSER( )
Run Code Online (Sandbox Code Playgroud)

正如你在这里看到的,我应该能够通过这两个通道连接并运行一些命令.但是当我SYSTEM.ADMIN.SVRCONN在远程配置中Channel name not recognized (AMQ4871)选择SYSTEM.AUTO.SVRCONN作为频道名称时,我得到:当我选择作为频道名称时,我得到:You are not authorized to perform this operation (AMQ4036).

任何的想法?

T.R*_*Rob 2

我将远程队列管理器添加到我的 WebSphere MQ 客户端。

我完全不确定这到底意味着什么。MQ Explorer 保留队列管理器定义的列表。MQ Client 只是一个用于建立连接的库。

如果您的意思是向 MQ Explorer 添加了一个远程队列管理器,那么这是有道理的。除了在资源管理器中定义连接之外,您还必须在队列管理器中配置连接。这意味着定义SYSTEM.ADMIN.SVRCONN通道或使用您选择的名称、定义并启动侦听器。如果您使用的是 7.1 或更高版本的队列管理器(在询问 MQ 时最好列出版本),那么您还需要创建一个 CHLAUTH 规则以允许连接,以及另一个 CHLAUTH 规则以允许具有管理权限的连接。或者完全禁用 CHLAUTH 规则,但不建议这样做。

如果我有一个类似的通道名称,并且MY.CHANNEL.NAME它是一个服务器连接通道,我可以通过服务器上的此通道运行一些命令(MQSC 或操作系统)吗?mqmMCAUSER

或许。

MQ 开箱即用,拒绝所有客户端连接。有一些 CHLAUTH 规则可拒绝管理连接,还有其他 CHLAUTH 规则可拒绝SYSTEM.*除 之外的任何通道的连接SYSTEM.ADMIN.SVRCONN。由于管理员连接被拒绝,非管理员用户必须先使用SET AUTHRECsetmqaut命令配置访问权限,然后才能使用SYSTEM.ADMIN.SVRCONN,因此 MQ 被认为是“默认安全的”。

当您以管理员身份创建MY.CHANNEL.NAME并连接时,如果启用了 CHLAUTH,则连接将被拒绝。您必须添加新的 CHLAUTH 规则,例如......

SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD) 
Run Code Online (Sandbox Code Playgroud)

...为了允许管理连接。

(注意:MQ CHLAUTH 阻止规则使用黑名单方法。默认规则阻止 *MQADMIN 所有通道。我上面列出的规则会覆盖默认规则,因为通道名称更具体,并且它会阻止 *NOBODY - 这是一个用户 ID 列表,包括 mqm 或任何其他管理用户 ID。这很奇怪,但这就是它的工作原理。)

有关此主题的更多信息,请访问http://t-rob.net/links,特别是莫拉格关于CHLAUTH规则的会议演讲是必读的。

20150506 更新
对原始问题中的编辑 #1 和 #2 的响应如下:

第一个编辑表示 QMgr 为 v7.0,第二个编辑显示 QMgr 定义了 CHLAUTH 记录。由于 CHLAUTH 在 v7.1 之前才可用,因此这两个语句是互斥的 - 它们不可能同时为真。当提供 MQ 服务器或客户端的版本时,最好粘贴到dspmqver. 如果问题涉及 GSKit、Java 代码或基本代码之外的其他组件,那就dspmqver -a更好了。

问题更新中提供的 MQSC 输出完全解释了这些错误。

dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
Run Code Online (Sandbox Code Playgroud)

正如莫拉格所指出的,SYSTEM.ADMIN.SVRCONN不能使用 ,因为它尚未定义。

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
Run Code Online (Sandbox Code Playgroud)

发生身份验证错误是因为与任何未明确覆盖的 SVRCONN 通道的任何连接都会被此规则阻止。CHLAUTH 规则优先,因为它更明确,并且允许非管理员连接到该通道。缺乏类似的首要规则意味着上面列出的通道的现有规则拒绝了它。 SYSTEM.*SYSTEM.ADMIN.SVRCONNSYSTEM.AUTO.SVRCONNSYSTEM.*

如前所述,强烈建议访问链接网站并阅读 Morag 关于 MQ v7.1 安全性和 CHLAUTH 规则的会议演示。它解释了如何应用 CHLAUTH 规则、优先级如何工作,以及也许最重要的是如何使用MATCH(RUNCHECK)参数验证它们。

要正确实现 MQ 安全性,您至少需要以下各项:

  1. 定义一个名称不以SYSTEM.*和 set开头的通道MCAUSER('*NOBODY')
  2. 定义 CHLAUTH 规则以允许连接到该通道,并根据需要映射 MCAUSER。
  3. 如果您希望使用管理员访问权限连接到通道mqm,请定义 CHLAUTH 规则来对通道进行身份验证,最好使用 TLS 和证书。

有几件事是您不想的,其原因在莫拉格和我的演示中进行了解释。这些包括...

  1. 用于SYSTEM.AUTO.SVRCONN任何合法连接。
  2. 就此而言,使用SYSTEM.*任何内容(除了SYSTEM.ADMIN.SVRCONNSYSTEM.BROKER.*)进行合法连接。
  3. 允许未经身份验证的管理连接。
  4. 禁用 CHLAUTH 规则。
  5. 禁用 OAM。

希望人们学习 MQ 安全性,并且学得很好。然而,作为一名专门从事该领域的顾问,我必须告诉您,即使是雇用我提供现场课程并帮助其实施的客户也很难将其锁定。从这一事实可以得出两点见解。

首先,如果您没有足够的时间来了解 MQ 安全性,那么实施将不安全。要研究该主题以了解所有部分如何充分组合在一起以设计出一个像样的安全模型,需要对 QMgr 进行实践培训,您可以构建、锤炼、拆除、再次构建等等,这需要数周的时间专门的实践学习,或者数月或数年的休闲学习。我的建议是获取 MQ Advanced for Developers。它功能齐全、免费,并且拥有您现在正在使用的 v7.1 或 v7.5 QMgr 上的控件的超集。

第二个见解是,学习 MQ(或任何其他 IT)安全性没有捷径。如果将其视为简单的配置问题,那么几乎可以保证在实施时不安全。如果将其视为学习可用于身份验证、授权和策略执行的所有不同控制,然后学习它们如何交互,并且如果将安全性视为实践的学科,那么就有可能实现一些有意义的安全性。

解决第二个问题需要对教育进行投资。阅读演示文稿并在您管理的测试 QMgr 上实时尝试各种控件。了解哪些错误进入哪些错误日志、哪些错误生成事件消息以及生成哪种类型的事件。获取SupportPacs中的一些诊断工具,例如我最喜欢的MS0P之一,并熟悉它们。考虑参加MQ 技术会议(在那里您可以见到许多在此回复 SO 的人)以获得更深入的培训。

如果您(或您的雇主)还没有准备好致力于深入的技能培养,或者正试图在即将到来的项目截止日期前学习这一点,那么请考虑根据需要雇用深度 MQ 安全技能,因为依赖于即时 -针对此主题的在职培训是不安全网络的秘诀。