Управляемые учетные записи (Managed Service Accounts – MSA) это специальный тип учетных записей Active Directory, которые можно использовать для безопасного запуска служб, приложений и заданий планировщика. Основная их идея в том, что паролем таких учетных записей полностью управляет Active Directory. Для них автоматически генерируется сложный пароль длиной 240 символов, который меняется автоматически (по умолчанию каждые 30 дней). Для аутентификации используется только Kerberos (нет проблем с безопасностью NTLM), интерактивный вход не возможен, пароль не известен никому и не хранится в локальной системе (нельзя извлечь пароль из системного процесса LSASS с помощью mimikatz или аналогичных утилит). Таким образом для запуска службы или автоматических заданий, вам не нужно создавать отдельных сервисных пользователей в AD и управлять их паролями.
Managed Service Accounts появились в Windows Server 2008 R2 (тип объекта msDS-ManagedServiceAccount). Основное их ограничение – такую учетную запись можно использовать только на одном сервере (т.е. их нельзя использовать с кластерными и NLB службами). Поэтому в Windows Server появились групповые учетные записи служб, gMSA — Group Managed Service Accounts (тип msDS-GroupManagedServiceAccount). gMSA аккаунты могут одновременно использоваться на нескольких серверах.
Рассмотрим особенности использования MSA и gMSA для запуска служб и заданий на серверах в Active Directory.
- Требования для использования сервисных аккаунтов MSA/gMSA
- Создаем корневой ключа KDS службы распространения ключей
- Создаем управляемую учётную запись MSA в Active Directory
- Создаем групповую учетную запись gMSA
- Настройка учетных записей MSA/gMSA на серверах
- Запуск служб Windows от имени Managed Service Account
- Запуск задания планировщика от имени сервисной учетной записи /gMSA
Требования для использования сервисных аккаунтов MSA/gMSA
| Managed Service Account | Group Managed Service Accoun | |
| Уровень домена и леса AD | Не ниже Windows Server 2008 R2 | Не ниже Windows Server 2012 |
| KDC | Контроллер домена с включенной службой распространения ключей Microsoft Key Distribution Service (KdsSvc) | |
| PowerShell | Для создания и управления сервисными аккаунтами нужно установить модуль Active Directory module for Windows PowerShell | |
| .Net Framework | На сервере нужно установить .NET Framework 3.5 или выше | |
| Поддерживаемые клиенты | Windows 7/Windows Server 2008 R2 и выше | Windows Server 2012/Windows 8 и выше |
Создаем корневой ключа KDS службы распространения ключей
Прежде, чем приступить к созданию учетной записи MSA/gMSA, нужно выполнить разовую операцию по созданию корневого ключа KDS (KDS root key). Для этого на контроллере домена с правами администратора выполните команду (служба Microsoft Key Distribution Services должна быть установлена и включена):
Add-KdsRootKey –EffectiveImmediately
В этом случае ключ будет создан и доступен для использования через 10 часов, после окончания репликации между контролерами домена.
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Проверим, что корневой ключ KDS создался успешно:
Get-KdsRootKey
Для проверки ключа используется команда:
Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId
Создаем управляемую учётную запись MSA в Active Directory
Чтобы создать новую управляемую учетную запись MSA в AD воспользуйтесь командой:
New-ADServiceAccount -Name msaMskSrv1Tasks –RestrictToSingleComputer
По умолчанию MSA и gMSA создаются в корневом контейнере CN=Managed Service Accounts, но вы можете изменить OU с помощью параметра Path.
Привяжите сервисную учетную запись MSA к нужному компьютеру:
$Identity = Get-ADComputer -identity msk-srv01
Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaMskSrv1Tasks
Откройте консоль
dsa.msc
(ADUC, Active Directory Users and Computers) и проверьте, что в контейнере (OU) Managed Service Accounts появилась новая учетная запись типа msDS-ManagedServiceAccount.
Информацию об MSA аккаунте можно получить с помощью команды:
Get-ADServiceAccount msaMskSrv1Tasks
Создаем групповую учетную запись gMSA
Прежде чем создавать учетную запись gMSA, создайте доменную группу и поместите в нее сервера, которым будет разрешено использовать пароль этой групповой сервисной учетной записи. Проще всего создать и наполнить группу с помощью PowerShell:
New-ADGroup MskSQL1 -path 'OU=Groups,OU=MSK,OU=RU,dc=winitpro,DC=ru' -GroupScope Global -PassThru –Verbose
Add-AdGroupMember -Identity MskSQL1 -Members msk-sql01$, msk-sql02$, msk-sql03$
Чтобы создать групповую учетную запись Group Managed Service Account (gMSA), используйте команду:
New-ADServiceAccount -name gmsaMskSQL1 -DNSHostName gmsaMskSQL1.winitpro.ru -PrincipalsAllowedToRetrieveManagedPassword MskSQL1 –verbose
Учётная запись gMSA также по умолчанию создается в OU Managed Service Accounts.
Настройка учетных записей MSA/gMSA на серверах
Для использования сервисных аккаунтов MSA/gMSA на целевых серверах или рабочих станциях сначала нужно установить модуль PowerShell для Active Directory:
Add-WindowsFeature RSAT-AD-PowerShell
Установите учетную запись MSA/gMSA на сервере:
Install-ADServiceAccount -Identity gmsaMskSQL1
Проверьте, сервисная учетная запись установлена корректно:
Test-ADServiceAccount gmsaMskSQL1
Если команда вернет True – все настроено правильно.
WARNING: Test failed for Managed Service Account gmsaMskSQL1. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA.
Можно изменить периодичность смены пароля (по умолчанию 30 дней):
Set-ADServiceAccount gmsaMskSQL1 -ManagedPasswordIntervalInDays 60
Получить время последней смены пароля можно так:
Get-ADServiceAccount -Identity gmsaMskSQL1 -Properties passwordlastset
Для проверки работы служб и скриптов от имени сервисной учетной записи MAS не получится использовать стандартный RunAs. Вместо этого воспользуйтесь утилитой PsExec (ранее мы показывали, как использовать psexec для запуска командной строки от имени System).
- Откройте командную строку с правами администратора;
- Выполните команду:
PsExec64.exe -i -u winitpro\gmsaMskSQL1$ -p ~ cmd.exeВместо пароля указа знак~, это значит что пароль нужно получить из AD. - В открывшемся окне cmd выполните команду
whoami, чтобы убедиться, что консоль запущена от имени аккаунта gMSA.
- Проверьте запуск скриптов, программ или служб от имени учетной записи Managed Service Account.
Теперь осталось настроить запуск из-под MSA/gMSA нужных вам служб Windows, заданий Task Scheduler, пулов IIS и т.д.
Запуск служб Windows от имени Managed Service Account
Теперь можно настроить запуск нужной службы Windows из-под сервисной записи MSA/gMSA.
- Откройте консоль
services.msc; - Откройте свойства нужной службы и перейдите на вкладку Log on;
- Выберите опцию This account и укажите имя MSA аккаунта. В конце имени обязательно указывается символ $ (пароль указывать не нужно);
- Сервисной учетной записи MSA будут автоматически предоставлены права Log On As a Service;
- После сохранения изменений службу нужно перезапустить.
Запуск задания планировщика от имени сервисной учетной записи /gMSA
Вы можете настроить запуск заданий планировщика Windows Task Scheduler от имени сервисной учетной записи gMSA. Это удобно, так как пароли учетной записи gMSA не хранятся в скриптах в явном виде, вам не нужно их шифровать или защищать. При изменении пароля не нужно перенастраивать задание.
Настроить задание для запуска от имени MSA/gMSA можно только с помощью PowerShell. Например, следующий скрипт создаст новое задание планировщика, которое ежедневно в 21:00 запускает PowerShell скрипт для резервного копирования базы данных:
$action = New-ScheduledTaskAction -Execute powershell.exe -Argument "-file C:\PS\DB\BackupDB.ps1 -executionpolicy bypass -NoProfile"
$trigger = New-ScheduledTaskTrigger -At 21:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID winitpro\gmsaMskSQL1$ -LogonType Password
Register-ScheduledTask BackupDB –Action $action –Trigger $trigger –Principal $principal
Аргумент “
-LogonType Password
” означает, что пароль для этой gMSA учетной записи будет получен с контроллера домена.
Также вы можете создать задание планировщика с нужными настройками из графической консоли. Затем с помощью утилиты schtasks.exe можно настроить, чтобы оно запускалось от имени Managed Service Account:
schtasks /Change /TN BackupDB /RU "winitpro\gmsaMskSQL1$" /RP ""
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На запрос пароля отсавляете его пустым.
itpro! Пожалуйста добавьте в абзац ««Тонкая» настройка gMSA» мой PS-скрипт для удобного пересоздания текущих существующих задач в планировщике на учётную запись gMSA. Долго искал такой скрипт и не нашел вообще. Очень удобно использовать, т.к. не надо мучится с powershell, а работать через привычный GUI.
#ЕгоркинА.Н. 10:27 28.04.2021
#Gtht*****************
$domain=»corp»
$ObjectClass=»msDS-GroupManagedServiceAccount»
#***************************
clear
Write-host «*********************************************************************»
Write-host «Скрипт перевода задач на служебную учётную запись»
Write-host «Скрипт запускаем на конкретном сервере с правами администратора и, желательно, с доступом к AD для поиска gMSA»
Write-host «Выбираем задачу и затем новую учётную запись gMSA — создастся новая задача и старая перейдёт в disable»
Write-host
Write-host «*********************************************************************»
pause
clear
#Показываем все доступные задачи
Write-host «————————————————————————————————»
Write-host Список всех задач из корня \
Write-host
Get-ScheduledTask -TaskPath «\» -TaskName «*»
[string]$schedule_name = $(read-host «Введите (часть или полное) название задачи, в которой хотите поменять пользователя»)
#Выбираем задачу
$schedule_name_search = $schedule_name+»*»
$tasks_name_sel = Get-ScheduledTask -TaskPath «\» -TaskName $schedule_name_search
Write-host
Write-host Выбрана задача $tasks_name_sel.TaskName
Write-host
#Выбираем gMSA учётную запись
Write-host «————————————————————————————————»
Write-host Список всех gMSA учётных записей в домене Corp
Get-ADObject -LDAPFilter «(&(ObjectClass=$ObjectClass)(name=*))» -Server ‘Corp’ | select Name, ObjectGUId | format-table
[string]$gmsa_name = $(read-host «Введите название сервисной учётной записи (двойной клик на имя левой и двойной клик правой кнопкой)»)
#Проверка что gMSA примаплена к текущему серверу
$gmsa_name_search=$domain+»\»+$gmsa_name+»$»
$gmt = Test-ADServiceAccount -Identity $gmsa_name
if ($gmt -eq $True) {
Write-host
Write-host «Успешно — учетная запись $gmsa_name найдена и привязана к этому компьютеру»
Write-host «————————————————————————————————»
}
else {
Write-host
Write-host «Иными словами, учетная запись $gmsa_name не привязана к этому компьютеру:»
Write-host «или вы ошиблись в выборе учётной записи, или кто-то забыл про команду»
Write-host «Install-ADServiceAccount -Identity $gmsa_name»
Write-host
Write-host «при этом, учетная запись gMSA создается следующей командой от имени доменного администратора:»
Write-host «New-ADServiceAccount -Name имя_gMSA_учётной_записи -DNSHostName hq-dc01 -PrincipalsAllowedToRetrieveManagedPassword имя_целевого_сервера$»
Write-host «————————————————————————————————»
pause
exit
}
pause
Write-host «————————————————————————————————»
#Экспортируем выбранную задачу в формате xml в переменную schedule
$schedule = Export-ScheduledTask -TaskName $schedule_name
#Заменяем старую учётную запись на новую gMSA
$schedule_user_bad = $schedule | findstr «UserId»
$schedule_user_bad = $schedule_user_bad.Replace(» «,»»)
$schedule_user_good = »+$gmsa_name_search+»
$schedule_good = $schedule.Replace($schedule_user_bad,$schedule_user_good)
#Заменяем тип запуска задачи на корректный
$schedule_user_bad = $schedule | findstr «LogonType»
$schedule_user_bad = $schedule_user_bad.Replace(» «,»»)
$schedule_user_good = ‘Password’
$schedule_good = $schedule_good.Replace($schedule_user_bad,$schedule_user_good)
#Удаляем тип запуска «с наивысшими привилегиями»
$schedule_Run_level = ‘ HighestAvailable’
$schedule_good = $schedule_good.Replace($schedule_Run_level,»»)
#Переводим старую задачу в Disable
Disable-ScheduledTask -TaskName $schedule_name
#Регистрируем новую задачу с припиской gMSA в названии
Register-ScheduledTask -Xml ($schedule_good) -TaskName $schedule_name»_gMSA»
Write-host «Работа скрипта завершена успешно. Но, это не означает корректность работы самой задачи в части наличия прав на отработку полезной нагрузки»
Write-host
#ЕгоркинА.Н. 10:27 28.04.2021
#peremennye*****************
$domain="corp"
$ObjectClass="msDS-GroupManagedServiceAccount"
#***************************
clear
Write-host "*********************************************************************"
Write-host "Скрипт перевода задач на служебную учётню запись"
Write-host "Скрипт запускаем на конкретном сервере с правами администратора и, желательно, с доступом к AD для поиска gMSA"
Write-host "Выбираем задачу и затем новую учётную запись gMSA - создастся новая задача и старая перейдёт в disable"
Write-host
Write-host "*********************************************************************"
pause
clear
#Показываем все доступные задачи
Write-host "------------------------------------------------------------------------------------------------"
Write-host Список всех задач из корня \
Write-host
Get-ScheduledTask -TaskPath "\" -TaskName "*"
[string]$schedule_name = $(read-host "Введите (часть или полное) название задачи, в которой хотите поменять пользователя")
#Выбираем задачу
$schedule_name_search = $schedule_name+"*"
$tasks_name_sel = Get-ScheduledTask -TaskPath "\" -TaskName $schedule_name_search
Write-host
Write-host Выбрана задача $tasks_name_sel.TaskName
Write-host
#Выбираем gMSA учётную запись
Write-host "------------------------------------------------------------------------------------------------"
Write-host Список всех gMSA учётных записей в домене Corp
Get-ADObject -LDAPFilter "(&(ObjectClass=$ObjectClass)(name=*))" -Server 'Corp' | select Name, ObjectGUId | format-table
[string]$gmsa_name = $(read-host "Введите название сервисной учётной записи (двойной клик на имя левой и двойной клик правой кнопкой)")
#Проверка что gMSA примаплена к текущему серверу
$gmsa_name_search=$domain+"\"+$gmsa_name+"$"
$gmt = Test-ADServiceAccount -Identity $gmsa_name
if ($gmt -eq $True) {
Write-host
Write-host "Успешно - учетная запись $gmsa_name найдена и привязана к этому компьютеру"
Write-host "------------------------------------------------------------------------------------------------"
}
else {
Write-host
Write-host "Иными словами, учетная запись $gmsa_name не привязана к этому компьютеру:"
Write-host "или вы ошиблись в выборе учётной записи, или кто-то забыл про команду"
Write-host "Install-ADServiceAccount -Identity $gmsa_name"
Write-host
Write-host "при этом, учетная запись gMSA создается следующей командой от имени доменного администратора:"
Write-host "New-ADServiceAccount -Name имя_gMSA_учётной_записи -DNSHostName hq-dc01 -PrincipalsAllowedToRetrieveManagedPassword имя_целевого_сервера$"
Write-host "------------------------------------------------------------------------------------------------"
pause
exit
}
pause
Write-host "------------------------------------------------------------------------------------------------"
#Экспортируем выбранную задачу в формате xml в переменную schedule
$schedule = Export-ScheduledTask -TaskName $schedule_name
#Заменяем старую учётную запись на новую gMSA
$schedule_user_bad = $schedule | findstr "UserId"
$schedule_user_bad = $schedule_user_bad.Replace(" ","")
$schedule_user_good = ''+$gmsa_name_search+''
$schedule_good = $schedule.Replace($schedule_user_bad,$schedule_user_good)
#Заменяем тип запуска задачи на корректный
$schedule_user_bad = $schedule | findstr "LogonType"
$schedule_user_bad = $schedule_user_bad.Replace(" ","")
$schedule_user_good = 'Password'
$schedule_good = $schedule_good.Replace($schedule_user_bad,$schedule_user_good)
#Удаляем тип запуска "с наивысшими привилегиями"
$schedule_Run_level = ' HighestAvailable'
$schedule_good = $schedule_good.Replace($schedule_Run_level,"")
#Переводим старую задачу в Disable
Disable-ScheduledTask -TaskName $schedule_name
#Регистрируем новую задачу с припиской gMSA в названии
Register-ScheduledTask -Xml ($schedule_good) -TaskName $schedule_name"_gMSA"
Write-host "Работа скрипта завершена успешно. Но, это не означает корректность работы самой задачи в части наличия прав на отработку полезной нагрузки"
Write-host
Спасибо за инфу, идея хорошая!
Обязательно попробую твой скрипт в деле и отпишусь о результатах.
Обновил статью, добавил упоминание про ваш скрипт. Действительно, удобно.
Спасибо!
Есть ли срок действия у корневого ключа KDS, и если да — то как его обновить без угрозы простоя сервисов?
-DNSHostName dc1.winitpro.ru , где dc1.winitpro.ru – имя DNS сервера
из документации
-DNSHostName
Specifies the DNS host name of Service Account.
Не освещена проблема «двойного прыжка» (double-hop) при установке учётной записи на сервер через «PSRemouting», ходить для этого на сервер через RDP как минимум странно да и просто не удобно если сервер не один.