На сервере заказчика при установке ПО для управления контроллерами MegaRAID 9580-8i8e и MegaRAID SAS 9171-8I столкнулся с проблемой при попытке авторизации в утилите LSA (LSI Storage Authority). Это программа для управления RAID-контроллерами LSI/Avago/Broadcom в средах Windows и Linux. Она нужна для настройки контроллеров, создания массивов, управления кэшированием, обновления прошивок, а также для мониторинга и фоновой проверки дисков.
Несмотря на то, что я точно знал, что ввожу верные логин и пароль, система упорно выдавала ошибку: Error Code 49: Invalid Credentials.
Поиск решения и первый тупик
Изучив документацию, я наткнулся на статью в базе знаний Broadcom. Там сообщалось, что полная поддержка LSA гарантируется только для англоязычных версий ОС. Поскольку на целевом сервере стояла русскоязычная Windows, проблема, скорее всего, была связана с локализацией.
В источнике предлагалось исправить файл конфигурации:C:\Program Files(x86)\LSI\LSIStorageAuthority\conf\LSA.conf
Нужно найти параметр full_access_groups = Administrators и заменить название группы на локализованный вариант, например Администраторы или Administratory. После правок требовалось перезапустить службу LSAService.
Неудачная попытка
Однако это решение не сработало. Во-первых, путь к файлу на моей машине оказался другим: C:\Program Files\LSI\LSIStorageAuthority\conf\LSA.conf. Во-вторых, замена Administrators на Администраторы (группа с таким именем действительно присутствует в системе) не дала результата.
Я предположил, что проблема в кодировке файла. Пересохранил LSA.conf в ANSI и UTF-8 через стандартный блокнот — безуспешно. Экспериментировать с другими кодировками в Notepad++ не было времени, так как работа велась удаленно.
Нестандартный подход, который сработал
Тогда я решил проверить свою догадку: возможно, название группы используется лишь для проверки при аутентификации, а не для прямой привязки к существующей группе. Я действовал так:
- В файле конфигурации изменил параметр на произвольное имя:
full_access_groups = zzz - Создал в системе группу с точно таким же именем —
zzz. - Добавил своего пользователя в эту группу.
- Перезапустил службу LSAService.
После этих манипуляций вход в LSA прошел успешно. Ошибка исчезла.
Вывод
Если столкнетесь с похожей ситуацией на неанглоязычной ОС, стандартные советы по замене на Администраторы могут не помочь. Рабочим оказался вариант: создать свою группу, назвать ее так же, как указано в параметре full_access_groups, и добавить туда нужного пользователя.
