WebSphere MQ, работающий под локальной учетной записью / группой, не может читать членство в группах для пользователя Active Directory. Обходной путь или альтернативное решение?
25912
noahz
Я разрабатываю приложение, которое использует WebSphere MQ v6.0. WebSphere MQ в настоящее время не работает из-за следующей проблемы:
Служба WebSphere MQ работает под локальным пользователем «MUSR_MQADMIN» в локальной группе «mqm»
Я пытаюсь использовать сервис, используя свою учетную запись, BIZ \ noahz
MUSR_MQADMIN должен проверить, находится ли BIZ \ noahz в локальной группе "mqm"
MUSR_MQADMIN не имеет разрешения на чтение членства в группе Active Directory в BIZ \ noahz
31.01.2011 18:51:32 - Процесс (704.1105) Программа пользователя (MUSR_MQADMIN) (amqzlaa0.exe) AMQ8079: Доступ запрещен при попытке получить информацию о членстве в группе для пользователя «noahz @ biz».
ОБЪЯСНЕНИЕ: WebSphere MQ, работающий с полномочиями пользователя 'musr_mqadmin @ noahz-biz', не смог получить информацию о членстве в группе для указанного пользователя. ДЕЙСТВИЕ: Убедитесь, что права доступа Active Directory позволяют пользователю 'musr_mqadmin @ noahz-biz' читать членство в группах для пользователя 'noahz @ biz'. Чтобы получить информацию о членстве в группе для пользователя домена, MQ должен запускаться с правами пользователя домена.
У меня нет прав администратора Active Directory для моей машины с Windows, поэтому мой вопрос:
Что еще я могу сделать, чтобы решить (или обойти) эту проблему и заставить WebSphere MQ снова работать на меня? Например, можно ли отключить эту проверку безопасности в WebSphere MQ?
ОБНОВЛЕНИЕ Вот ответ, который я получил от поддержки IBM:
Обычно эти ошибки указывают на проблему с ИД пользователя, под которым настроена служба MQ в dcom. Если вы не уверены, что это за идентификатор пользователя, вы можете проверить следующее:
Откройте командную строку и введите: dcomcnfg. После открытия MMC «Службы компонентов» дважды щелкните «Службы компонентов», дважды щелкните «Компьютеры», дважды щелкните «Мой компьютер», дважды щелкните «Конфигурация DCOM». В окне найдите «IBM MQSeries Services», щелкните по нему правой кнопкой мыши и выберите «Свойства». Нажмите на вкладку «Идентичность». Должен отображаться «этот пользователь», за которым следует идентификатор.
Убедитесь, что у идентификатора MQ-сервисов (на вкладке Identity выше) есть необходимые права локально. Предоставьте ему любые права, которые отсутствуют для следующего:
Откройте Локальные политики, затем Назначение прав пользователя, дважды щелкните, чтобы убедиться, что установлены следующие права: - Вход в систему как пакетное задание - Вход в систему как служба - Завершение работы системы - Отладка программ - Увеличение квот - Работа в качестве части операционной системы - Обход проверка хода - заменить токен уровня процесса
Конечным результатом было то, что мой ИТ-отдел и InfoSec решили, что WebSphere MQ является «серверным программным обеспечением» и поэтому не допускается на отдельных рабочих станциях, поэтому мне даже не удавалось протестировать вышеуказанное решение!
Пожалуйста, смотрите обновление ниже. Не уверен, что это будет работать для вас, но это стоит отметить для других пользователей с подобной проблемой. Если вы хотите передать этот опыт в лабораторию разработчиков WMQ, отправьте Требование WMQ по адресу http://bit.ly/WMQReq, в котором описано, как вы можете решить эту проблему - то есть отключить безопасность во время установки, WMQ-эквивалент HTACCESS. файл, хранилище LDAP, или что-то еще будет работать для вас.
T.Rob 12 лет назад
0
Стоит отметить, что решения, предложенные Робом, Э.Дж. и Эдуардо, направлены на решение проблем, отличных от рассматриваемых. Они работают, удостоверяясь, что ID, представленный MQ, является тем, который MQ может разрешить локально. Первоначальная проблема заключалась в том, что представленный идентификатор не был локальным идентификатором, и MQ необходимо запросить домен, чтобы получить информацию о группе. Чтобы запустить MQ на вашей рабочей станции, эти решения хороши. Если вам нужно убедиться, что Production QMgr не заносит кратер, поскольку был представлен идентификатор домена, следуйте совету IBM или моему ответу, чтобы предоставить необходимые права на MQ svc acct.
T.Rob 9 лет назад
0
Хотя я не смог найти вышеупомянутые записи DCOM (связанные с V7.1?), С помощью ранее упомянутого runas-tip я смог создать, запустить и подключиться к локальному Qmgr Windows V7.1 без доступа к Active Directory., Вот что я сделал:
Измените пароль для пользователя MUSR_MQADMIN в lusrmgr Windows
Убедитесь, что MQService остановлен
В списке услуг также измените пароль для пользователя MUSR_MQADMIN
Откройте DOSbox и выполните: C:> runas / user: MUSR_MQADMIN "crtmqm QMGR1" C:> runas / user: MUSR_MQADMIN "strmqm QMGR1" (обратите внимание, что для каждой команды вы должны будете указать пароль)
Щелкните правой кнопкой мыши значок MQ на панели задач и выберите «WebSphere MQ Explorer»
Откроется MQ Explorer, который должен указать Qmgr «QMGR1» с красной стрелкой, указывающей вниз. Щелкните правой кнопкой мыши этот значок и выберите «Пуск ...»
Во всплывающем окне выберите «Начать интерактивно» и нажмите «ОК».
Иконка QMGR1 теперь должна иметь зеленую стрелку, указывающую вверх (запущено), а ее квадрат должен быть желтым (подключен).
В MQ Explorer создайте очередь с именем TEST1 и сделайте ее постоянство по умолчанию постоянным
В DOSbox выполните: C:> amqsput TEST1 QMGR1 Введите сообщение ... и затем пустую строку для завершения примера программы
Теперь проверьте в MQ Explorer, что ваше сообщение там!
Совет: коды возврата MQ можно быстро проверить с помощью команды "mqrc, fi C:> mqrc 2085
Это было спасение жизни. Я также хотел бы добавить, что может потребоваться запустить MQ Explorer явно как MUSR_MQADMIN, если вы используете это решение.
G_H 10 лет назад
0
1
T.Rob
WebSphere MQ всегда нужно будет получать членство в группе любого идентификатора, пытающегося запустить свои компоненты или авторизовать доступ к своим ресурсам. Если эти идентификаторы не являются локальными, то MQ потребуются права для выполнения поиска членства в SAM в домене, который владеет идентификатором. Есть несколько доступных решений:
Используйте локальный идентификатор. MQ всегда сможет выполнять поиск в локальной базе данных SAM, поскольку он должен быть установлен администратором и предоставил себе соответствующие локальные права во время установки. Это не обязательно должен быть MUSR_MQADMIN, но он должен быть в группе mqm, если он собирается запустить QMgr.
Используйте WMQ Explorer, чтобы запустить QMgr. Любая последняя версия WMQ Explorer предложит разные варианты, один из которых - запустить QMgr под идентификатором, который владеет сервисом. После запуска вы можете использовать свой обычный идентификатор для доступа к очередям и темам.
ОБНОВЛЕНИЕ: Хотелось бы, чтобы я подумал об этом до того, как ваш ИТ-отдел закрылся, но есть возможность отключить Диспетчер прав доступа к объектам. Это компонент, который выполняет поиск в домене AD. Я знаю, что его отключение позволяет любому подключаться к QMgr без проблем с разрешениями домена. Я уверен, что это также позволит вашему идентификатору выполнять процессы, которые запускают QMgr.
Моя проблема в том, что все идентификаторы пользователей и членство в группах управляются централизованно с помощью Active Directory, у меня на самом деле нет прав на все, что вы сказали. Смотрите мой ответ от службы поддержки клиентов IBM, кстати. Спасибо!
noahz 12 лет назад
0
1
ajkret
Я также занимаюсь разработкой приложений с помощью Websphere Message Broker. В настоящее время у меня есть издание для разработчиков. Я нашел способ обойти эту проблему, установив MQ с отключенным поиском членов SAM.
Для этого я запустил «Панель запуска Websphere MQ» (запустите Setup.exe в Windows) из установочного каталога (Websphere_MQ_V7.5). На вкладке «Конфигурация сети» есть возможность отключить конфигурацию User Id. Выберите «Нет» и выполните установку.
Не то чтобы это не лучший вариант для производственной среды и сред QA.
На самом деле было бы гораздо лучше использовать другого пользователя, без пробелов или предварительно настроенного экземпляра Websphere Message Broker. Позже у меня была похожая проблема при запуске приложения.
ajkret 8 лет назад
0
1
simonalexander2005
Я знаю, что это старый вопрос, но с этим я столкнулся пару раз с тех пор; поэтому я решил поделиться своим опытом.
То, что я сделал, было пройти через установщик, выбрав no для параметров пользователя домена; затем:
Убедитесь, что служба работает как учетная запись локальной системы (диспетчер задач -> Службы -> Службы -> IBM Websphere MQ -> Свойства -> Вход в систему -> Учетная запись локальной системы)
Установите переменную среды для отключения OAM ( ПРЕДУПРЕЖДЕНИЕ: ЭТО ОТКЛЮЧАЕТ АУТЕНТИФИКАЦИЮ В MQ ), установивMQSNOAUT=NO
Добавьте всех в группу mqm, чтобы быть в безопасности.
Во всяком случае, у меня это сработало (Windows 7)
Thanks! This is indeed an old question (and I've since moved on from the employer where I encountered this) but I think the core problem I had was no Admin rights over my own machine. Basically, running WebSphere MQ as a developer with no Admin rights on your own machine is a chore :(
noahz 7 лет назад
0
Согласовано!! Но я думаю, что установка этой переменной среды устраняет необходимость в правах администратора или, по крайней мере, для чтения членства в группе
simonalexander2005 7 лет назад
0
0
Eduardo Costa
Я думаю, лучший способ - использовать runas для запуска от имени пользователя mq:
runas /user:MUSR_MQADMIN "strmqm <qmgr-name>"
Ха, спасибо. С момента публикации этого вопроса я удалил WebSphere MQ, но попробую, если в этом возникнет необходимость.
noahz 13 лет назад
0
Смотрите мое последнее обновление.
noahz 12 лет назад
0