Инфоплекс

Каждый из нас сталкивается с настройкой сервисных учетных записей. В большинстве случаев такая сервисная учетная запись нужна только для запуска одной или нескольких служб. Выполнять консольный вход в систему под этой учетной записью не планируется. Менять её пароль зачастую тоже не планируется. Однако, это справедливо не для всех случаев. В вашей компании может быть разработан регламент безопасности, в соответствии с которым пароли должны менять регулярно. И это может породить волну работ по смене пароля для сервисных учетных записей. Именно поэтому компания Microsoft начиная с Windows Server 2008 R2 внедрила управляемые учетные записи (Managed Service Account - MSA). Это позволило делегировать управление паролями непосредственно Active Directory. Так же для этих учетных записей не разрешен интерактивный вход, что является дополнительным преимуществом в плане безопасности. В тоже время у MSA был один существенный недостаток - учетная запись могла использоваться только на одной компьютере. В следующей версии Windows Server (Windows Server 2012) компания Microsoft устранила этот недостаток. Была добавлена поддержка групповых управляемых учетных записей (Group Managed Service Account - gMSA). Именно об этом типе учетных записей и пойдет речь в текущей публикации.

Что такое групповые управляемые учетные записи

Групповые управляемые учетные записи позволяют вам не беспокоиться о смене пароля для сервисных учетных записей. Active Directory сделает это автоматически за вас. Интерактивный вход через групповые учетные записи также невозможен.

Вы можете использовать gMSA для запуска служб или заданий планировщика. Например, можно запускать Windows службы от имени gMSA. От имени gMSA можно, к примеру, запускать службы сервера SQL.

Есть нюанс - групповые учетные записи не могут быть использованы для запуска служб кластера. Но в тоже время учетные записи gMSA могут быть использованы для служб, которые работают "поверх" отказоустойчивого кластера. Например, у вас настроена система мониторинга System Center Operation Manager, которая работает "поверх" отказоустойчивого кластера. Предположим, что у вас есть несколько серверов управления, которые используют одну и ту же сервисную учетную запись. При таких вводных данных сервера мониторинга являются прямыми кандидатами на использования gMSA. Например, для такого сценария есть даже опорная статья в документации.

При необходимости, вы также можете зарегистрировать SPN для gMSA. Но о регистрации SPN мы поговорим чуть ниже.

Еще одна особенность gMSA заключается в том, что учетные записи gMSA поддерживают только Kerberos аутентификацию.

Предварительные требования

Для того, чтобы вы могли использовать групповые управляемые учетные записи ваша инфраструктура соответствовать некоторым требованиям. Перечислю их:

1. Для запуска необходимых командлетов PowerShell необходима 64-разрядная операционная система.
2. Сервер, на котором будет использоваться gMSA, должен работать под управление операционной системы Windows Server 2012 или выше.
3. Функциональный уровень домена и леса Active Directory должен быть Windows Server 2012 или выше.
4. На сервер, на котором будет использоваться gMSA, необходимо установить модуль Windows PowerShell для Active Directory.

Клиентские компьютеры, с которых ваши пользовали будут осуществлять доступ к сервису, могут работать под управление операционной системы Windows XP или новее.

Настройка KDS - создание корневого ключа

Есть важный момент - созданный ключ начнет быть активным только спустя 10 часов. Это сделано для того, чтобы в распределенной среде корневой ключ успел отреплицироваться на все контроллеры домена, прежде чем его смогут использовать службы.

Если в вашей инфраструктуре всего один контроллер домена или вы тестируете gMSA на своем стенде, то можете использовать следующие комендлеты, чтобы ключ KDS был активным сразу же:

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

Создание групповой управляемой учетной записи

Предположим, что на сервере mail01.cgp.loc у нас есть некий сервер, который синхронизует пользователей Active Directory с другой почтовой системой. В своей работе сервис использует службу Windows. Это просто пример. В вашем случае вводные данные могут немного отличаться.

