WebSphere Application Server 7.0 игнорирует идентификатор пользователя Windows при подключении к MQ

Кто-нибудь сталкивался с проблемой, когда WAS не использует имя пользователя Windows при подключении к ресурсу Websphere MQ? Ни один из наших блоков разработчика никогда не сталкивался с этой проблемой в прошлом, они смогли отправить имя пользователя для MQ для авторизации. Но у нас есть новая машина разработчика, которая, похоже, не отправляет имя пользователя, и поэтому невозможно установить соединение с MQ.

Мы попытались указать псевдоним аутентификации J2C для QCF с помощью DefaultPrincipalMapping, но это не сработало.

РЕШЕНИЕ. Выяснилось, что проблема заключалась в том, что сервер был установлен и работал как служба Windows. Когда мы создали новый профиль сервера, который запускался пользователем, а не как служба, он использовал имя пользователя Windows при подключении к MQ.


windows java websphere ibm-mq jakarta-ee
person Kaleb Brasee    schedule 09.06.2011    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я подозреваю, что проблема может быть на самом деле противоположна тому, что вы описываете. В старых версиях WAS, если файл Идентификатор пользователя на панели Фабрики соединений был оставлен пустым, WAS отправлял пустой идентификатор. WebSphere MQ не будет иметь никакого значения для передачи диспетчеру прав доступа к объектам, поэтому канал будет работать под управлением процесса агента канала сообщений, который всегда является административным. Таким образом, более старые версии WAS обычно работали с правами администратора, хотя это не было широко признано. Вы можете убедиться в этом, посмотрев состояние работающего канала и посмотрев, пусто ли поле MCAUSER.

Более новые версии WAS теперь пытаются найти идентификатор для отправки в WMQ, если панель конфигурации пуста. Из-за этого новые установки и обновления существующих установок часто не позволяют авторизоваться в WMQ, используя тот же канал, который работал ранее.

Интересная часть всего этого заключается в том, что проблема возникает только в том случае, если QMgr имеет пустое значение в атрибуте канала MCAUSER. Если QMgr имеет пустой MCAUSER и ни один выход не устанавливает MCAUSER во время ПОДКЛЮЧЕНИЯ, то канал разрешает административный доступ. Если канал не имеет SSL с установленным SSLPEER или выходом для аутентификации соединения, то этот административный доступ доступен для анонимных пользователей. Почему это проблема? Потому что WebSphere MQ имеет возможность инициировать команды ОС в зависимости от поступления сообщения. Это означает, что любой пользователь с правами администратора WMQ может удаленно выполнять произвольные команды ОС в качестве функции программного обеспечения. Из этого следует, что эта возможность ДОЛЖНА быть заблокирована, даже для легитимных приложений, если должна быть какая-либо подотчетность сообщений, проходящих через сеть.

Тот факт, что ваше приложение может представить успешно выполненный идентификатор и другой неудачный идентификатор, по-видимому, указывает на то, что QMgr разрешает административный доступ и, я бы поспорил, делает это для анонимных подключений. О! НАМНОГО лучше исправить безопасность QMgr, чем решить проблему с подключением, установив «правильный» идентификатор в WAS. Подробнее об этом см. в презентации Усиление WebSphere MQ на конференции IMPACT.

person T.Rob    schedule 09.06.2011