• Codeby web-security - Курс "Тестирование Веб-Приложений на проникновение с нуля" от команды codeby. Общая теория, подготовка рабочего окружения, пассивный фазинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое. Подробнее ...

  • Мобильный клиент нашего форума для Android гаджетов доступен в Google Play Market по этой ссылке. Клиент можно скачать с нашего форума по этой ссылке. Последняя версия МК в нашем телеграм канале вот здесь

Как поменять пароль главного админа сервера?

  • Автор темы KAZ
  • Дата начала
K
#1
Так уж получилось что доступ к id главного админа сервера имеют все кому не лень и пароль все знают...
впорос: как изменить пароль главного админа сервера и назначить ему новую айдишку ?
 

puks

Lotus team
03.02.2007
1 971
8
#2
Для новичка легче всего создать нового пользователя и дать ему те же права. А старого удалить. Хотя и тут могут быть подводные камни (подписи агентов и тп)
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#3
сменить пароль. настроить пользователя на проверку паролей при входе (правда, на сервер)...
хотя, возможно, вариант с заменой юзера не так плох, но тогда придется аккуратно перенести права, а это может занять время и т.п.
 
K
#4
Случилось нечто страшное, я в Current Server Document поставил Not access server для админа и теперь немогу зайти на сервер, помогите срочно !!!! как изменить Current Server Document локально?, а то ведь я даже теперь немогу снять блокировку так как на сервер не заходит

скажите какой файл в лотусе отвечает за Current Server Documet, а то у меня есть бэкап но он совсем старый, я подумал может я просто заменю файлик который отвечает за Current Server
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#5
ну почему они сначала делают?!! )))

и что, никого больше нету с нужными правами?
попробуй файлово скопировать names.nsf с сервака на локальный комп куда-то в папочку, например, lotus/notes/data/serverNames/
но не замени ею локальный names.nsf, в общем.
посмотри кто там имеет доступ...
если ничего хорошего не сможешь выяснить, то попробуй под айдишкой сервера зайти в клиент и открыть базу, дальше ты знаешь...

потом придется остановить сервер, чтобы подсунуть ему names.nsf, либо попытаться репликнуть ее, но лучше файлом...

если ничего лучше не посоветуют, попробуй мой вариант :lol:
 
K
#6
ФУУуууФф СПАСИБО ТЕБЕ Akupaka, я так сделал и теперь норм захожу на сервер! Спасибо еще раз...
Давайте теперь снова по первому вопросу, так значит нового юзака создать , а как отобрать права у старого админа?
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#7
))) ты уже отобрал один раз! тебе мало?
вообще, админ на сервере определяется по наличию определенных записей в Names.nsf в серверном документе...
но кроме этого есть еще множество баз! каждая со своим уникальным ACL!
поэтому процесс смены прав не такой простой... нужно многое обдумать... а может есть стандартный способ, порой в справке админа, на IBM'е...
а главное! не спеши!
 
K
#8
Убрал админа, создал нового, но теперь проблема остался сервер, ведь серверу права не ограничишь, а под ним тоже заходят и делают что хотят....
Как быть, неужели сервер переустанавливать придется и создавать новую айдишку?
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#9
что это за организация такая?.. О.о еще скажи, что банк! ;)
не знаю даже, что и посоветовать... ну, как вариант убрать у сервера права на выполнение кода...
но к базам доступ запретить полностью, наверное, будет неверно... сменить пароль можно, но при каждом запуске придется его вводить...
можно ходить и бить по рукам, пока не отдадут последнюю копию айдишки ;)
 
A

Alexander (Criz)

#10
Надо в ACL баз учётке сервера точно указать что он SERVER (User Type), и тогда юзеры не смогут подключаться под учёткой сервера, а сам сервер сохранит свои права....
 
30.05.2006
1 345
11
#11
Надо в ACL баз учётке сервера точно указать что он SERVER (User Type), и тогда юзеры не смогут подключаться под учёткой сервера, а сам сервер сохранит свои права....
Эт - да.. Но хацкеры сёрверной ID-шкой фоновые агенты подпишут
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 689
305
#12
так - ради смеха :)
завести CA на административном сервере (назначить свой, д.б. не менее двух серверов)
и перегенерять им id админа :( и его учетку через adminp (над деталями - подумать), у них будет невалидный ИД каждый день :), даже ежели новый у вас запросят
СА - шоб сертификатор не понадобился
два сервера - типа шоб базы CA небыло и adminp работал тока на одном
или сертификат отзывать регулярно
 
A

Alexander (Criz)

#13
Эт - да.. Но хацкеры сёрверной ID-шкой фоновые агенты подпишут
Кстати, а подписывать агенты и базы ID сервера (соответственно давать права на выполнение агентов), это насколько нормально? Встречал разные мнения, кто как думает?
 

Мыш

Lotus team
12.02.2008
1 107
12
#14
Эт - да.. Но хацкеры сёрверной ID-шкой фоновые агенты подпишут
А на фига юзерам права дизайнера и права на запуск агентов на сервере? Единственное, правда, с ООО могут быть траблы - не помню точно, под кем он в новых версиях пускается.... Ну или своего написать, в конце концов :)
 
30.05.2006
1 345
11
#15
Кстати, а подписывать агенты и базы ID сервера (соответственно давать права на выполнение агентов), это насколько нормально?
IMHO - это порочная, но общепринятая практика. В один из недостатков оной я и ткнул: смена пароля серверной id-шки не лишит хаЦкеров возможности подписывать фоновые агенты от имени сервера. Т.е. у них будет возможность выполнить на сервере любой код, доступиться к любым (почти) данным
 
K

Klido

#16
смена пароля серверной id-шки не лишит хаЦкеров возможности подписывать фоновые агенты от имени сервера
дык там организация - у всех есть админский id и серверный id, наверное у каждого есть и все юзерские id :)

реально когда я в подобной ситуации был:
- вкл. проверку ключей на сервере (можно и паролей заодно - смотря что за бардак по обычным юзерам, чтоб самому не захлебнуться ;))
- смена ключей админским id (старые не пустит, остается возможность подписи кода)
- создание нового админа, ввод его во все админские группы и FA
- запрет всем остальным операций с базами (создание реплик, баз и шаблонов)
- переподписывание всего кода (раз бардак - баз там мало :))
- вывод скомпрометированного админа (или удаление), тяжелый случай, если на него зашито что-то вроде интертрастовского СМ

по серверу:
- поход в СБ и доклад, что у кого-то есть такой важный файл :) (в принципе, если СБ хорошая - уже можно дальше забить )
- поднимаем рядом сервер и всё переносим туда, старый убиваем
- сложнее, если и cert.id у всех валяется... тогда всех - в новый сертификат

по серверу - есть более тонкие способы - смена ключа сервера:
Поскольку политики применяются только к пользователям, а не к серверам, а также из-за того, что серверы не могут запустить вручную процесс смены ключей, сделать это должны администраторы. Делается это при помощи набора полей на закладке Administration (Администрирование) документа Server, как показано на рис. 5.9.
http://www.intuit.ru/department/security/s...domino/5/6.html
Страшно менять :)
 
Вверх Снизу