Mq explorer не может управлять администратором
Обновлено: 06.07.2024
Система разграничения прав строится на предоставлении определённому кругу пользователей доступа к некоторому набору объектов, при этом, к одному и тому же объекту могут быть предоставлены разные права для групп и пользователей в рамках группы. Для того, чтобы предоставленный далее материал был понятен, необходимо выработать общий язык в терминах и определениях, используемых в статье. Давайте рассмотрим их:
Для работы с системой разграничения прав используются команды: setmqaut и dspmqaut, также задать права доступа к объектам можно с использованием графического интерфейса MQExplorer.
Команда setmqaut предназначена для установки и удаления прав на объекты.
-n Profile name, either an object name or a generic profile name.Команда dspmqaut предназначена для просмотра существующих прав установленных для пользователя или группы на определённый объект.
-n Profile name, either an object name or a generic profile name.Все пользователи, которым выдаются права на доступ к очередям, сервисам и т.д. должны иметь права на подключение к менеджеру очередей, именно эти права являются первой стадией проверки доступа пользователя к топологии MQ. Для предоставления простых прав необходимо выдать команду:
setmqaut -m <имя менеджера> -t qmgr -g <имя группы> +connect +dsp +inq setmqaut -m <имя менеджера> -t qmgr -p <имя пользователя> +connect +dsp +inq setmqaut -m <имя менеджера> -n <имя очереди> -t q -g <имя группы> +put +setall +setid setmqaut -m <имя менеджера> -n <имя очереди> -t q -g <имя группы> +browse +getВ случае, если с Вашей топологией работает большое количество пользователей имеет смысл объединить их в одну группу, которой дать права, свойственные для всех пользователей работающих с топологией, например, права на соединение с менеджером.
Для проверки прав доступа к объекту необходимо выдать команду:
dspmqaut -m <имя менеджера> -t q -n <имя очереди> -g <имя группы>7 комментариев на “ Разграничение прав в WebSphere MQ ”
Sergey Kirsanov :Поэкспериментировав с настройкой CHLAUTH в MQ 7.5, удалось выяснить два интересных момента. Было создано правило, разрешающее доступ к каналу для администрирования MQ только пользователю с определённой учётной записью myadmuser:
Если не заключать имя пользователя в одинарные кавычки, то будет создано правило такого вида:
При подключении к каналу учитывается регистр имени пользователя, под которым он вошёл в Windows. Например, если он вошёл как myadmuser, а правило создано для MYADMUSER, он не сможет подключиться к каналу. Если создано оба варианта правила (для верхнего и нижнего регистра), то он всё равно не сможет подключиться, если он вошёл в систему как Myadmuser или myAdmUser или как-то ещё.
И теперь, самое интересное. Если прописать в настройках подключения нужное имя пользователя (например, в MQ Explorer в Connection Properties на вкладке Userid), то правило CHLAUTH сработает, и разрешит доступ, даже если этот пользователь вошёл в Windows под другим именем.
Вывод: в MQ 7.5 нет аутентификации, и правила CHLAUTH для аутентификации по имени пользователя не имеют практического применения, а только лишь создают видимость защиты MQ.
Michael Golubkov :Александр, в MQ никогда не было полноценной системы аутентификации и думаю никогда не будет. До версии 5.3 была встроена система аутентификации на основе связки пользователь/пароль, передаваемой с клиента на сервер. На основе этой системы с использованием канальных выходов безопасности можно было реализовать видимость надёжной системы. Однако, IBM отказалась от данного механизма, в пользу доменной аутентификации, что намного надёжней, поскольку до этого имя и пароль хранились в переменных окружения и передавались по сети в открытом виде. Сейчас, как правильно заметил Сергей, появилась возможность использовать LDAP, что в купе с записями идентификации канала позволяет построить надёжную систему. Для любителей хардкора никто не отменял канальные выходы безопасности и SSL.
Michael Golubkov :Это фича очень полезна администратору, поскольку даёт возможность сразу же проверить правильность созданной им политики для конкретного пользователя.
А если администратор активировал записи идентификации канала, то подобная подстановка для взлома не имеет смысла, поскольку будет отказ ещё на уровне соединения с менеджером.
Sergey Kirsanov :SSL на каналах, выставление конкретного MCAUSER на канале, выдача для этого MCAUSER необходимых прав, вот решение ситуации с авторизацией и разделением доступа.
Как я могу добавить нового пользователя в свою очередь в WebSphere 7.5 MQ Explorer? У меня 90-дневная пробная версия, и у меня нет консоли администратора: / Не знаю почему .
Я хочу подключиться к очереди, размещенной на моем сервере, но я не могу подключиться к учетной записи администратора.
2 ответа
Во-первых, получите версию с неограниченным сроком действия, для которой название продукта - MQ Advanced для разработчиков. На момент написания статьи он доступен в версиях 7.5 и 8.0 и является бесплатным. Если вам нужна поддержка, IBM позволит вам бросить на них деньги, но полнофункциональный продукт с неограниченным сроком действия предоставляется бесплатно.
MQ теперь по умолчанию поставляется в безопасности. Когда вы впервые создаете диспетчер очередей, он отклоняет административные подключения по клиентским каналам. Это позволит неадминистративным каналам использовать SYSTEM.ADMIN.SVRCONN , за исключением того, что до тех пор, пока вы явно не авторизуете их, у неадминистраторов нет прав на QMgr.
(Начиная с версии v8.0, QMgr также настроен по умолчанию на требование идентификатора и пароля, но вам не нужно беспокоиться об этом с MQ v7.5.)
Если вы используете QMgr для Linux или Windows и можете запустить MQ Explorer на хосте, на котором установлен QMgr, подключитесь к QMgr, используя режим привязки, а не канал. Если вы используете ID пользователя с правами администратора (один в группе mqm или в Windows также в группе администраторов), то режим привязки будет работать.
Если вам необходимо подключиться через клиентский канал, вам нужно будет настроить MQ, чтобы разрешить административное подключение и / или подключения пользователей с низким уровнем привилегий. Вы можете сделать это, отключив правила CHLAUTH , но такой подход категорически не рекомендуется. Намного лучше узнать, как работает безопасность MQ, чем отключать ее.
Вы также можете определить новые правила CHLAUTH , разрешающие соединение. Правила по умолчанию для CHLAUTH выглядят так:
Обратите внимание, что первое правило говорит о блокировке пользователей с правами администратора на любом канале. Вы можете добавить новое правило, в котором говорится, что нужно заблокировать некоторых пользователей без прав администратора на канале, который вы хотите использовать для администраторов.
Команда DEF CHL определяет новый канал для администраторов и устанавливает для MCAUSER значение, гарантирующее, что этот канал не запустится.
Первое правило CHLAUTH предписывает MQ заменить неверный MCAUSER на один из запроса на соединение при условии, что запрос исходит от 127.0.0.1 и только для MY.ADMIN.SVRCONN . Введите здесь свой IP-адрес. Вместо этого предпочтительно использовать сертификат вместо IP-адреса для аутентификации соединения.
Второе правило CHLAUTH немного сложное. Не существует правила «РАЗРЕШИТЬ ПОЛЬЗОВАТЕЛЕЙ», поэтому мы должны использовать правило типа TYPE(BLOCKUSER) . Но когда мы блокируем пользователей, мы должны предоставить их непустой список. Нам нужно правило CHLAUTH , в котором имя канала более конкретное, чем имя по умолчанию и со значением USERLIST , которое делает не содержать *MQADMIN или ваш фактический идентификатор пользователя. Я использую здесь *NOBODY , потому что это делает очевидным, что цель состоит в том, чтобы никого не блокировать, а значение не может никогда быть фактическим идентификатором пользователя.
Определение канала только для администраторов считается лучшей практикой. Аутентификация администраторов на основе IP-адреса или имени хоста - нет. После того, как вы подключитесь со своим идентификатором администратора и настроите QMgr, подумайте о том, чтобы узнать достаточно о сертификатах MQ, чтобы строго аутентифицировать подключения администратора. И / или перейдите к V8.0 QMgr и клиенту, где вы можете войти в систему, используя пароль.
MQ Explorer не позволяет вносить изменения в операционную систему, поэтому сначала вам придется создать пользователя в операционной системе другими способами.
Однако, если ваш идентификатор пользователя существует, вы можете использовать MQ Explorer, чтобы предоставить этому пользователю доступ к очереди. Вызовите список очередей в проводнике, а затем щелкните правой кнопкой мыши очередь, в полномочия которой вы хотите добавить пользователя. Выберите «Права доступа к объектам» -> «Управление записями прав доступа . ». Появится мастер, который позволит вам добавить группу или пользователя в очередь.
Вам также нужно будет разрешить этому пользователю подключаться к диспетчеру очередей, как я подозреваю?
WebSphere MQ Explorer – это инструмент, имеющий графический пользовательский интерфейс и предоставляющий возможности навигации, конфигурирования и управления объектами среды MQ.
В данной статье будет рассмотрен процесс установки MQ Explorer и его подключения к менеджеру очередей.
MQ Explorer входит в состав дистрибутива серверной части продукта WebSphere MQ и так же доступен отдельно для скачивания как SupportPac MS0T.
Установка MQ Explorer.
1. Откройте папку с дистрибутивом MQ Explorer:
2. Запустите Setup.exe. Начнется процесс распаковки инсталляционных файлов:
Дождитесь его окончания, после этого запустится диалоговый режим установки:
Нажмите «Next» («Далее»).
3. В следующем окне предлагается ознакомиться с лицензионным соглашением:
Выберите вариант «Я принимаю условия IBM и условия не-IBM», затем нажмите «Next» («Далее»).
4. Укажите, куда следует установить продукт:
5. На данном этапе отображается итоговая информация об устанавливаемом продукте:
Необходимо нажать «Install» («Установить»), после чего начнется процесс установки MQ Explorer:
6. По окончании установки появится окно, информирующее об успешной установке MQ Explorer:
Нажмите «Done» («Готово»), для выхода из установщика.
Запуск MQ Explorer. Подключение к удаленному менеджеру.
1. Для запуска MQ Explorer необходимо нажать «Пуск», затем «Все программы», раскрыть папку «IBM WebSphere MQ Explorer V7.5» и выбрать «MQ Explorer».
После чего начнется запуск MQ Explorer:
Слева представлено дерево навигатора, справа – рабочая область, которая изменяется в зависимости от выбранного в навигаторе раздела.
3. В окне навигатора, нажмите правой кнопкой мыши на разделе «Администраторы очередей», в появившемся всплывающем меню выберите «Добавить удаленный администратор очередей…»
4. В появившемся окне, в поле «Имя администратора очередей» введите имя целевого менеджера, выберите способ подключения «Напрямую». После выполненных действий нажмите «Далее»:
5. В следующем окне заполните сведения о соединении. Укажите имя хоста или ip-адрес, где расположен целевой менеджер, номер порта и канал подключения. Обратите внимание на опцию «Подключать автоматически», по умолчанию она не выбрана. При выборе этой опции, при каждом запуске, MQ Explorer будет автоматически соединяться с менеджером.
После выполненных действий нажмите «Готово».
6. В случае если все сделано правильно, в окне навигатора появится удаленный менеджер:
Если при настройке подключения к менеджеру были допущены ошибки, то появится окно:
Необходимо нажать «Закрыть», после чего появится окно, в котором необходимо нажать «Нет»:
В этом случае следует проверить параметры подключения и попробовать еще раз соединиться с менеджером.
К сожалению, в работе сисадмина нет-нет да и приходится разрешать пользователям запускать всякий софт с админскими правами. Чаще всего это какие-нибудь странные китайские программы для работы с оборудованием. Но бывают и другие ситуации вроде небезызвестного bnk.exe.
Выдавать пользователю права администратора, чтобы решить проблему быстро и просто, противоречит нормам инфобезопасности. Можно, конечно, дать ему отдельный компьютер и поместить в изолированную сеть, но — это дорого и вообще…
Попробуем разобрать решения, которые позволят и программу запустить, и безопасника с финансистом не обозлить.
Программа может запрашивать права администратора условно в двух случаях:
- Когда хочет получить доступ туда, куда «простым смертным» нельзя: например, создавать файлы в системных каталогах.
- Когда программу скомпилировали со специальным флагом «Требовать права администратора».
С первым случаем все понятно: берем в руки замечательную программу Марка Руссиновича Process Monitor, смотрим, что происходит, и куда программа пытается залезть:
Куда это лезет этот 7Zip?
И по результатам исследования выдаем права пользователю на нужный каталог или ветку реестра.
Сложнее, если случай клинический, и так просто выдать права не получится: например, программа требует сильного вмешательства в работу системы вроде установки драйверов. Тогда придется придумывать всякий колхоз, про который речь пойдет в последнем разделе статьи. Пока подробнее освещу второй случай — когда стоит флажок.
Если сильно упростить, то в специальном манифесте программы (к слову, установщики — это тоже программы) могут быть три варианта запуска:
- asInvoker. Программа запускается с теми же правами, что и породивший ее процесс (как правило, это explorer.exe c правами пользователя);
- highestAvailable. Программа попросит максимально доступные пользователю права (у администратора появится окно с запросом повышения UAC, у пользователя — нет);
- requireAdministrator. Программа будет требовать права администратора в любом случае.
Если разработчик твердо решил требовать права администратора, даже если они не нужны, то обойти это можно малой кровью.
В системе Windows, начиная с Vista, появилась служба UAC, которая помимо прочего отвечает за запросы программ на повышение прав. Не все программы «переваривали» работу с этой службой. Поэтому в системе был доработан механизм совместимости приложений, позволяющий прямо задать программе ее поведение — запрашивать права или нет.
Простейшим вариантом работы с этим механизмом будет использование переменных среды.
Рассмотрим пример с редактором реестра. Действительно, запуская regedit.exe под администратором, мы получаем запрос на повышение прав:
Запрос повышение прав.
Если же мы запустим редактор реестра из консоли, предварительно поменяв значение переменной среды __COMPAT_LAYER на:
То запроса UAC не будет, как и административных прав у приложения:
Бесправный редактор реестра.
Этим можно пользоваться, запуская программы батниками или добавляя контекстное меню через реестр. Подробнее читайте в материале How to Run Program without Admin Privileges and to Bypass UAC Prompt?
Поскольку ярлычками тут обойтись не выйдет, ведь 1С сама скачивает файл и запускает его, то придется применять тяжелую артиллерию — Microsoft Application Compatibility Toolkit.
Документация к ПО, как обычно, доступна на официальном сайте, загрузить можно как часть Windows Assessment and Deployment Kit. Сам процесс решения проблемы несложен.
Необходимо поставить утилиту, запустить Compatibility Administrator и создать Application Fix в новой или имеющейся базе данных:
Создаем исправление приложения.
Имя и издатель значения не имеют. Имеет значение только расположение файла — тут нужно указать реальный проблемный bnk.exe (где он будет лежать на самом деле — не важно).
Далее необходимо в списке исправлений выбрать RunAsInvoker.
Выбираем нужный фикс.
Все остальное оставляем по умолчанию, сохраняем базу данных. Должно получиться примерно так:
Созданный фикс для bnk.exe.
После этого достаточно будет установить базу данных, щелкнув по ней правой кнопкой и выбрав Install. Теперь пользователи смогут сами грузить классификаторы банков.
Все становится хуже, если приложению действительно нужны права админа. Тогда добавление прав на системные объекты и исправления не помогают.
Казалось бы, самым очевидным решением для запуска нашего странного ПО выглядит использование встроенной утилиты Runas. Документация доступна на сайте Microsoft.
Ну, посмотрим, что из этого выйдет.
Действительно, RunAs запустит 7zip с правами учетной записи «Администратор», спросит пароль и запомнит его. Потом ярлык с такой строкой запуска будет запускать 7zip под Администратором без вопросов.
)
Есть один существенный недостаток: пароль запоминается на уровне системы, и теперь, используя команду Runas, можно будет запускать абсолютно любую программу. Это мало чем отличается от прямого предоставления админских прав сотрудникам, так что использовать это решение не стоит.
Зато runas может быть полезен, когда сотрудник знает пароль администратора, но работает под ограниченной учетной записью (по идее так должен делать каждый системный администратор).
Если мы начали с консольных команд, то перейдем к более высокоуровневым скриптам. Интересное решение было предложено в статье «Планктонная Windows», где упомянутый выше Runas обвязывался js-скриптом и пропускался через обфускатор. У решения есть и очевидный минус — скрипт можно раскодировать.
Чуть более интересным методом в 2к20 являются возможности PowerShell и его работа с паролями. Подробнее можно почитать в материале «Защита и шифрование паролей в скриптах PowerShell».
Если вкратце: в PS работа с паролями производится через специальный тип данных SecureString и объект PSCredential. Например, можно ввести пароль интерактивно:
Затем сохранить пароль в зашифрованном виде в файл:
И теперь использовать этот файл для неинтерактивной работы:
К сожалению, файл этот можно использовать только на том ПК, на котором его создали. Чтобы этого избежать, можно сделать отдельный ключ шифрования. Например так:
Теперь при помощи этого ключа пароль можно зашифровать:
К сожалению, с безопасностью дела обстоят так же печально: утащить пароль не составляет трудностей, если есть доступ к файлу с ключом шифрования и зашифрованным паролем. Да, можно добавить обфускации и скомпилировать скрипт в .exe вместе с нужными файлами. Но нужно понимать, что это — полумеры.
В свое время я использовал для решения подобных задач свой любимый AutoIt, где компилировал скрипт с командой RunAs и радовался… До тех пор, пока не узнал, что AutoIt (особенно старых версий) декомпилируется на раз-два.
Другим интересным вариантом может быть применение назначенных заданий — если создать назначенное задание от админского аккаунта, пользователю для работы будет достаточно его запуска. К сожалению, для интерактивной работы с приложением это решение не подходит.
На свете существует несколько сторонних решений, призванных решить задачу. Остановлюсь на парочке из них.
Пожалуй, одна из самых известных утилит — это AdmiLink, разработанная Алексеем Курякиным для нужд ядерной физики. Программа и принципы ее работы описаны на официальном сайте. Я, как обычно, позволю себе более краткое описание.
Программа состоит из трех модулей. AdmiLink — это графическое окно, где можно создать ярлык на нужное приложение (в принципе, в ряде случаев достаточно только его).
Основное окно программы.
Помимо непосредственно создания ярлыка (и да, запрос UAC тоже можно подавлять), есть и дополнительные функции вроде калькулятора, терминала и удобных настроек политик безопасности. Со всеми возможностями программы читателю предлагается разобраться самостоятельно.
Второй модуль называется AdmiRun и представляет из себя консольную утилиту. Она умеет запускать приложения от имени администратора, получив в качестве одного из параметров строку, созданную через AdmiLink. В строке шифруется имя пользователя и пароль, при этом участвует и путь к программе.
На первый взгляд все выглядит безопасно, но, к сожалению, код программ закрыт, и насколько можно доверять разработчику — вопрос.
Третий модуль — AdmiLaunch — отвечает за запуск окон в разных режимах, и он используется для запуска AdmiRun, если создавать ярлык через AdmiLink.
В целом, решение проверено годами и поколениями отечественных системных администраторов. Но добавлю и альтернативу из-за рубежа.
RunAsRob — довольно интересное ПО за авторством немецкого разработчика Оливера Хессинга (Oliver Hessing). В отличие от AdmiLink, ПО устанавливается как служба, запускаемая под привилегированной учетной записью (администратора или системы). Как следствие, подготовленный ярлык обращается к службе, которая уже в свою очередь запускает заданное ПО.
Особенность программы в том, что есть возможность авторизовать не только программы, но и папки (включая сетевые). А хранение настроек в реестре позволило добавить шаблоны групповых политик, примерно как мы писали в статье «Погружение в шаблоны и приручение GPO Windows». Благодаря этому при необходимости настройки можно применять прямо из Active Directory.
Основное окно программы.
Программа богато документирована на официальном сайте.
У этого автора есть еще и программа RunAsSpc, позволяющая запускать исполняемые файлы под правами другого пользователя, передавая учетные данные через зашифрованный файл.
Мне остается только добавить, что это ПО бесплатно только для личного использования.
Но учтите, что из программы, запущенной под административными правами, можно натворить бед. Например, запустить привилегированную командную консоль через диалог Файл — Открыть.
Запускаем cmd.exe прямо из редактора реестра.
Немного защититься помогут политики запрета контекстного меню и прочих диспетчеров задач, часть из которых может настроить AdmiLink. Но в любом случае следует быть осторожным.
А вам приходилось городить странные костыли? Предлагаю делиться историями в комментариях.
Читайте также: