Сбой вызова IBM MQ с кодом 2 '(' MQCC_FAILED ') причина' 2035 '(' MQRC_NOT_AUTHORIZED ') - PullRequest
Новая
       31

Сбой вызова IBM MQ с кодом 2 '(' MQCC_FAILED ') причина' 2035 '(' MQRC_NOT_AUTHORIZED ')

1 голос
/ 18 апреля 2019

Я с трудом пытаюсь подключиться к MQ v9 моего учреждения.

Команда MQ предоставила мне информацию о подключении: - 

String hostName = '...'
int port = ...
String queueManager = '...'
String channel = '...'
String userId = 'ABC123'
String password = '...'

Учитывая следующий код... 

JmsConnectionFactory cf = JmsFactoryFactory.
        getInstance(WMQConstants.WMQ_PROVIDER).
        createConnectionFactory()

cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, hostName)
cf.setIntProperty(WMQConstants.WMQ_PORT, port)
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel)
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT)
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManager)
cf.setStringProperty(WMQConstants.USERID, userId)
cf.setStringProperty(WMQConstants.PASSWORD, password)
// tried with both `true` and `false`... same error
cf.setBooleanProperty(WMQConstants.USER_AUTHENTICATION_MQCSP, true)

Connection connection = cf.createConnection()
connection.start()
connection.close()

... Я получаю эту ошибку: - 

Exception in thread "main" com.ibm.msg.client.jms.DetailedJMSSecurityException: 
JMSWMQ2013: The security authentication was not valid 
that was supplied for queue manager '...' with connection 
mode 'Client' and host name '...'.
Please check if the supplied username and password 
are correct on the queue manager to which you are 
connecting.  
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM 
MQ call failed with compcode '2' ('MQCC_FAILED') reason 
'2035' ('MQRC_NOT_AUTHORIZED').

Команда MQ сказала мне, что в журнале есть что-то вроде этого: - 

----- amqzfuca.c : 4527 -------------------------------------------------------
04/17/2019 10:32:20 AM - Process(10468.40757) User(...) Program(...)
                    Host(...) Installation(Installation1)
                    VRMF(9.1.0.1) QMgr(...)
                    Time(2019-04-17T15:32:20.542Z)
                    RemoteHost(...)
                    CommentInsert1(...)
                    CommentInsert2(...)
                    CommentInsert3(CLNTUSER(XYZ) ADDRESS(...))

AMQ9777E: Channel was blocked

EXPLANATION:
The inbound channel '...' was blocked from address '...' 
because the active values of the channel matched a record
configured with USERSRC(NOACCESS). The active values of the channel were
'CLNTUSER(XYZ) ADDRESS(...)'.

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

В то время как я передал другую учетную запись (идентификатор пользователя: ABC123), журнал MQ видит идентификатор пользователя, который я использовал для входа на мою машину (идентификатор пользователя: XYZ).учетные данные, которые я явно передал в опущены?Как это исправить?

Я использую эту зависимость: 

<dependency>
    <groupId>com.ibm.mq</groupId>
    <artifactId>com.ibm.mq.allclient</artifactId>
    <version>9.1.2.0</version>
</dependency>

Я не использую IBM JRE ... точнее, я использую Oracle JDK 1.8 на моемMac, если это поможет.

Спасибо.

ОБНОВЛЕНИЕ 2019-04-22

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

Если я установлю USER_AUTHENTICATION_MQCSP на true, то передается идентификатор пользователя моей машины (XYZ).

ЕслиЯ установил USER_AUTHENTICATION_MQCSP на false, и теперь я получаю другое сообщение об ошибке: - 

04/22/2019 01:19:49 PM - Process(1147099.9759) User(...) Program(...)
            Host(rofesb911a) Installation(Installation1)
            VRMF(9.1.0.1) QMgr(...)
            Time(2019-04-22T18:19:49.323Z)
            RemoteHost(...)
            CommentInsert1(wa03598)
            CommentInsert2(REQUIRED)
            CommentInsert3(MCAUSER(ABC123) CLNTUSER(ABC123) ADDRESS(...))

AMQ9790I: The failed authentication check was caused by a CHLAUTH record with
CHCKCLNT(REQUIRED).

EXPLANATION:
The user ID 'ABC123' and its password were checked because the inbound
connection matched a channel authentication record with CHCKCLNT(REQUIRED).

The active values of the channel were 'MCAUSER(ABC123) CLNTUSER(ABC123)
ADDRESS(...)'. The MATCH(RUNCHECK) mode of the DISPLAY CHLAUTH
MQSC command can be used to identify the relevant CHLAUTH record.

Хорошая новость: он видит правильный идентификатор пользователя (ABC123), но мне сказали парольявляется недействительным.Я не верю, что это была проблема с паролем, потому что я мог использовать те же учетные данные для доступа к другим защищенным веб-службам.

1 Ответ

1 голос
/ 18 апреля 2019

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

Диспетчер очереди не использует ADOPTCTX (ДА)

ADOPTCTX (YES) - это настройка в администраторе очередей, которая указывает, что после того, как идентификатор пользователя и пароль были проверены как правильные, идентификатор пользователя (в вашем случае «ABC123») должен затем использоваться для всех дальнейших проверок безопасности ( например, я могу использовать эту очередь). Если этот параметр НЕТ, то после завершения проверки пароля он фактически будет использовать клиентский компьютер, вошедший в систему с идентификатором пользователя, который также отправляется администратору очередей (в вашем случае «XYZ»). Вполне вероятно, что это относится к вашему менеджеру очередей.

USER_AUTHENTICATION_MQCSP mode

Существует два способа отправки идентификатора пользователя и пароля из клиентского приложения Java администратору очередей.

  1. Первый (несколько десятилетий назад) использовался до IBM MQ V8 и использовал поток ограниченной длины (максимум 12 символов в каждом поле), который изначально был для клиентов DOS SNA для отправки этих двух полей в QMgr. Этот поток через сеть был также способом, которым клиент, вошедший в систему с идентификатором пользователя, был отправлен администратору очередей, и поэтому мог быть отправлен только один.
  2. Более новым, добавленным в MQ V6 и сделанным более полезным при исходной проверке пароля в администраторе очередей в MQ V8, была структура MQCSP, которая допускала поля идентификатора пользователя и пароля переменной длины. Это был сетевой поток, отличающийся от того, который отправляет клиента, вошедшего в систему с идентификатором пользователя, и поэтому оба отправляются администратору очередей.

Когда вы установили для USER_AUTHENTICATION_MQCSP значение true, вы говорили клиенту Java использовать второй режим. Это дает возможность быть отключенным настройкой ADOPTCTX (NO). Если вы установите для него значение false, единственный идентификатор пользователя, который попадет в администратор очередей, - это ABC123 (в вашем примере) и, скорее всего, даст вам другой, возможно, успешный результат.

Попробуйте ваше приложение с USER_AUTHENTICATION_MQCSP, установленным на false, и когда оно сработает, сообщите вашей команде MQ, что им следует использовать ADOPTCTX (YES), который также теперь является значением по умолчанию, затем вы можете переключиться обратно на USER_AUTHENTICATION_MQCSP, установленный на правда.

...