Использование учётной записи gMSA для службы "Агент сервера 1С:Предприятие 8.3" на серверах кластера 1С:Предприятие

Первичный опыт развёртывания кластера 1С:Предприятие 8.3 (в варианте инсталляции с настройками "по умолчанию") и его начальной тестовой эксплуатации выявил некоторые неочевидные особенности функционирования службы агента сервера 1С ("1C:Enterprise 8.3 Server Agent"), выполняющейся в контексте локальной сервисной учётной записи USR1CV8. Изучение этих особенностей и подтолкнуло к мысли о том, что для запуска этой службы на серверах 1С в составе доменной инфраструктуры Active Directory, вместо обычной локальной учётной записи, логичней и безопасней будет использовать учётную запись Group Managed Service Account (gMSA).

Началась вся история с того, что на этапе подготовки серверов под будущий кластер 1С, в ходе инсталляции серверной части 1С:Предприятие 8.3 на каждом из серверов был задан уникальный пароль для вновь создаваемой инсталлятором локальной сервисной учётной записи USR1CV8. И всё было вроде бы хорошо, пока служба агента сервера 1С работала изолировано в рамках локальной системы. Но почти сразу после сборки двух-узлового кластера 1С была обнаружена проблема с периодической блокировкой этой самой локальной учётной записи USR1CV8 на обоих серверах кластера. В следствии такой блокировки через некоторое время останавливалась и служба агента сервера 1С, работающая от имени этой учётной записи.

Ручная разблокировка учётной записи проблема не решала, так как через некоторое время ситуация повторялась и учётная запись заново блокировалась.

Была предпринята попытка установить одинаковый пароль для одноимённых локальных учётных записей USR1CV8 на обоих серверах 1С. После этого блокировки учётных записей прекратились, и как следствие, прекратились неконтролируемые остановки службы агента сервера 1С.

Однако, не смотря на это, в логе безопасности Windows (%SystemRoot%\System32\Winevt\Logs\Security.evtx) на обоих серверах наблюдалась одинаковая картина - каждые несколько секунд продолжали регистрироваться события безуспешных попыток аутентификации локального пользователя USR1CV8 на соседнем сервере кластера 1С.

При этом на каждом из серверов, в каталоге хранения технологического журнала для службы агента сервера 1С (лог процесса ragent), наблюдался бурный рост лог-файлов с регистрацией множества однотипных событий, указывающих на безуспешные попытки взаимной аутентификации.

В данной ситуации простым и очевидным решением оказалось исключение локальной учётной записи USR1CV8 из локальной политики безопасности "Deny access to this computer from the network", в которую "заботливый" инсталлятор сервера 1С включает эту учётную запись по умолчанию. И вроде бы это решило проблемы взаимной аутентификации служб агента сервера 1С между серверами. Однако в ходе дальнейшей эксплуатации серверов 1С стало понятно, что на локальных сервисных учётных записях всё равно "далеко не уедешь", и что серверным процессам 1С рано или поздно всё-равно потребуется доступ к доменным ресурсам.

Сначала мы пробовали запускать службу агента сервера 1С на обоих серверах от имени одной и той же классической учётной записи специально созданного пользователя в домене Active Directory.

Последующий опыт работы с серверами 1С показал, что запускать службу агента 1С на каждом из серверов кластера всё-же лучше от имени отдельных учётных записей домена, так как это будет более правильно и с точки зрения безопасности и будет иметь свои преимущества в случае необходимости выполнения отладки работы 1С.

В конечном итоге, с учётом сильных сторон (опять же с точки зрения безопасности) управляемых служебных учётных записей gMSA, служба агента сервера 1С была настроена на запуск от имени разных gMSA на разных серверах 1С. Собственно, далее мы и рассмотрим пример такой настройки.

Создание сервисных учётных записей gMSA

Итак, создадим в домене для каждого экземпляра службы агента сервера 1С (для каждого сервера) отдельную учётную запись gMSA.

О том, как создать учётную запись gMSA можно посмотреть в статье Вики "Создание учётных записей MSA и gMSA".

В нашем случае с помощью PowerShell в домене создано две учётных записи gMSA с именами s-S031 и s-S032. При этом использование каждой из учётных записей мы разрешим на обоих серверах кластера 1С (в нашем примере KOM-APP31 и KOM-APP32).

$server1 = Get-ADComputer "KOM-APP31"
$server2 = Get-ADComputer "KOM-APP32"
$gMSAou = "OU=Managed Service Accounts,OU=Service Objects,OU=KOM,DC=holding,DC=com"

New-ADServiceAccount -Name "s-S031" -DNSHostName "s-S031.holding.com" `
-PrincipalsAllowedToRetrieveManagedPassword $server1,$server2 `
-ManagedPasswordIntervalInDays 60 -Path $gMSAou 

New-ADServiceAccount -Name "s-S032" -DNSHostName "s-S032.holding.com" `
-PrincipalsAllowedToRetrieveManagedPassword $server1,$server2 `
-ManagedPasswordIntervalInDays 60 -Path $gMSAou

