Занявшись вопросом установки кластера сервера приложений 1С я без удивления для себя обнаружил, что в сети достаточно много информации по тому как это делать, что означает тот или иной параметр конфигурации, но как правило это копипаста с ИТСа, копипаста с крупных порталов по 1С, устаревшая информация по настройке сервера для 8.2 и даже порой информация противоречила друг другу. Кроме того, я не обнаружил ни одной комплексной статьи по созданию безопасного, надёжного кластера сервера приложений 1С. Попробую компенсировать это своей статьёй.
Службы 1С будут запускаться под служебной учётной записью gMSA — Group Management Service Account. Ключевыми особенностями данного типа учётной записи является то, что мы не заморачиваемся с безопасностью пароля — Windows AD сам устанавливает рандомный пароль для учётки (240 знаков: 120 — символы, 120 — цифры), сам осуществляет регулярную смену пароля (по умолчанию 30 дней), сам обновляет пароль на серверах, пароль не хранится на серверах. Для данной учётки не создаётся профиль на сервере, где она используется. Учётка может использовать только на тех серверах, которые мы сами добавили в группу безопасности.
Для начала подготовим наш доменный лес к использованию данного типа учёток (если мы не сделали этого ранее).
Дальнейшие действия выполняются на контроллере домена.
Проверяем, что на контроллере домена включена служба Microsoft Key Distribution Service (Центр распространения ключей Kerberos — KDC).
Создадим корневой ключ. Выполняем в PowerShell от имени администратора:
Add-KdsRootKey –EffectiveImmediately
Консоль вернёт GUID созданного ключа. Можем посмотреть более подробную информацию по ключу:
Get-KdsRootKey
Созданный ключ будет доступен только через 10 часов. До этого времени попытки создать учётку gMSA будет заканчиваться ошибками «Key not found».
Это сделано для того, чтобы все контроллеры домена успели синхронизироваться и получить информацию о новом корневом ключе.

Спустя 10 часов мы узнали, что в тестовой среде можно было и не ждать 10 часов, а добавить к команде параметр, который установит время создания ключа 10 часами ранее текущего времени.
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Прежде чем создавать саму учётку, сделаем группу безопасности, в которую будут входить сервера приложений 1С.
Как уже писал выше, учётка будет доступна только для определенного списка серверов. При создании учётки можно жёстко определить перечень таких серверов, но более правильно будет создать группу безопасности, в которую мы включим эти сервера, а при необходимости сможем исключить их из неё, или добавить новые. Но есть особенность: чтобы сервер смог начать использовать эту учётку, после включения его в группу безопасности — его необходимо перезагрузить.
В оснастке управления пользователями и компьютерами домена создадим группу безопасности ServiceGroupServers1C и включим в неё наши сервера приложений 1С: SRV01, SRV02.
Переходим к созданию учётки. В консоли PowerShell:
New-ADServiceAccount -name gUSRV1CV8 -DNSHostName gUSRV1CV8.domain.ru -PrincipalsAllowedToRetrieveManagedPassword "ServiceGroupServers1C"
здесь -name – имя учётки;
-DNSHostName — FQDN имя (имя учётки+доменный суффикс);
-PrincipalsAllowedToRetrieveManagedPassword — имя группы безопасности, которую мы создали ранее.
Если хотим, то можно добавить ключ -ManagedPasswordIntervalInDays в котором указать период действия пароля до его автоматической смены (в днях). По умолчанию это значение 30 дней.
После успешного создания учётки в консоле пользователей и компьютеров домена в контейнере Managed Service Accounts появится наша созданная учётка.
Hint: по умолчанию этот контейнер не отображается, чтобы его увидеть, нужно в меню Вид оснастки включить опцию Дополнительные компоненты.
Отлично, учётка в домене есть, теперь нужно обрадовать наши сервера, что им теперь с этой учёткой жить. Переходим на первый сервер приложений 1С, открываем консоль PowerShell от имени администратора и подключаем среду Active Directory:
Add-WindowsFeature RSAT-AD-PowerShell
Затем устанавливаем созданную учётку на сервере:
Install-ADServiceAccount -Identity gUSR1CV8
Команда ничего не вернёт, поэтому проверим результат:
Test-ADServiceAccount gUSR1CV8
Вернула True — значит всё хорошо.
Дадим учётке права входа в качестве службы. Открываем оснастку Локальная политика безопасности (secpol.msc), переходим Локальные политики — Назначение прав пользователя — ВХод в качестве службы и добавляем пользователя domain\gUSR1CV8$. Да-да, именно со знаком доллара на конце.

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

На этапе указания учётной записи, от имени которой будет запускаться служба, указываем ранее созданную учётку domain\gUSR1CV8$.
Скорее всего служба не сможет стартануть (просто продолжите установку) и вот почему: сервер 1С пишет конфигурации и кэш в каталоги C:\Program Files\1cv8\srvinfo, а у нашей учётки нет туда прав.
Да и в целом такой путь к каталогу srvinfo (в котором, на секундочку, хранится список опубликованных информационных баз, кэш этих баз и журналы регистрации, которые могут стремительно расти) крайне сомнителен. Поэтому после установки переместим этот каталог в более удобное место: отдельный раздел, отдельный диск ну или хотя бы просто в корень диска C: (тоже сомнительное расположение, но в тестовой среде — пойдёт) и дадим нашей учётке права на изменение. После перемещения необходимо сообщить о новом пути службе сервера 1С: открываем редактор реестра regedit и переходим:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64)
и в параметре ImagePath корректируем значение ключа -d:
"C:\Program Files\1cv8\8.3.14.1779\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\srvinfo" -debug -http
Коли уж мы тут, сразу включили серверную отладку + отладку по HTTP: ключи -debug, -http
Когда всё это сделали — запускаем службу. Если служба запустилась — мы всё сделали правильно, мы молодцы. Повторяем всё это для второго сервера.
День добрый!
Подскажите, как себя чувствует служба агента сервера предприятия 1С будучи запущенной от имени gMSA? Никаких проблем не наблюдалось?
Добрый день! Исключая случая когда не выдали необходимых прав на файловые ресурсы — всё работает стабильно.
Вы столкнулись с какими-то проблемами при работе службы от имени gMSA?