Управляемые учетные записи служб (MSA и gMSA) в Active Directory

Управляемые учетные записи служб (MSA и gMSA) в Active Directory

Управляемые учетные записи (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

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 часов, после окончания репликации между контролерами домена.

Совет. В тестовой среде для немедленного использования KDS ключа можно воспользоваться командой:

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

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

Get-KdsRootKey

Add-KdsRootKey создать корневой ключ KDS в active directory

Для проверки ключа используется команда:

Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

Test-KdsRootKey

Создаем управляемую учётную запись 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

Напоминаю, что вы можете использовать MSA аккаунт только на одном сервере.

Откройте консоль
dsa.msc
(ADUC, Active Directory Users and Computers) и проверьте, что в контейнере (OU) Managed Service Accounts появилась новая учетная запись типа msDS-ManagedServiceAccount.

контейнер Managed Service Accounts в active directory

по умолчанию этот контейнер не отображается. Чтобы его увидеть, нужно в консоли ADUC выбрать View -> Advanced Features.

Информацию об MSA аккаунте можно получить с помощью команды:

Get-ADServiceAccount msaMskSrv1Tasks

информация об аккаунте MSA - Get-ADServiceAccount

Создаем групповую учетную запись 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$

создать группу в active directory

Чтобы создать групповую учетную запись Group Managed Service Account (gMSA), используйте команду:

New-ADServiceAccount -name gmsaMskSQL1 -DNSHostName gmsaMskSQL1.winitpro.ru -PrincipalsAllowedToRetrieveManagedPassword MskSQL1 –verbose

New-ADServiceAccount создать Group Managed Service Account (gMSA) с помощью powershell

Учётная запись gMSA также по умолчанию создается в OU Managed Service Accounts.

объект msDS-GroupManagedServiceAccount в acttive directory

Настройка учетных записей MSA/gMSA на серверах

Для использования сервисных аккаунтов MSA/gMSA на целевых серверах или рабочих станциях сначала нужно установить модуль PowerShell для Active Directory:

Add-WindowsFeature RSAT-AD-PowerShell

Установите учетную запись MSA/gMSA на сервере:

Install-ADServiceAccount -Identity gmsaMskSQL1

Проверьте, сервисная учетная запись установлена корректно:

Test-ADServiceAccount gmsaMskSQL1

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

установка Install-ADServiceAccount на сервере

Если команда вернула False, скорее всего учетная запись MSA не установлена на сервере или у данного компьютера нет прав на нее:

this computer does not have permission to use the group MSA

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

Get-ADServiceAccount passwordlastset

Для проверки работы служб и скриптов от имени сервисной учетной записи MAS не получится использовать стандартный RunAs. Вместо этого воспользуйтесь утилитой PsExec (ранее мы показывали, как использовать psexec для запуска командной строки от имени System).

  1. Откройте командную строку с правами администратора;
  2. Выполните команду:
    PsExec64.exe -i -u winitprogmsaMskSQL1$ -p ~ cmd.exe

    Вместо пароля указа знак
    ~
    , это значит что пароль нужно получить из AD.

  3. В открывшемся окне cmd выполните команду
    whoami
    , чтобы убедиться, что консоль запущена от имени аккаунта gMSA. PsExec64 запуск командной строки от имени gmsa аккаунта в windows server
  4. Проверьте запуск скриптов, программ или служб от имени учетной записи Managed Service Account.

Теперь осталось настроить запуск из-под MSA/gMSA нужных вам служб Windows, заданий Task Scheduler, пулов IIS и т.д.

Запуск служб Windows от имени Managed Service Account

Теперь можно настроить запуск нужной службы Windows из-под сервисной записи MSA/gMSA.

  1. Откройте консоль
    services.msc
    ;
  2. Откройте свойства нужной службы и перейдите на вкладку Log on;
  3. Выберите опцию This account и укажите имя MSA аккаунта. В конце имени обязательно указывается символ $ (пароль указывать не нужно);
  4. Сервисной учетной записи MSA будут автоматически предоставлены права Log On As a Service; запуск службы windows от имени gMSA учетной записи
  5. После сохранения изменений службу нужно перезапустить.

Для запуска сложных сервисов с помощью gMSA, проверьте в документации, что это поддерживается. На данный момент gMSA поддерживаются в SQL Server, IIS, AD LDS, Exchange Server.

Запуск задания планировщика от имени сервисной учетной записи /gMSA

Вы можете настроить запуск заданий планировщика Windows Task Scheduler от имени сервисной учетной записи gMSA. Это удобно, так как пароли учетной записи gMSA не хранятся в скриптах в явном виде, вам не нужно их шифровать или защищать. При изменении пароля не нужно перенастраивать задание.

Для предоставления прав учетной записи MSA/gMSA достаточно включить ее в нужные группы доступа. Например, в локальные администраторы сервера, Domain Admins, DNS admins и т.д.

Настроить задание для запуска от имени MSA/gMSA можно только с помощью PowerShell. Например, следующий скрипт создаст новое задание планировщика, которое ежедневно в 21:00 запускает PowerShell скрипт для резервного копирования базы данных:

$action = New-ScheduledTaskAction -Execute powershell.exe  -Argument "-file C:PSDBBackupDB.ps1 -executionpolicy bypass -NoProfile"
$trigger = New-ScheduledTaskTrigger -At 21:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID winitprogmsaMskSQL1$ -LogonType Password
Register-ScheduledTask BackupDB –Action $action –Trigger $trigger –Principal $principal

powershell создать задание планировщика для запуска от аккаунта Group Managed Service Accounts (gMSA)

Примечание. Для запуска заданий планировщика нужно предоставить учетной записи gMSA права “Log on as a batch job”.

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

Также вы можете создать задание планировщика с нужными настройками из графической консоли. Затем с помощью утилиты schtasks.exe можно настроить, чтобы оно запускалось от имени Managed Service Account:

schtasks /Change /TN BackupDB /RU "winitprogmsaMskSQL1$" /RP ""

В комментариях к статье есть PowerShell скрипт от Tony, который позволяет перенастроить любое имеющееся задание на запуск от имени gMSA аккаунта.

PowerShell
Управляемые учетные записи служб (MSA и gMSA) в Active Directory