Здравствуйте. По причинам не зависящим от нас, несколько месяцев назад нам пришлось поменять административный сервер. Мы поменяли его просто записью в names.nsf. После этого вылезло множество проблем с архивами, из-за записи в расположении содержащей старый сервер. Теперь мы хотим поменять обратно на старый сервер, сделав его снова административным, без ошибок. Можете подсказать последовательность шагов что и где поменять. В каких записях, политиках. Заранее спасибо.
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
"обычно" сменой имен (записей в ACL) занимается сам админсервер (по запросам в соответ. БД ).
на почитать есть похожее
Ссылка скрыта от гостей
и от вендора
Ссылка скрыта от гостей
Последнее редактирование:
Хм, может всё-таки кто-нибудь подскажет, какой командой вызвать правильный адинистративный процесс по смене административного сервера? Есть ли вообще такая команда? Как зацепить по максимуму все записи об административном сервере. Зацепит ли это записи в политиках?
Wanderstep
Lotus Team
Описали бы для начала, как изначально было настроено и что вы изменили ранее:
Но если говорить только о назначении административного сервера для БД - строго говоря, это запись в ACL на вкладке Advanced. В БД names.nsf и в других базах, где это необходимо, должен быть указан актуальный административный сервер.
А то вышеупомянутая фраза как-то не освещает, что именно вы сделали, чтобы понять, что вы могли поломать.
О какой записи идет речь? О каких проблемах с архивами?
Нет такой команды в природе. Назначение сервера административным - это комплекс мер, на самом деле. Вам указывали ранее ссылку на гайд, где пошагово дальше описано, что надо делать:
Ссылка скрыта от гостей
Но если говорить только о назначении административного сервера для БД - строго говоря, это запись в ACL на вкладке Advanced. В БД names.nsf и в других базах, где это необходимо, должен быть указан актуальный административный сервер.
КМК, "расположение" - это location. Но в location же home server пользователя указывается, причем тут administration server...
Это клиентские настройки, их можно скриптом поменять, либо проводить реконфигурацию клиента, либо настраивать политику для пользователей.
Desktop policy
Можно как первоначальную сделать, можно динамическую.
Вот я как раз надеялся на наличе админ процесса, который сам меняет везде записи о домэин директори сервер. Но получается, что просто делаем админ сервером обратно старый, а потом вручную правим политики?
Wanderstep
Lotus Team
Не путайте, пожалуйста, терминологию. Админ сервер - это совсем про другое.
Данные о сервере справочника Domino (Domino directory server) можно централизованно распространить по пользователям политиками Domino (setup и desktop settings policy).
По умолчанию, сервер справочника необязательно указывать - он берет значение по умолчанию из поля выше - Home/mail server.
Все-таки, непонятно, как вы ранее поломали и что именно правили централизованно, что теперь у всех пользователей в locations неактуальный сервер?
Опишете нормально, что и как делали, какие ошибки возникли и что обратно вернули - можно будет разобраться и подсказать. А пока вы все загадками говорите да запутываете использованием неверной терминологии.
Данные о сервере справочника Domino (Domino directory server) можно централизованно распространить по пользователям политиками Domino (setup и desktop settings policy).
По умолчанию, сервер справочника необязательно указывать - он берет значение по умолчанию из поля выше - Home/mail server.
Все-таки, непонятно, как вы ранее поломали и что именно правили централизованно, что теперь у всех пользователей в locations неактуальный сервер?
Опишете нормально, что и как делали, какие ошибки возникли и что обратно вернули - можно будет разобраться и подсказать. А пока вы все загадками говорите да запутываете использованием неверной терминологии.
Опишу ситуацию
Есть кластер серверов на котором происходит регистрация пользователей, есть ид-ваулт, и меняется адресная книга домена, настроены CA процессы, сервера хаб1 и хаб2.
Сервер хаб1 указан в качестве административного в адресной книге домена.
Адресная книга распространяется с этих серверов на все другие кластера.
На них настраиваются политики, которые распространяются по всем клиентским машинам пользователей.
Возникла необходимость указать что административный сервер будет хаб2, это было сделано в следующем порядке:
1. В ACL адресной книге был указан хаб2 в качестве административного
2. В политиках указан хаб2 в качестве сервера домино директории.
Спустя некоторое время была проведена миграция почты пользователей на другой сервер админ процессом
Спустя некоторое время старый сервер почты был удален.
После этого выяснилось, что у ряда пользователей (<5%) в локейшенах остались как старый хоум/мэйл сервер так и старый сервер домино директории хаб1
И обновление клиентских машин пользователей согласно политикам не происходило!
После ручной корректировки локейшена работало корректно.
Теперь есть необходимость передать главенство с хаб2 на хаб1
Какой порядок действий, чтобы это сделать корректно и избежать вышеуказанной проблемы?
Есть кластер серверов на котором происходит регистрация пользователей, есть ид-ваулт, и меняется адресная книга домена, настроены CA процессы, сервера хаб1 и хаб2.
Сервер хаб1 указан в качестве административного в адресной книге домена.
Адресная книга распространяется с этих серверов на все другие кластера.
На них настраиваются политики, которые распространяются по всем клиентским машинам пользователей.
Возникла необходимость указать что административный сервер будет хаб2, это было сделано в следующем порядке:
1. В ACL адресной книге был указан хаб2 в качестве административного
2. В политиках указан хаб2 в качестве сервера домино директории.
Спустя некоторое время была проведена миграция почты пользователей на другой сервер админ процессом
Спустя некоторое время старый сервер почты был удален.
После этого выяснилось, что у ряда пользователей (<5%) в локейшенах остались как старый хоум/мэйл сервер так и старый сервер домино директории хаб1
И обновление клиентских машин пользователей согласно политикам не происходило!
После ручной корректировки локейшена работало корректно.
Теперь есть необходимость передать главенство с хаб2 на хаб1
Какой порядок действий, чтобы это сделать корректно и избежать вышеуказанной проблемы?
Ага, целью было вывести сервер из эксплуатации? Так понятнее.
1. Вопрос - зачем вам вообще политика установки "сервера Domino Directory"? Обычно вполне хватает Home/Mail server. Возможно, у вас софт какой-то "от третьей стороны" используется для Notes или адресные книги на серверах должны быть с разным содержимым? По умолчанию это поле пустое (если нет политик).
2. Политики могут не применяться по множеству причин, начиная от версий клиентов, кончая антивирусами и софтом "от третьей стороны" - тот же пресловутый PGPDesktop вспоминается....Возможно, пользователи не запускали клиента в течение времени миграции, например. Тут согласен с уважаемым savl - проще скриптом установить нужные поля, заранее разослав письмо с кнопкой и инструкцией.
Последнее редактирование:
Wanderstep
Lotus Team
Обучение наступательной кибербезопасности в игровой форме. Начать игру!