Group Managed Service Accounts в Windows Server 2012

Технология управляемых служебных записей (Managed Service Accounts – MSA) впервые была представлена в Windows Server 2008 R2 и предназначена для автоматического управления (смены) паролей служебных (сервисных) учетных записей. Благодаря использованию механизма Managed Service Accounts можно существенно снизить риск компрометации системных учетных записей, из-под которых запущены системные службы(не секрет, что существует большое количество утилит, позволяющих извлечь пароли локальных пользователей из LSASS).

Для учетных записей MSA генерируется пароль длиной 240 символов, из которых половина – английские буквы, другая половина – служебные символы. Пароль такой учетной записи меняется автоматически (по-умолчанию каждые 30 дней) и не хранится на локальной системе

Основным недостатком MSA является возможность использования подобной служебной записи только на одном компьютере. Это означает, что служебные учетные записи MSA не могут работать с кластерными и NLB службами (веб-фермы), которые работают одновременно на нескольких серверах и используют одну учетную запись и пароль.

Для преодоления указанного недостатка Microsoft в Windows Server 2012 добавила функционал групповых управляемых учетных записей служб (gMSA  — Group Managed Service Accounts). Такие учетные записи можно одновременно использовать на нескольких серверах, чтобы все экземпляры службы использовали одну и ту же учетную запись, например в службе балансировки нагрузки (NLB), кластерных службах и т.п.

Требования gMSA :

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

• Уровень схемы AD — Windows Server 2012 (как ее обновить описано здесь).
• Контроллер домена Windows Server 2012 (и выше) со службой Microsoft Key Distribution Service (служба распространения ключей) – именно это служба отвечает за генерацию паролей
• PowerShell модуль для управления Active Directory
• В качестве клиентов могут использоваться Windows Server 2012/2012 R2 и Windows 8/8.1
• Служба, использующая gMSA должна быть совместима с этим типом аккаунтов (должно быть указано в документации). На данный момент gMSA поддерживают: SQL Server 2008 R2 SP1, 2012;IIS; AD LDS; Exchange 2010/2013

Создаем KDS ключ

Прежде, чем приступить к созданию учетной записи gMSA, необходимо выполнить разовую операцию по созданию корневого ключа KDS (KDS root key). Для этого на контроллере домена с правами администратора выполните команду (служба Microsoft Key Distribution Services должна быть установлена и включена):

Add-KdsRootKey –EffectiveImmediately

В этом случае ключ будет создан и доступен через 10 часов, после окончания репликации.

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

Проверим, что корневой ключ KDS создался успешно:

Get-KdsRootKey

Создаем учетную запись gMSA

Создадим новую учетную запись gMSA командой:

New-ADServiceAccount -name gmsa1 -DNSHostName dc1.winitpro.ru -PrincipalsAllowedToRetrieveManagedPassword "gmsa1Group"

Где, gmsa1 – имя создаваемой учетной записи gMSA

dc1.winitpro.ru – имя DNS сервера

gmsa1Group – группа Active Directory, в которую включены все системы, которые будут использовать эту групповую учетную запись (группа должна быть создана предварительно)

После выполнения команды нужно открыть консоль ADUC (Active Directory Users and Computers) и проверить, что в контейнере (OU) Managed Service Accounts появилась советующая учетная запись (по умолчанию этот контейнер не отображается, чтобы его увидеть, нужно в меню View оснастки включить опцию Advanced Features)

Установка gMSA на сервере

Подключим модуль Powershell для поддержки среды Active Directory:

Add-WindowsFeature RSAT-AD-PowerShell

Далее нам нужно установить управляемую учетную запись на сервера, на которых она будет использоваться (из-под этой учетки в дальнейшем будет запущен некий сервис). В первую очередь нужно проверить, что этому серверу разрешено получать пароль учетной записи gMSA из Active Directory. Для этого его учетная запись должна состоять в указанной при создании доменной группе  (в нашем случае gmsa1Group). Установим запись gmsa1 на данном сервере:

Install-ADServiceAccount -Identity gmsa1

Проверить, что учетная групповая сервисная запись установлена корректно можно так (для Windows PowerShell 4.0):

Test-ADServiceAccount gmsa1

Если команда вернет True – все настроено правильно.

Далее в свойствах службы укажем, что она будет запускаться их под учетной записи gMSA. Для этого на вкладке Log on нужно выбрать This account и указать имя сервисной учетной записи. В конце имени обязательно указывается символ $, пароль указывать не нужно. После сохранения изменений службу нужно перезапустить.

Сервисной учетной записи автоматически будут предоставлены права «Log On As a Service».

«Тонкая» настройка gMSA

Периодичность смены пароля можно изменить (по умолчанию 30 дней):

Set-ADServiceAccount gmsa1-ManagedPasswordIntervalInDays 60

Учетную запись gMSA можно использовать и в задачах планировщика.  Тонкий нюанс в том, что задание можно настроить только через PowerShell.

$action = New-ScheduledTaskAction  “c:\script\backup.cmd”
$trigger = New-ScheduledTaskTrigger -At 21:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID winitpro\gmsa1$ -LogonType PasswordRegister-ScheduledTask BackupDB –Action $action –Trigger $trigger –Principal $principal

Аргумент «-LogonType Password» означает, что пароль для этой gMSA учетной записи будет получен с контроллера домена.