Процесс применения групповых управляемых учетных записей разделен на два этапа:

1. Вы создаете управляемую учетную запись в ActiveDirectory.
2. Вы запускаете службу или сервис от имени групповой управляемой учетной записи на нужном вам сервере.

Рассмотрим наглядно каждый из шагов этого процесса. Итого, что нам нужно сделать:

1. Создаем gMSA . Для этого на контроллере домена запускаем следующий командлет:

New-ADServiceAccount -Name cgpsvc1 -DNSHostName mail.cgp.loc -PrincipalsAllowedToRetrieveManagedPassword mail01$

Основные параметры командлета приведены в таблице ниже.

Параметр	Значение
Name	Имя учетной записи gMSA. Именно это имя учетной записи gMSA будет указано непосредственно на сервере при настройке службы Windows
DNSHostName	Имя DNS, по которому будет производится обращение к сервису.
PrincipalsAllowedToRetrieveManagedPassword	Перечисление учетных записей компьютеров, которым разрешено использование учетной записи gMSA. Если учетную запись gMSA будут использовать несколько компьютеров, то целесообразнее указать в этом параметру группу Active Directory, в которую вы включить все учетные записи компьютеров.

Проверить статус созданной учетной записи gMSA можно следующим командлетом:

Get-ADServiceAccount -Identity cgpsvc1

2. После того, как учетная запись была создана необходимо запустить службу Windows от имени gMSA. Однако, предварительно нам нужно выполнить несколько подготовительных работ.

Установим модуль Active Directory для PowerShell

Add-WindowsFeature RSAT-AD-PowerShell

Установим нашу учетную запись gMSA:

Install-ADServiceAccount -Identity cgpsvc1

После установки учетной записи gMSA мы можем выполнить её проверку следующим командлетом:

Test-ADServiceAccount -Identity cgpsvc1

При успешной установке учетной записи gMSA командлет должен вернуть значение "True".

3. Последним шагом мы выполним запуск нужного нам сервиса Windows от имени учетной записи gMSA. Запускаем оснастку управления сервисами и находим нужный нам сервис.

На вкладке "Log On" устанавливаем переключать в значение "This account" и указываем имя учетной записи gMSA в формате samaccountname, т.е. NetBIOS имя домена + \ + имя учетной записи gMSA + $. Обратите внимание на знак $ в завершении имени аккаунта. Поле с паролем оставляем пустым. Сохраняем внесенные изменения.

Нас уведомят о том, что учетной записи gSMA будет предоставлено разрешение входа в качестве сервиса.

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

Если служба по каким-то причинам не запускается, то нужно либо смотреть журнал событий, либо руководство от вендора по настройке запуска службы от gMSA. По сути, это все та же учетная запись и ей тоже необходимо назначать дополнительные разрешения (если таковые требуются).

Регистрация SPN для gMSA

Для корректной работы некоторых сервисов необходима регистрация Service Principal Name (SPN). Зачем нужен SPN? SPN необходим для тех сервисов, которые используют Kerberos аутентификацию, т.е. сервис аутентифицирует ваших пользователей "прозрачно". Им не нужно дополнительно указывать какой-то логин или пароль.

Групповые управляемые учетные записи можно использовать при регистрации SPN. 

Предположим, что у нас в сети есть SQL сервер - sql01.cg.loc. На нем развернул SQL сервер с экземпляром по умолчанию (MSSQLSERVER). Службы SQL запущены от gMSA cg\sqlsvc1. Вы хотели бы зарегистрировать для него SPN запись.

В таком случае пример команды для регистрации SPN выглядит следующим образом (для NetBIOS и FQDN имени соответственно):

setspn -s MSSQLSvc/sql01 CG\sqlsvc1$
setspn -s MSSQLSvc/sql01.cg.loc CG\sqlsvc1$ 

Обратите внимание на знак $ в конце имени учетной записи - он обязательно должен присутствовать.

Заключение