Пошаговые руководства, шпаргалки, полезные ссылки...
БлогФорумАвторы
Полезные Online-сервисы
Перечень Бесплатного ПО
Подписка на RSS-канал
После того, как все основные настройки кластера 1С:Предприятие 8.3 проведены, обязательным пунктом усиления безопасности серверов 1С является создание учётных записей Администраторов кластера / Администраторов центрального сервера. Эти два типа администраторов имеют разные зоны полномочий. Чтобы полностью закрыть доступ к функциям администрирования серверов 1С и работающих на их базе кластеров, нужно сначала отдельно для каждого сервера создать учётные записи уровня «Администратор центрального сервера», а потом внутри кластера создать учётные записи уровня «Администратор кластера».
Сначала создадим для каждого сервера административные учётные записи уровня «Администратор центрального сервера». Здесь мы можем сделать, как минимум, две административные учётные записи. Одна учётная запись будет иметь локальный характер и хранится в конфигурации сервера 1С, а вторая учётная запись будет привязана к Windows-аутентификации и использовать локальные логины Windows, либо доменные логины службы каталогов Active Directory. Локальная учётная запись 1С со сложным паролем в этом случае вовсе не обязательна, и может быть сделана лишь на тот случай, если вдруг потребуется получить доступ к функциям администрирования сервера 1С, а Windows-аутентификация в этот момент по какой-то причине не заработает.
Итак, сначала «на всякий пожарный» создадим одну учётную запись администратора локального типа (со сложным паролем) …
… а для основной работы с сервером создаём дополнительно учётные записи, привязанные к доменным учётным записям тех пользователей, которые выполняют функции администрирования этого сервера 1С.
Обратите внимание на то, попытка использовать кнопку обзора для выбора доменного пользователя в крупных доменных инфраструктурах с большим количеством пользователей может завершиться полным уходом консоли «в себя» на очень длительное время. Поэтому для доменных учётных записей лучше сразу указывать в поле «Пользователь» данные учётной записи по представленному на скриншоте формату.
В итоге для данного сервера мы получим возможность администрирования Центральным сервером 1С двумя учётными записями. При этом, если консоль администрирования 1С будет открываться в пользовательском окружении Windows-пользователя «Petya», то никаких лишних запросов аутентификации не будет, и доступ к функциям администрирования сервером будет предоставлен автоматически.
Ещё раз обращаем внимание на то, что как только мы создаём на сервере первого администратора, не важно, локальный у него тип или Windows, то последующее подключение после перезапуска консоли потребует успешной аутентификации. Поэтому, чтобы избежать ситуации «отрубили сук, на котором сидим» (в случае проблем с настройкой Windows-аутентификации), нам может оказаться полезной заранее созданная учётная запись локального типа.
Аналогичным образом нам нужно создать пару учётных записей уровня «Администратор центрального сервера» для второго сервера 1С (KOM-APP42). При создании локальной учётной записи сервера 1С (в нашем примере «ServerAdmin») на всех серверах кластера мы можем указать один и тот же пароль. Это позволит при входе в консоль под этой учётной записью на любом из серверов управлять всеми серверами без лишних запросов на ввод пароля.
Для того, чтобы полностью ограничить доступ к функциям управления кластера 1С, нам потребуется создать административные учётные записи уровня «Администратор кластера». Для этого в консоли администрирования развернём соответствующий кластер и по аналогии с вышеописанным примером сначала создадим локальную учётную запись кластера 1С, а затем учётную запись c Windows-аутентификацией для возможности «прозрачного» входа.
В отличие от учётных записей уровня «Администратор центрального сервера», которые могут задаваться на каждом сервере отдельно и могут иметь разные пароли, учтённые записи уровня «Администратор кластера» создаются в кластере один раз и автоматически реплицируются на другие серверы-участники кластера.
После создания административных записей в кластере на первом сервере, переключимся в консоли на второй сервер и убедимся в том, что данные по созданным учётным записям администраторов кластера успешно реплицировались.
Проверено на следующих конфигурациях:
Автор первичной редакции: Алексей Максимов Время публикации: 13.03.2023 15:45