Запуск команд Linux/MQSC из клиента mq

я добавляю удаленный администратор очередей в свой клиент WebSphere MQ.

я не уверен, что это означает. MQ Explorer сохраняет список определений администратора очередей. MQ Client - это просто библиотека для создания соединений.

если вы имели в виду, что добавили удаленный администратор очередей в MQ Explorer, то это имеет смысл. В дополнение к определению соединения в Проводнике, вам также придется подготовить соединение в Администраторе очередей. Это средство определение SYSTEM.ADMIN.SVRCONN канал или один с именем по вашему выбору, определение и запуск слушателя. Если вы находитесь в Администраторе очередей 7.1 или выше (всегда полезно перечислять версии при запросе о MQ), вам также необходимо создать правило CHLAUTH, чтобы разрешить соединение, и другое правило CHLAUTH, чтобы разрешить соединение с правами администратора. либо это, либо вообще отключить правила CHLAUTH, но это не рекомендуется.

если у меня есть имя канала, как MY.CHANNEL.NAME и это канал подключения к серверу с mqm как его MCAUSER, могу ли я запустить некоторые команды (MQSC или OS) через этот канал на сервере?

может быть.

из коробки MQ отрицает все клиентские соединения. Есть правила параметром chlauth отрицать административные связи, и другие правила параметром chlauth, чтобы запретить подключения для любого SYSTEM.* канал, кроме SYSTEM.ADMIN.SVRCONN. Поскольку подключения администратора запрещены, пользователи, не являющиеся администраторами, должны иметь доступ, подготовленный с помощью SET AUTHREC или setmqaut команды, прежде чем они могут использовать SYSTEM.ADMIN.SVRCONN, следовательно, MQ считается " безопасным по умолчанию."

при создании MY.CHANNEL.NAME и подключиться как администратор, и если chlauth включен, соединение будет отклонено. Вам нужно будет добавить новое правило CHLAUTH, например...

SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD) 

...для того, чтобы разрешить подключение админ.

(Примечание: правила блокировки MQ CHLAUTH используют методику черного списка. Правило по умолчанию блокирует *MQADMIN со всех каналов. Правило, указанное выше, переопределяет правило по умолчанию, поскольку имя канала является более конкретным и блокирует *NOBODY - это список идентификаторов пользователей, которые делают не включить MQM или любой другой ID административного пользователя. Это странно, но так это работает.)

подробнее на эту тему в http://t-rob.net/links, и в частности презентация Мораг на конференции CHLAUTH правила должен прочитать.

20150506 обновление
Ответ на изменения #1 & #2 в исходном вопросе выглядит следующим образом:

первая правка говорит о том, что на "qmgr" на В7.0, а второй показывает, что на "qmgr" имел параметром chlauth записей, определенных. С параметром chlauth не доступен до В7.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.

как отмечает Мораг,SYSTEM.ADMIN.SVRCONN не может использоваться, потому что он не был определен.

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)

ошибка auths происходит потому, что любой подключение к любой SYSTEM.* канал SVRCONN, который явно не переопределение блокируется этим правилом. Правила параметром chlauth для SYSTEM.ADMIN.SVRCONN имеет приоритет, потому что он более явный и позволяет подключаться к этому каналу без администратора. Отсутствие аналогичного переопределяющего правила для SYSTEM.AUTO.SVRCONN означает, что существующее правило для SYSTEM.* каналы, как указано выше.

как отмечалось ранее, это сильно рекомендуется перейти на связанный веб-сайт и прочитать презентацию конференции Мораг на MQ v7.1 безопасность и Правила параметром chlauth. Он объясняет, как применяются правила CHLAUTH, как работает приоритет и, возможно, самое главное, как проверить их с помощью MATCH(RUNCHECK) параметр.

чтобы сделать MQ Security right, вам нужно по крайней мере следующее:

1. определить канал с именем, которое не начинается с SYSTEM.* и set MCAUSER('*NOBODY').
2. определите правило CHLAUTH, чтобы разрешить соединения с этим каналом, сопоставляя MCAUSER как требуемый.
3. если вы хотите подключиться к каналу с mqm или доступ администратора, определите правила CHLAUTH в аутентифицировать канал, предпочтительно с использованием TLS и сертификатов.

есть несколько вещей, которые вы делаете не хочу сделать, по причинам, которые объясняются в моей презентации Мораг. В их числе...

1. используя SYSTEM.AUTO.SVRCONN для любой законной подключение.
2. если на то пошло, используя SYSTEM.* что-нибудь (кроме SYSTEM.ADMIN.SVRCONN или SYSTEM.BROKER.*) на законных подключений.
3. разрешение несанкционированных подключений администратора.
4. отключение правил CHLAUTH.
5. отключение OAM.

я хочу люди, чтобы узнать MQ security, и узнать его очень хорошо. Однако, как консультант, который специализируется на ИТ, я должен сказать вам, что даже клиенты, которые наняли меня, чтобы дать классы на месте и помощь в их реализации имеют проблемы с блокировкой. Из этого факта можно сделать два вывода.

во-первых, если вы не достаточно времени, чтобы получить до скорости на MQ безопасности, то реализация не будет безопасным. Чтобы изучить тему до понимания того, как все части подходят друг к другу достаточно хорошо, чтобы разработать достойную модель безопасности, требуется практическое обучение с QMgr, которое вы можете построить, забить, снести, построить снова и т. д. требуются недели самоотверженных практических занятий, месяцы или годы случайных занятий. Мой совет здесь - получить MQ Advanced для разработчиков. Он полностью функциональный, бесплатный и имеет надмножество элементов управления, которые у вас есть на v7.1 или v7.5 QMgr, над которым вы сейчас работаете.

второе понимание заключается в том, что нет ярлыка для изучения безопасности MQ (или любой другой ИТ). Если к нему подойти, как если бы это был просто вопрос конфигурации, то он почти гарантированно не будет безопасным, когда выполненный. Если подходить к нему как к изучению всех различных элементов управления, доступных для аутентификации, авторизации и применения политики, а затем к изучению того, как они все взаимодействуют, и если к безопасности подходить как к дисциплине практики, то можно достичь некоторой значимой безопасности.

решении второго вопроса потребует инвестиций в образование. Прочитайте презентации и попробуйте различные элементы управления live на тестовом QMgr, который вы администрируете. Поймите, какие ошибки идут в какие журналы ошибок, которые генерируют сообщения о событиях и какие типы событий генерируются. Получите некоторые из диагностических инструментов в SupportPacs, например MS0P, который является одним из моих любимых, и познакомиться с ними. Подумайте о посещении MQ Tech Conference (где вы можете встретить многих людей, отвечающих здесь на SO) для более углубленного обучения.

если вы (или ваш работодатель) не готовы посвятите себя углубленному формированию навыков или попытайтесь изучить это в течение ближайшего срока проекта, а затем рассмотрите возможность найма глубоких навыков безопасности MQ по мере необходимости, потому что опора на обучение точно в срок на работе по этой теме является рецептом для небезопасной сети.