Ошибка «2035» («MQRC_NOT_AUTHORIZED») при подключении к MQ

2035 предполагает, что ваше соединение попадает в QMgr. Если бы у вас было неправильное имя канала, хост или порт, вы бы получили ответ 2059. 2035 означает, что соединение установлено с прослушивателем, найден канал с запрошенным именем и предпринята попытка соединения.

Если вы хотите выполнить проверку после этого момента, необходимо будет либо авторизовать идентификатор, который вы используете для подключения, либо поместить авторизованный идентификатор в атрибут MCAUSER канала.

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

Если вы включите сообщения авторизации, 2035 появится в очереди событий. Затем вы можете просмотреть сообщение и увидеть, какой идентификатор использовался для подключения и какие параметры также использовались. 2035 может быть связано с тем, что вы запросили права доступа к диспетчеру очередей или что-то еще, чего у вас не должно быть. Сообщения авторизации покажут вам это.

Вы также можете решить эту проблему, установив mcauser('mqm') .. я смог преодолеть ошибку 2035.

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

Особая благодарность моему СТАРШЕМУ Билалу Ахмаду (PSE)

Вы должны проверить привилегии у администратора MQ.

Я тоже боролся с этим целую вечность. В конце концов я нашел это решение. (Если вы можете назвать отключение аутентификации решением.)

Я использую версию - 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) Перезапустите диспетчер очередей, чтобы это изменение вступило в силу.

Источник http://www-01.ibm.com/support/docview.wss?uid=swg21962081

Для Q/Q-менеджера, работающего в Windows, вам может потребоваться создать пользователя на машине с Q/Q-менеджером [т.е. создайте пользователя на машине Q, чтобы он соответствовал пользователю на машине Q-client], а затем добавьте этого пользователя в группу «mqm» на этой машине.

Шаги:

1. Убедитесь, что пользователь домена, который используется для создания Q CLIENT [т.е. пользователь, под которым работает приложение Q-client] также существует на коробке с Q/Q-manager. Возможно, вы сможете просто создать локального пользователя в окне Q/Q-manager [или вам, возможно, придется сделать более сложное создание пользователя Active Directory — я не могу вам помочь].

2. В окне Q/Q-manager добавьте только что созданного пользователя [или существующего, если он уже существует] в группу mqm. [На сервере Windows вам нужно будет использовать консоль управления Microsoft (1. 'mmc' из командной строки, 2. Файл > Добавить/удалить SnapOn > Локальные пользователи и группы, 3. добавить пользователя в группу)]. Группа 'mqm' уже должна существовать на машине Q/Q-manager.

Вы можете использовать dspmqaut для проверки гранта. Ниже приведен пример предоставления пользователю poc доступа к Queue Manager QM1 и Queue 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.