Так получилось, что благодаря интересной архитектуре всей системы в целом (которая носит название Information Server), DataStage очень трепетно относится к такой банальной процедуре как смена пароля пользователя, под которым, например, осуществляется редактирование etl-процедур (т.н. джобов) или другие операции.
Такая неразбериха возникает еще и потому, что в продукте существует много различных мест, в которые можно залогиниться, создать пользователей, назначать роли и указывать их пароли. Это как минимум WAS — WebShere application server, Information Server Web Console, и собственно клиенты Designer, Director и Administrator. Процедуры аутентификации на сервере приложений могут быть различными и выбираются исходя политики безопаности компании, на серверах которой разворачивается DataStage. Проблемы возникают в том случае, если аутентификация осуществляется посредством локальной операционной системы (грубо говоря имя пользователя и пароль в ОС совпадает с именами пользователей при входе в административную консоль).
Итак, в этом небольшом посте я попытаюсь рассказать о том как восстановить работоспособность системы после того как была осуществлена процедура смены пароля пользователя ОС.
Заставляем WebSphere изменить все хеши паролей своих пользователей, которые изменились.
Для этого в каталоге
запускаем скрипт
(если сервер DataStage крутится под управлением Windows, то .sh, разумеется, превращается в .bat)
Придется после запуска этого скрипта некоторое время потерпеть, скрипт отрабатывает не вдруг.
Кстати, вам будет, наверное, интересно, что любые пароли, хранимые в любых конфигурационных файлах можно превратить в хеши, используя утилиту
синтаксис которой прост
при этом в значении указываемого свойства должен находится нехешированный пароль.
К пример, если вам необходимо сменить значение поля
Запускаем еще один скрипт, в зависимости от того, как настроен доступ к IS — один или два раза:
и\или
Необходимо зайти в WAS в раздел Security->Global Security->Authentication и изменить пароль для того типа аутентификации, который используется в вашем случае. (Например, LTPA). Не забудьте сохранить изменения в Master Configuration.
После указанных действий необходимо в Web консоли Information Server (обычно она доступна по адресу
Если после указанных действий клиенты Designer, Director или Administrator все еще не могут соедениться с сервером, в этом случае необходимо расшарить репозиторий пользователей Information Server & DataStage (также при помощи Web консоли и вкладки Administration->DataStage credentials).
Такая неразбериха возникает еще и потому, что в продукте существует много различных мест, в которые можно залогиниться, создать пользователей, назначать роли и указывать их пароли. Это как минимум WAS — WebShere application server, Information Server Web Console, и собственно клиенты Designer, Director и Administrator. Процедуры аутентификации на сервере приложений могут быть различными и выбираются исходя политики безопаности компании, на серверах которой разворачивается DataStage. Проблемы возникают в том случае, если аутентификация осуществляется посредством локальной операционной системы (грубо говоря имя пользователя и пароль в ОС совпадает с именами пользователей при входе в административную консоль).
Итак, в этом небольшом посте я попытаюсь рассказать о том как восстановить работоспособность системы после того как была осуществлена процедура смены пароля пользователя ОС.
Шаг 1
Заставляем WebSphere изменить все хеши паролей своих пользователей, которые изменились.
Для этого в каталоге
%ISHOME%/ASBServer/binзапускаем скрипт
./AppServerAdmin.sh -was -user ИМЯ_ПОЛЬЗОВАТЕЛЯ -password НОВЫЙ_ПАРОЛЬ(если сервер DataStage крутится под управлением Windows, то .sh, разумеется, превращается в .bat)
Придется после запуска этого скрипта некоторое время потерпеть, скрипт отрабатывает не вдруг.
Кстати, вам будет, наверное, интересно, что любые пароли, хранимые в любых конфигурационных файлах можно превратить в хеши, используя утилиту
%WASHOME%/AppServer/bin/PropFilePasswordEncoder.sh, синтаксис которой прост
./PropFilePasswordEncoder.sh ИМЯ_ФАЙЛА ИМЯ_СВОЙСТВАпри этом в значении указываемого свойства должен находится нехешированный пароль.
К пример, если вам необходимо сменить значение поля
com.ibm.SOAP.loginPassword в файле soap.client.props, то вам необходимо сделать следующее:- Удалить хеш предыдущего пароля. Хеши в конфигурационных файлах WAS хранятся в виде
{АЛОГРИТМ}ХЕШ. По умолчанию используется XOR шифрование, о чем будет оповещать строчка {xor} перед хешем. Можно смело вместо этой строки написать требуемый пароль в открытом виде; - Запускаем скрипт, в данном примере так:
./PropFilePasswordEncoder.sh "/opt/IBM/WebSphere/AppServer/profiles/default/properties/soap.client.props" com.ibm.SOAP.loginPassword
Запускаем еще один скрипт, в зависимости от того, как настроен доступ к IS — один или два раза:
./DirectoryAdmin -user -userid ПОЛЬЗОВАТЕЛЬ -password ПАРОЛЬи\или
./DirectoryAdmin -user -admin ПОЛЬЗОВАТЕЛЬ -password ПАРОЛЬШаг 2
Необходимо зайти в WAS в раздел Security->Global Security->Authentication и изменить пароль для того типа аутентификации, который используется в вашем случае. (Например, LTPA). Не забудьте сохранить изменения в Master Configuration.
Шаг 3
После указанных действий необходимо в Web консоли Information Server (обычно она доступна по адресу
servername:9080) во вкладке Administration->Users & Groups->Users сменить пароль для нужного пользователя и, разумеется, сохранить изменения. Если после указанных действий клиенты Designer, Director или Administrator все еще не могут соедениться с сервером, в этом случае необходимо расшарить репозиторий пользователей Information Server & DataStage (также при помощи Web консоли и вкладки Administration->DataStage credentials).