Обратите внимание, что для MQ v8 и более поздних версий, когда MQ сравнивает пользователя клиента MQ с USERLIST правила TYPE(BLOCKUSER) или с CLNTUSER в правиле TYPE(USERMAP), его можно настроить на просмотр либопользователь клиентский процесс выполняется под или на пользователя, который представлен в MQCSP и успешно аутентифицирован CONNAUTH.Чтобы получить более позднее поведение, вы должны установить ChlauthEarlyAdopt=y в разделе Channels: в qm.ini.Для новых администраторов очередей, созданных в MQ v8.0 LTS и MQ v9.0 LTS, значение по умолчанию НЕ будет устанавливать это, и MQ будет смотреть на пользователя, под которым выполняется клиентский процесс.Для CD MQ v9.0.5, MQ v9.1 LTS и MQ v9.1 CD по умолчанию его устанавливают, и MQ будет смотреть на пользователя, отправленного в MQCSP и успешно аутентифицированного CONNAUTH.
Примечаниепараметр ChlauthEarlyAdopt был добавлен в 8.0.0.5, до этого он всегда смотрел на пользователя, под которым выполняется клиентский процесс.
По умолчанию MQ поставляется со следующим правилом:
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN)
Это правило блокирует всех пользователей, которые, как считает MQ, имеют права администратора MQ, подключаться к ЛЮБОМУ SVRCONN каналу в администраторе очередей.
Вы добавили следующие два правила (обратите внимание, есливы добавляете ВСЕ в свою команду DISPLAY, она не отображает все атрибуты, поэтому я могу обсуждать только то, что вы показываете):
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(TEST1.SRVCNN) TYPE(ADDRESSMAP)
ADDRESS(10.0.2.4) USERSRC(CHANNEL)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(TEST1.SRVCNN) TYPE(BLOCKUSER)
USERLIST(mqm)
Первый (TYPE(ADDRESSMAP)) разрешит соединение с ADDRESS(10.0.2.4) к этому каналу и оставьте пользователя установленным для того, что согласовано на канале.Но в отсутствие любого другого правила MAP, которое блокирует соединения путем установки USERSRC(NOACCESS), это правило действительно ничего не делает.
Если у вас есть SVRCONN канал с пустым MCAUSER, тогда MQ примет имя пользователяэто отправлено от клиента.Для большинства клиентов это пользователь, под которым выполняется процесс, для Java и JMS очень легко отправить любого пользователя, включая пустое значение.Если оба пользователя, отправленные клиентом, и MCAUSER на канале являются пустыми, то согласованный MCAUSER будет тем пользователем, под которым выполняется процесс агента канала сообщений, в unix это обычно будет mqm.
* 1036.*
Второе правило (TYPE(BLOCKUSER)) на самом деле говорит MQ специально блокировать любой канал, куда пользователь mqm посылает с клиента, это, скорее всего, противоположно тому, что вы пытались выполнить.
Если клиентское подключение не является административным приложением, лучший способ исправить это - определить другого пользователя и дать ему разрешение на то, что ему нужно.
См. Мой ответ наСледующий вопрос для получения более подробной информации о том, как предоставить разрешения MQ для пользователя с низким уровнем привилегий: Ошибки авторизации с MQ8 + JDk8
Не было бы хорошей практикой разрешать приложениям подключаться к SVRCONNканал, который не имеет безопасности, вы не упоминаете, используете ли вы CONNAUTH или TLS сертификаты для обеспечения безопасности каналаЭл, но если нет, вам следует использовать один или другой, чтобы определить, кто может подключиться к каналу.