О том, как установить и протестировать созданные в домене управляемые сервисные учётные записи на стороне конечных серверов, мы писали ранее в статье Вики "Установка учётных записей Managed Service Account (MSA) на серверы". Практика показывает, что на серверах Windows Server 2012 R2/2022, для учётных записей gMSA, в отличие от MSA, выполнять установку в явном виде необходимости нет.

Протестируем доступность обеих учётных записей на каждом из серверов 1C:

Install-WindowsFeature -Name "RSAT-AD-PowerShell"
Test-ADServiceAccount -Identity "s-S031"
Test-ADServiceAccount -Identity "s-S032"

Настройка локальных политик безопасности Windows

По аналогии с тем, как по умолчанию настраивает права доступа инсталлятор 1С:Предприятие 8.3 для учётной записи USR1CV8, включим сервисную учётную запись gMSA на соответствующем сервере 1С в локальные группы безопасности "Users" и "Performance Log Users". То есть, включаем только ту учётную запись, от имени которой будет выполняться служба на этом сервере. Например, на сервере KOM-APP31 включим в эти группы учётную запись s-S031.

Затем на каждом из серверов 1С откроем консоль управления локальными политиками безопасности Local Security Policy (secpol.msc) и включим сервисную учётную запись gMSA, от имени которой будет выполняться служба агента сервера 1С на данной системе, в следующие политики:

• "Deny log on locally" ("Запретить локальный вход")
• "Log on as a batch job" ("Вход в качестве пакетного задания")
• "Log on as a service" ("Вход в качестве службы")

Обратите внимание на то, что в нашем случае включать учётную запись gMSA в политику "Deny access to this computer from the network" ("Отказать в доступе к этому компьютеру из сети"), в которую по умолчанию включается локальная учётная запись USR1CV8, - не нужно. В противном случае учётная запись службы агента 1С с первого сервера не сможет входить на второй сервер и наоборот.

Далее, согласно п.16 документа "Check-list по настройке рабочих серверов в продукционной зоне" дополнительно рекомендуется включить служебную учётную запись gMSA в следующие локальные политики безопасности:

• "Adjust memory quotas for a process" ("Настройка квот памяти для процесса")
• "Replace a process level token" ("Замена токена уровня процесса")

Стоит отметить, что использовать две последние политики имеет смысл лишь в том случае, если сервер под задачу 1С:Предприятие используется выделенный и не совмещается с какими-либо другими приложениями.

Настройка доступа к каталогу конфигурации кластера 1С

На каждом сервере предоставим сервисной учётной записи gMSA полный доступ на каталог конфигурации кластера 1С. В конфигурации по умолчанию, этот каталог имеет путь:

• C:\Program Files\1cv8\srvinfo
• C:\Program Files (x86)\1cv8\srvinfo (для 32-битной 1С на 64-битной ОС)

Если расположение каталога менялось, то необходимо предоставить полные права и на каталог в изменённом расположении.

Чтобы назначаемые на каталог права корректно применились с наследованием на подкаталоги и файлы нижнего уровня, перед изменением прав доступа потребуется остановить службу "Агент сервера 1С:Предприятие 8.3" .

Настройка доступа к каталогу технологического журнала 1С

Ранее мы описывали процедуру выноса журналов отладки на отдельный диск. Если такой вынос осуществлялся, то необходимо выдать полные права доступа учётным записям gMSA и на этот каталог.

И опять же, чтобы назначаемые на каталог права корректно применились на вложенные подкаталоги и файлы, перед изменением прав доступа потребуется остановить службу "Агент сервера 1С:Предприятие 8.3".

Настройка службы агента сервера 1С

После того, как выше обозначенные разрешения выданы на уровне локальных политик безопасности и на уровне файловой системы, переходим в оснастку управления службами Windows (services.msc). Здесь откроем свойства службы "Агент сервера 1С:Предприятие 8.3" и на вкладке "Log On" включим режим запуска службы от имени сервисной учётной записи gMSA. При этом, если вписываем имя учётной записи вручную, обязательно в конце имени указать символ "$". Но, лучше, чтобы не ошибиться, воспользоваться кнопкой "Browse" для подбора учётной записи из домена. Пароль для учётной записи при этом указывать не нужно.

Обратите внимание на то, что после настройки запуска службы от имени учётной записи gMSA, при повторном открытии диалоговой формы свойств службы на вкладке "Log On" все элементы управления станут недоступны.

Если в дальнейшем по какой-то причине потребуется внести изменения на этой вкладке, например, настроить запуск службы от имени стандартной учётной записи USR1CV8 или от имени другой учётной записи gMSA, то для возврата возможности редактирования предварительно потребуется выполнить с правами администратора команду вида:

sc managedaccount "Имя службы" false

После настройки службы сохраняем изменения и пробуем запустить/перезапустить службу. Служба должна запуститься без ошибок и теперь можно приступить в проверке работоспособности сервера 1С.

По окончании проверочных мероприятий не забываем заблокировать используемую ранее локальную учётную запись USR1CV8 на серверах кластера 1С:Предприятие.