AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) потребует, что если пароль передается, что это правильный пароль.
Ошибка AMQ8077, которую вы получаете, потому что у пользователя нет разрешений для подключения к диспетчеру очереди.
Вы должны предоставить разрешение OAM для разрешения clientadmin на connect менеджеру очереди.
По умолчанию на Linux вы можете предоставить права доступа MQ OAM только по отношению к группе, что пользователь является членом, в вашем случае, группа, которая clientadmin является членом. В MQ v8.0, а затем, если следующий параметр был добавлен в qm.ini вы можете также предоставить разрешение OAM против самого пользователя:
Service:
SecurityPolicy=user
выше настройка не требуется, он просто позволяет двумя способами для предоставления разрешений OAM. Это описано на странице Центра знаний IBM MQ v8.0 «Principals and groups». На этой странице говорится:
UNIX и Linux системы
списки ACL основаны на обоих идентификаторов пользователей и групп, и вы можете использовать либо для авторизации.
С Version 8.0 вы можете использовать пользовательскую модель для авторизации, и это позволяет использовать как пользователей, так и группы. Однако, когда вы указываете пользователя в команде setmqaut, новые разрешения распространяются только на этого пользователя, а не на группы, к которым принадлежит этот пользователь.
Для получения дополнительной информации см. Installable services.
Когда вы используете модель для авторизации на основе групп, основная группа, к которой принадлежит идентификатор пользователя, включена в ACL.
Индивидуальный идентификатор пользователя не включен и полномочия предоставляются всем членам этой группы. Из-за этого имейте в виду, что вы можете непреднамеренно изменить полномочия принципала, изменив полномочия другого принципала в той же группе.
Это задокументировано на странице Центра знаний IBM MQ v8.0 «Installable services». На этой странице говорится:
SecurityPolicy = пользователь | группа | по умолчанию
В системах UNIX и Linux значение определяет, использует ли диспетчер очереди пользователя на основе или на основе групповой авторизации. Значения не чувствительны к регистру. Если вы не указали этот атрибут, используется значение по умолчанию, которое использует авторизацию на основе групп. Перезапустите диспетчер очереди, чтобы изменения вступили в силу.
Чтобы предоставить разрешение OAM для подключения к менеджеру очередей по отношению к группе вы можете сделать это либо с помощью команды MQSC SET AUTHREC:
SET AUTHREC PROFILE('self') GROUP('groupname') OBJTYPE(QMGR) AUTHADD(CONNECT,DSP,INQ)
То же самое может быть достигнуто с помощью инструмента командной строки setmqaut:
setmqaut -m <queue_manager_name> -t qmgr -g groupname +connect +dsp +inq
чтобы предоставить разрешение OAM для подключения к менеджеру очередей против Сам пользователь Вы можете сделать это либо с помощью команды MQSC SET AUTHREC:
SET AUTHREC PROFILE('self') PRINCIPAL('clientadmin') OBJTYPE(QMGR) AUTHADD(CONNECT,DSP,INQ)
То же самое может быть достигнуто с помощью инструмента командной строки setmqaut:
setmqaut -m <queue_manager_name> -t qmgr -p clientadmin +connect +dsp +inq
Вы должны были бы также грант PUT или получить доступ к очередь, к которой вы хотите получить доступ. В следующем примере с помощью команды MQSC SET AUTHREC использует основной, но вы можете изменить его, чтобы использовать группу, если требуется:
SET AUTHREC PROFILE('QUEUE.NAME') PRINCIPAL('clientadmin') OBJTYPE(QUEUE) AUTHADD(PUT,GET,BROWSE,DSP,INQ)
То же самое может быть достигнуто с помощью инструмента командной строки setmqaut:
setmqaut -m <queue_manager_name> -t queue -p clientadmin +put +get +browse +dsp +inq
Update 2017/02/21
Установка разрешения на Linux с использованием -p без использования SecurityPolicy = пользователь не рекомендуется. Это связано с тем, что это действие НЕ устанавливает разрешения против пользователя, указанного в -p, вместо этого устанавливает его против основной группы этого пользователя в момент запуска команды.
Это может привести к различным ситуациям, несколько примеров я могу думать ниже:
- Если у вас есть два пользователей с одной и той же основной группе и вы предоставляете им различные уровни доступа, оба они в конечном итоге с тот же уровень доступа, который был получен из последней команды setmqaut, которую вы запускали.
- Даже если вы предоставили им оба одинакового уровня доступа для начала, вы можете удалить доступ от одного из двух пользователей и выдать аналогичную команду с указанным разрешением
-remove. В результате получилось бы не было бы, что вы удалили доступ от одного из двух пользователей, но вместо этого вы удалили его у обоих пользователей.
- Для основной группы учетных записей unix не редкость. Если пользователь не является членом той же группы, что и вторичная группа после изменения, они потеряют доступ к MQ.
Также не рекомендуется обеспечить неадминистративный пользователю +all, если вы сделаете это вы можете также добавить пользователя в группу mqm и предоставить им полную MQ административным органом.
Вместо этого вы должны предоставить пользователю особые разрешения, которые необходимы. В моем примере я представил ограниченный набор разрешений, которые должны работать для большинства приложений.
Существует два метода. 1. Если вы хотите использовать -p и предоставить разрешение конкретному пользователю, вам потребуется настройка SecurityPolicy = user. 2. Если вы хотите предоставить группе, членом которой является пользователь, вам не нужен параметр SecurityPolicy = user и вы можете использовать -g для группы. Неправильно то, что вы устанавливаете свойство SecurityPolicy равным слову clientadmin, возможные значения для этого свойства - 'user' или' group', при этом группа является значением по умолчанию, если вы не устанавливаете значение. Значение «пользователь» - это буквальная строка 'user', не заменяющая ее именем конкретного пользователя. – JoshMc
Бит путать с последним комментарием, для моего приложения «clientadmin» должен иметь привилегию доступа к qmgr и очередям. Я понимаю, чтобы дать соответствующую привилегию с помощью setmqaut, но смутился о значении «SecurityPolicy =». Поскольку мне нужно предоставить доступ к пользовательскому уровню [clientadmin], «SecurityPolicy = clientadmin» - правильный подход? –
Нет, «SecurityPolicy = пользователь» - правильный подход. Параметр представляет собой буквальную четырехзначную строку 'user', а не имя конкретного пользователя. После того, как эта настройка будет установлена, можно использовать разрешения -p. – JoshMc