WebSphere 7, настройка фабрики соединений JMS Q без идентификатора пользователя: MQRC_NOT_AUTHORIZED - PullRequest
Новая
       36

WebSphere 7, настройка фабрики соединений JMS Q без идентификатора пользователя: MQRC_NOT_AUTHORIZED

7 голосов
/ 16 мая 2011

У меня есть экземпляр WebSphere 6 и экземпляр WebSphere 7. Каждый из них имеет поставщика сообщений WebSphere MQ, фабрику соединений с очередью и очередь, настроенную аналогичным образом. Все поля идентификатора пользователя оставлены пустыми, а псевдонимы аутентификации - "none".

В WAS6 работает нормально.

В WAS7 я получаю ошибку:

JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'. Please check if the supplied username and password are correct on the QueueManager you are connecting to; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

Что может отличаться в способе подключения WAS7 к MQ по сравнению с WAS6, если не указан идентификатор пользователя?

У меня нет никакой видимости или доступа к этому MQ (версия 7), для него не требуется идентификатор пользователя при доступе из WAS 6, поэтому мне нужно, чтобы WAS7 работал так же.

1 Ответ

12 голосов
/ 16 мая 2011

В WAS 6, если вы не указали идентификатор пользователя на панели администрирования, в WMQ был передан пробел. WMQ будет запускать канал, даже если он не может определить удаленного пользователя, и в этом случае канал работает с полномочиями агента канала сообщений (MCA), который всегда является административным. Следовательно, в V6 это работает.

Начиная с V7, клиент WMQ будет немного стараться определить, какой ID передать, если вы оставите его пустым в панели администратора WAS, и получит идентификатор JVM и передаст его при вызове CONNECT. Это источник 2035 года.

Правильный способ исправить это - администратор WMQ должен поместить идентификатор с низким уровнем привилегий в поле MCAUSER канала SVRCONN. Идентификатор должен быть авторизован для любых очередей, которые нужны серверу Java EE, но не для очереди команд и других административных очередей. Это решит проблему, связанную с тем, что WAS 7 отправляет нераспознанный идентификатор , а предотвращает получение доступа администратора любого типа на этом канале.

Альтернативой является переход к панели администратора WAS для соединения WMQ и установка идентификатора пользователя на mqm. (Это работает, если WMQ работает в распределенной системе, отличной от Windows. Если WMQ работает в Windows, z / OS или чем-то еще, подставьте здесь эквивалентный идентификатор платформы.) Хотя это запустит WAS и работает, он не обращается к тот факт, что QMgr предоставляет административный доступ.

Пожалуйста, ознакомьтесь с презентацией и лабораторией WMQ Hardening по адресу http://t -rob.net / links для более полного объяснения того, как определить и устранить основную уязвимость в QMgr.

...