• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

    На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.

    Запись на курс до 25 апреля. Получить промодоступ ...

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

  • Автор темы KAZ
  • Дата начала
K

KAZ

Так уж получилось что доступ к id главного админа сервера имеют все кому не лень и пароль все знают...
впорос: как изменить пароль главного админа сервера и назначить ему новую айдишку ?
 

puks

Lotus Team
03.02.2007
1 919
55
BIT
3
Для новичка легче всего создать нового пользователя и дать ему те же права. А старого удалить. Хотя и тут могут быть подводные камни (подписи агентов и тп)
 
A

Akupaka

сменить пароль. настроить пользователя на проверку паролей при входе (правда, на сервер)...
хотя, возможно, вариант с заменой юзера не так плох, но тогда придется аккуратно перенести права, а это может занять время и т.п.
 
K

KAZ

Случилось нечто страшное, я в Current Server Document поставил Not access server для админа и теперь немогу зайти на сервер, помогите срочно !!!! как изменить Current Server Document локально?, а то ведь я даже теперь немогу снять блокировку так как на сервер не заходит

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

Akupaka

ну почему они сначала делают?!! )))

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

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

если ничего лучше не посоветуют, попробуй мой вариант :lol:
 
K

KAZ

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

Akupaka

))) ты уже отобрал один раз! тебе мало?
вообще, админ на сервере определяется по наличию определенных записей в Names.nsf в серверном документе...
но кроме этого есть еще множество баз! каждая со своим уникальным ACL!
поэтому процесс смены прав не такой простой... нужно многое обдумать... а может есть стандартный способ, порой в справке админа, на IBM'е...
а главное! не спеши!
 
K

KAZ

Убрал админа, создал нового, но теперь проблема остался сервер, ведь серверу права не ограничишь, а под ним тоже заходят и делают что хотят....
Как быть, неужели сервер переустанавливать придется и создавать новую айдишку?
 
A

Akupaka

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

Alexander (Criz)

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

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
215
так - ради смеха :)
завести CA на административном сервере (назначить свой, д.б. не менее двух серверов)
и перегенерять им id админа :( и его учетку через adminp (над деталями - подумать), у них будет невалидный ИД каждый день :), даже ежели новый у вас запросят
СА - шоб сертификатор не понадобился
два сервера - типа шоб базы CA небыло и adminp работал тока на одном
или сертификат отзывать регулярно
 
A

Alexander (Criz)

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

Мыш

Lotus Team
12.02.2008
1 220
29
BIT
68
Эт - да.. Но хацкеры сёрверной ID-шкой фоновые агенты подпишут

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

Klido

смена пароля серверной id-шки не лишит хаЦкеров возможности подписывать фоновые агенты от имени сервера

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

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

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

по серверу - есть более тонкие способы - смена ключа сервера:
Поскольку политики применяются только к пользователям, а не к серверам, а также из-за того, что серверы не могут запустить вручную процесс смены ключей, сделать это должны администраторы. Делается это при помощи набора полей на закладке Administration (Администрирование) документа Server, как показано на рис. 5.9.

Страшно менять :)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!