Технология управляемых служебных записей (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 учетной записи будет получен с контроллера домена.
gmsa1Group – это обычная глобальная группа безопасности, в которую включены необходимые сервера, на которые потом будет проинсталирована gmsa1
Собственно это был вопрос, а не констатация факта.
Может быть кто-нибудь пояснит, как связать группу ПК с уч. записью gMSA ?
В нашем примере связь идет через группу gmsa1Group. Т.е. эта группа в AD, в которую включены ПК которые нужно будет связать с групповой учеткой.
Все я разобрался после того как сервера будут добавлены в группу, которая в свою очередь будет «привязана» к gMSA, их необходимо перегрузить для того что бы отобразить их членство в группе.
Т.к. без этого происталировать gMSA на этом сервере не удастся из-за отказа в доступе.
Таким образом не нужно привязывать к gMSA необходимые сервера, а можно привязать группу из серверов, но с одним но:
2. Create and configure the gMSA
http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx
У меня после запуска службы от имени MSA аккаунта, вкладка Log On (Вход в систему) стала не активной.
Как это можно исправить?
У меня было то же самое на Windows Server 2012 R2, на 2012 — вкладка остается активной. Видимо какая-то недокументированная фича/бага.
Чтобы переключить запуск сервиса на SYSTEM или другой аккаунт придется воспользоваться sc.exe
Подскажите как создать задание в планировщике заданий, на еженедельную перезагрузку ПК от имени MSA?
Я так понял это можно сделать только через PS?
Напрямую из планировщика задание, которо запускается от имени gMSA аккаунта создать нельзя. Но есть небольшой трюк — создаете и настраиваете новое задание через графический интерфейс Task Scheduler от имени просто пользователя, а потом меняете акканунт на gMSA командой
schtasks /change /TN \TaskName /RU DOMAIN\gMSA_account$ /RP
На запрос пароля отсавляете его пустым.
Есть ли срок действия у корневого ключа KDS, и если да — то как его обновить без угрозы простоя сервисов?