Сервисная учетная запись windows

Для безопасного запуска служб, приложений и заданий планировщика на серверах и рабочих станциях домена Active Directory можно использовать управляемые учетные записи служб (Managed Service Accounts – MSA). MSA – это специальный тип учетной записи, для которых AD генерирует сложный пароль (240 символов) и автоматически меняет его каждые 30 дней. Интерактивный вход под MSA не возможен, пароль не известен никому и не хранится в локальной системе (нельзя извлечь пароль из системного процесса LSASS с помощью mimikatz или аналогичных утилит). Таким образом для запуска служб или заданий, вам не нужно создавать отдельных сервисных пользователей в AD и управлять их паролями

В этой статье, мы покажем, как создать сервисные учетные записи MSA и использовать их для запуска служб и сервисов на серверах.

Существует два типа сервисных учетных записей в AD:

• Managed Service Accounts (MSA) – появились в Windows Server 2008 R2 (тип объекта
  msDS-ManagedServiceAccount
  ). Основное ограничение – такую учетную запись можно использовать только на одном сервере (т.е. их нельзя использовать с кластерными службами).
• Group Managed Service Accounts (gMSA) – появились в Windows Server 2012 (тип объекта
  msDS-GroupManagedServiceAccount
  ). gMSA аккаунты можно одновременно использовать на нескольких серверах.

Создать корневой ключ Key Distribution Services

Перед началом использования сервисных учетных записей AD нужно выполнить разовую операцию по созданию корневого ключа KDS (KDS root key) на контроллере домена с включенной службой KdsSvc. Этот ключ будет использовать для генерации паролей gMSA.

Add-KdsRootKey –EffectiveImmediately

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

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

Get-KdsRootKey

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

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

Картинка с сайта: winitpro.ru

Создать управляемую учётную запись MSA в Active Directory

Чтобы создать новую управляемую учетную запись MSA в AD воспользуйтесь командой:

New-ADServiceAccount -Name msaMskSrv1Tasks –RestrictToSingleComputer

Привяжите сервисную учетную запись MSA к определенному серверу (для привязки используется атрибут msDS-HostServiceAccount в свойствах учетной записи компьютера):

$Identity = Get-ADComputer -identity msk-srv01
Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaMskSrv1Tasks

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

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

Картинка с сайта: winitpro.ru

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

Создать групповую сервисную учетную запись gMSA для нескольких серверов

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

Картинка с сайта: winitpro.ru

Создать групповую учетную запись Group Managed Service Account (gMSA) и привязать ее к группе MskSQL1:

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

Картинка с сайта: winitpro.ru

Учётная запись gMSA также по умолчанию создается в OU Managed Service Accounts. Привязка учетной записи к серверу или группе выполняется через атрибут msDS-GroupMSAMembership в свойствах учетной записи gMSA.

Картинка с сайта: winitpro.ru

Для корректной работы Kerberos аутентификации в некоторых сервисах нужна регистрация Service Principal Name (SPN). Сервисные учетные записи gMSA можно использовать при регистрации SPN:

setspn -s MSSQLSvc/sql01 winitpro\gmsaMskSQL1$
setspn -s MSSQLSvc/sql01.winitpro.loc winitpro\gmsaMskSQL1$

Установка учетных записей MSA и gMSA на хостах Windows

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

Add-WindowsFeature RSAT-AD-PowerShell

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

Install-ADServiceAccount -Identity gmsaMskSQL1

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

Test-ADServiceAccount gmsaMskSQL1

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

Картинка с сайта: winitpro.ru

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

Картинка с сайта: winitpro.ru

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

Картинка с сайта: winitpro.ru

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

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

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

3. В открывшемся окне cmd выполните команду
   whoami
   , чтобы убедиться, что консоль запущена от имени аккаунта gMSA.
   

   Картинка с сайта: winitpro.ru

4. Проверьте запуск скриптов, программ или служб от имени учетной записи Managed Service Account.

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

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

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

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

   Картинка с сайта: winitpro.ru

5. После сохранения изменений службу нужно перезапустить.

Для запуска пула IIS от имени gMSA, откройте расширенные настройки ApplicationPool (Advanced Settings) и в поле Identity измените ApplicationPoolIdentity на Custom Account ->
winitpro\gmsaMskSQL01$
(пароль оставьте пустым):

Или вы можете указать учетную запись MSA для пула с помощью PowerShell:

Import-Module WebAdministration
$pool = Get-Item IIS:\AppPools\wpad
$pool.processModel.identityType = 3
$pool.processModel.userName = "winitpro\gmsaMskSQL01$"
$pool.processModel.password = ''
$pool | Set-Item

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

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

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

Настроить задание для запуска от имени 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 -RunLevel Highest
Register-ScheduledTask BackupDB –Action $action –Trigger $trigger –Principal $principal

Картинка с сайта: winitpro.ru

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

schtasks /Change /TN BackupDB /RU "winitpro\gmsaMskSQL1$" /RP ""

Предоставьте учетной записи MSA/gMSA необходимые права доступа к сервису и NTFS разрешения на файловой системе. Например, я добавил учетную запись gMSA в локальную группу Backup Operators на сервере:

Add-LocalGroupMember -Group "Backup Operators" -Member winitpro\gmsaMskSQL1$

Картинка с сайта: winitpro.ru

Для запуска заданий планировщика нужно предоставить учетной записи gMSA права Log on as a batch job. На отдельном компьютере это можно сделать через редактор локальной GPO:
gpedit.msc
-> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment. Добавьте в политику учетную запись:
winitrpo\gmsaMskSQL1$

Картинка с сайта: winitpro.ru

Время на прочтение5 мин

Количество просмотров70K

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

HKEY_LOCAL_MACHINE/Security/Policy/Secrets

Существуют способы, которые позволяют извлечь пароли из LSA Secrets:

• Скопировать путь реестра во временный путь, а затем расшифровать зашифрованные пароли
• Использовать теневые копии
• Использовать специальные утилиты для работы с процессом lsass.exe

Попробуем получить пароль от учетной записи под которой запускается служба SQL Server.
Имеется:
Контроллер домена на Windows Server 2012 R2
SQL Server Express 2012
При установке SQL Server, для запуска службы, специально укажем существующую доменную учётную запись (пароль меньше 14 символов).

Картинка с сайта: habr.com

Воспользуемся утилитой gsecdump для извлечения паролей.
Запустим PowerShell от имени администратора и выполним команду: gsecdump-v2b5.exe -l
Результат:

Картинка с сайта: habr.com

Чтобы защититься от такого рода атак в Windows Server 2008 R2 был придуман механизм Managed Service Accounts.
Managed Service Accounts являются управляемыми учетными записями в домене, которые обеспечивают автоматическое управление паролями и упрощенное управление именами служб-участников, включая делегирование управления другим администраторам.
Преимущества управляемых учетных записей служб:

• Автоматическая смена паролей. По умолчанию смена пароля – раз в 30 дней
• Сложный пароль. Используется комплексный автоматически генерируемый пароль из 240 символов в случайном порядке (первая половина — буквы английского алфавита, вторая половина — цифры и другие символы)
• Отсутствие избыточных прав
• Возможность использования одного MSA на нескольких серверах (gMSA). В случае, когда требуется, чтобы все экземпляры служб использовали один и тот же субъект, например для использования в службе NLB
• Управление SPN

Автоматическое обновление SPN при переименовании
— учетной записи сервера
— свойства dnshostname учетной записи сервера
— изменении свойства addition¬aldnshostname учетной записи сервера
— изменении свойства additionalsam¬accountname учетной записи сервера

Сервисы и службы, которые поддерживают MSA:

• IIS
• AD LDS
• SQL Server 2008 R2 SP1, 2012
• MS Exchange 2010, 2013

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

• Уровень домена и леса – Windows Server 2008 R2
• Windows Server 2008 R2, Windows 7 (Professional, Enterprise, Ultimate)
• .Net Framework 3.5x
• Модуль администрирования Active Directory для PowerShell
• Установленный патч 2494158

Если лес и домен не имеют уровень 2008 R2 (MSA) и 2012 (gMSA) нужно поднять уровень леса командой:
adprep /forestprep
И уровень домена, командой:
adprep /domainprep в каждом домене, в котором необходимо создать и использовать управляемые учетные записи службы.

Включение MSA в PowerShell
1) Выполнить командлет: Import-Module ActiveDirectory
2) Чтобы создать учётную запись MSA нужно выполнить командлет:
New-ADServiceAccount serviceaccount –RestrictToSingleComputer
где serviceaccount – имя учетной записи MSA
RestrictToSingleComputer – параметр означает, что MSA будет привязан только к одному серверу.
Можно зайти в Active Directory Users and Computers и убедиться, что MSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

Картинка с сайта: habr.com

3) Чтобы привязать MSA к серверу нужно выполнить командлет:
Add-ADComputerServiceAccount -Identity server -ServiceAccount serviceaccount
где server – имя сервера, который будет соотнесён с MSA
serviceaccount – имя учетной записи MSA
Чтобы проверить, что операция выполнена успешно, нужно зайти в оснастку Active Directory Users and Computers, перейти в свойства сервера и посмотреть атрибут msDS-HostServiceAccount

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:
Install-ADServiceAccount -Identity serviceaccount
где serviceaccount – имя учетной записи MSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:
Test-ADServiceAccount serviceaccount
где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени MSA и перезапустить службу.
В конце имени MSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

В Windows Server 2012 появились Групповые управляемые учетные записи служб (Group Managed Service Accounts).
Они позволяют привязывать управляемую учетную запись не к одному серверу, а к нескольким.
Это может потребоваться, например, для использования в службе балансировки сетевой нагрузки.

Требования:

• Уровень схемы – Windows Server 2012
• Контроллер домена Windows Server 2012 (R2) на котором запущена служба Microsoft Key Distribution Service
• Windows Server 2012, 2012 R2, 8, 8.1
• Модуль администрирования Active Directory для PowerShell

Включение gMSA в PowerShell
1) Проверить, что включена служба Microsoft Key Distribution Services
“Служба распространения ключей использует общий секрет для создания ключей учетной записи. Эти ключи периодически изменяются. В дополнение к прочим атрибутам групповых управляемых учетных записей служб контроллер домена Windows Server 2012 вычисляет пароль для ключа, предоставленного службами распространения ключей. Обратившись к контроллеру домена Windows Server 2012, узлы Windows Server 2012 и Windows 8 могут получить текущий и предыдущий пароль.”
2) Создать Root Key
За создание Root Key отвечает командлет:
Add-KdsRootKey
Чтобы создать новый Root Key нужно выполнить командлет:
Add-KdsRootKey –EffectiveImmediately
В таком случае ключ будет доступен через 10 часов, пока не среплицируется.
Можно выполнить командлет:
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
В таком случае, ключ будет доступен сразу (-10 часов начала работы)
3) Создать gMSA
Выполнить командлет:
New-ADServiceAccount serviceaccount -DNSHostName test.test.com –PrincipalsAllowedToRetrieveManagedPassword $test
где serviceaccount – имя учетной записи gMSA
test.test.com – имя сервера, на котором был создан Root Key
$test – имя сервера, который может обращаться к KDS для получения информации

Можно зайти в Active Directory Users and Computers и убедиться, что gMSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

Картинка с сайта: habr.com

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:
Install-ADServiceAccount -Identity serviceaccount
где serviceaccount – имя учетной записи gMSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:
Test-ADServiceAccount serviceaccount
где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени gMSA и перезапустить службу.
В конце имени gMSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

Удалить MSA/gMSA можно с помощью командлета Uninstall-ADServiceAccount

Задавать параметры MSA/gMSA можно с помощью командлета Set-ADServiceAccount
Задание периода смены пароля:
Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60
где serviceaccount – имя учетной записи gMSA
60 – период, через который сменится пароль
Задание криптоалгоритмов Kerberos для использования MSA
Варианты: RC4, AES128, AES256
Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256
Задание SPN
Set-ADServiceAccount serviceaccount -ServicePrincipalNames @{Add=«добавляемый SPN»}

Задание NetBIOS имени для сервиса (SAMAccountName)
Если не задано, используется идентификатор Name
Если задано, имя отображения в AD будет из Name, а идентификатор для логина из SAMAccountName
Set-ADServiceAccount serviceaccount –SamAccountName test

MSA – это ещё один способ, который позволяет повысить безопасность.

Каждый из нас сталкивается с настройкой сервисных учетных записей. В большинстве случаев такая сервисная учетная запись нужна только для запуска одной или нескольких служб. Выполнять консольный вход в систему под этой учетной записью не планируется. Менять её пароль зачастую тоже не планируется. Однако, это справедливо не для всех случаев. В вашей компании может быть разработан регламент безопасности, в соответствии с которым пароли должны менять регулярно. И это может породить волну работ по смене пароля для сервисных учетных записей. Именно поэтому компания 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 — создание корневого ключа

Add-KdsRootKey -EffectiveImmediately

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

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

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

Get-KdsRootKey

Картинка с сайта: infoplex.ru

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

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

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

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

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

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

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

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

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

Get-ADServiceAccount -Identity cgpsvc1

Картинка с сайта: infoplex.ru

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

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

Add-WindowsFeature RSAT-AD-PowerShell

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

Install-ADServiceAccount -Identity cgpsvc1

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

Test-ADServiceAccount -Identity cgpsvc1

Картинка с сайта: infoplex.ru

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

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

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

Картинка с сайта: infoplex.ru

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

Картинка с сайта: infoplex.ru

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

Картинка с сайта: infoplex.ru

Если служба по каким-то причинам не запускается, то нужно либо смотреть журнал событий, либо руководство от вендора по настройке запуска службы от 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$ 

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

Заключение

В этой публикации мы разобрались с тем, что такое групповые управляемые учетные записи (Group Managed Service Account — gMSA). Также в публикации приведены требования, которым должны отвечать сервера и Active Directory для использования gMSA. Последним шагом я наглядно показал, как можно выполнить создания групповой управляемой учетной записи и настроить запуск службы от имени gMSA. 

microsoft-windows:windows-server-2012-r2:adds:how-to-use-managed-service-accounts-msa-and-group-managed-service-account-gmsa:how-to-create-an-msa-or-gmsa-account

Содержание

Создание учётных записей MSA и gMSA

Для создания учётной записи Managed Service Account (MSA) и Group Managed Service Account (gMSA) требуются права на уровне членства в группе Domain Admins в том случае, если создание учётной записи выполняется в контейнере Active Directory по умолчанию: CN=Managed Service Accounts,DC=holding,DC=com. Если указанного уровня прав нет, то можно использовать создание учётной записи в любом другом OU в домене, на который есть права уровня Account Operators.

Создание Managed Service Account

При необходимости создать учётную запись Managed Service Account, которая будет ограничена действием только в рамках одного компьютера, то есть учётную запись типа msDS-ManagedServiceAccount, достаточно выполнить команду типа:

New-ADServiceAccount -Name myMSA1 -RestrictToSingleComputer `
-Path "OU=Managed Service Accounts,OU=Service Objects,OU=KOM,DC=holding,DC=com"

Гдe:

• -Name – имя создаваемой учётной записи MSA.
  Обратите внимание на то, что имя имеет ограничение в 15 символов.

• -RestrictToSingleComputer – наличие этого параметра говорит о том, что нужно создать именно учётную запись MSA (не gMSA) действие которой ограничено одним каким-либо сервером.

• -Path — CN контейнера где будет создана учётная запись MSA, если нет желания использовать контейнер по умолчанию (CN=Managed Service Accounts,DC=holding,DC=com)

После успешного выполнения командлета убедимся в наличии объекта класса msDS-ManagedServiceAccount в указанном OU в домене.

Картинка с сайта: wiki.it-kb.ru

С помощью PowerShell можем запросить информацию о созданной учётной записи MSA командлетом Get-ADServiceAccount.

Картинка с сайта: wiki.it-kb.ru

Командлет New-ADServiceAccount имеет ряд других интересных параметров, узнать о которых можно, например, в онлайн справке.

В последствии созданную учётную запись можно будет привязать только к одному серверу.

Создание Group Managed Service Account

При необходимости создать групповую учётную запись Group Managed Service Account (класса msDS-GroupManagedServiceAccount), которую можно будет использовать в рамках нескольких компьютеров, например, на нескольких узлах какого-либо кластера, выполняем команду типа:

$server1 = Get-ADComputer "<имя сервера 1>"
$server2 = Get-ADComputer "<имя сервера 2>"
New-ADServiceAccount -Name "myGMSA1" -DNSHostName "myGMSA1.holding.com" `
-PrincipalsAllowedToRetrieveManagedPassword $server1,$server2 `
-ManagedPasswordIntervalInDays 60 `
-Path "OU=Managed Service Accounts,OU=Service Objects,OU=KOM,DC=holding,DC=com"

Гдe:

• -Name – имя создаваемой учётной записи gMSA

• -DNSHostName — FQDN имя, складывающееся из имени учётной записи (sAMAccountName) и доменного суффикса. Хотя есть разные толкования того, что должно быть указано в этом параметре (здесь и здесь.)

• -PrincipalsAllowedToRetrieveManagedPassword — перечень компьютеров домена, которым можно предоставить доступ к паролю учётной записи gMSA.

  Если количество серверов в кластере большое и может со временем меняться, то, возможно имеет смысл создать в домене AD отдельную глобальную группу безопасности, включить в неё учётные записи серверов-узлов кластера, и уже эту группу использовать в качестве значения параметра PrincipalsAllowedToRetrieveManagedPassword. Особенностью такого метода является то, что при изменении членства группы для вступления изменений в силу требуется перезагрузка сервера-участника группы.

• -ManagedPasswordIntervalInDays — Период (в днях) действия пароля до его автоматической смены (при смене генерируется стойкий пароль длинной в 240 символов). Если параметр не указан по умолчанию используется значение в 30 дней.

Картинка с сайта: wiki.it-kb.ru

После успешного выполнения командлета убедимся в наличии объекта класса msDS-GroupManagedServiceAccount в указанном OU в домене

Картинка с сайта: wiki.it-kb.ru

Замечания

Создавая учётные записи MSA/gMSA лучше руководствоваться принципом «отдельный сервис – отдельная учётная запись» и не пытаться использовать одну учётную запись MSA/gMSA для разных служб, так как это понижает уровень безопасности всех служб/приложений, совместно использующих одну и туже учётную запись. К тому же даже с точки зрения отладки работы служб и приложений использование разных учётных записей может дать свои преимущества.

---

Проверено на следующих конфигурациях:

Версия ОС
Windows Server 2012 R2 Standard EN (6.3.9600)

---

Автор первичной редакции:
Алексей Максимов
Время публикации: 30.10.2018 17:21

Рассказывая об администрировании Active Directory (AD) с помощью средств PowerShell, я замечаю, что мои слушатели, даже если выражают готовность к освоению PowerShell, в глубине души надеются, что им никогда не придется этого делать. Они убеждены, что для работы с AD в Windows Server 2008 R2 или Server 2012 вовсе не обязательно постигать эту науку. В самом деле, очень многое можно делать в графическом интерфейсе, возникает лишь вопрос целесообразности. К примеру, учетную запись для себя как преподавателя я гораздо быстрее установлю с помощью команды

set-aduser mark -title 'teacher',

чем с использованием оснастки Users and Computers или центра администрирования Active Directory. Разблокировать учетную запись пользователя Larry тоже намного проще, если ввести команду

unlock-adaccount larry

вместо запуска оснастки Users and Computers Active Directory. Запрос серверу глобального каталога легче направить с помощью средств PowerShell (просто добавить -server servername:3268 к запросу get-aduser), чем из графического интерфейса. Такие примеры убеждают скептиков, но далеко не всегда. Поэтому приходится прибегать к «тяжелой артиллерии», а именно, к управляемым учетным записям служб managed service acconyt (MSA).

Вероятно, вам приходилось создавать доменную учетную запись для службы, запускаемой на сервере (или для пула приложений IIS). Создание учетной записи может потребоваться на одном из этапов процесса установки важного серверного приложения. О создании учетной записи для новой службы также может вас проинформировать программа установки. В любом случае необходимая учетная запись создается, после чего новая служба запускается в эксплуатацию. Все довольны, но лишь до определенного момента.

Однажды вы приходите на работу, а там царит всеобщее замешательство. Служба, установленная шестью неделями ранее, перестала работать, и вы вдруг понимаете, что политика доменных паролей требует новый пароль каждые шесть недель. Вы сбрасываете пароль (так, чтобы этого не заметил никто из отдела информационной безопасности) и выставляете флажок Password never expires («Срок действия пароля не ограничен»).

В противоположность этому в системе с Server 2008 R2 или Server 2012 можно пропустить этап создания доменной учетной записи, необходимой для работы службы, и установить управляемую учетную запись службы MSA. Дополнительная информация об управляемых учетных записях службы MSA приведена во врезке «Различие между MSA и gMSA».

В системе, где есть как минимум один контроллер домена DC 2008 R2 и где служба запускается на рядовом сервере 2008 R2 или Server 2012, достаточно просто создать MSA и настроить службу на работу под этой учетной записью (поле пароля в оснастке Services следует оставить пустым – оно заполняется автоматически). После этого учетная запись MSA и рядовой сервер каждый месяц создают новый пароль без необходимости вмешательства администратора.

Мне непонятно, почему большинство администраторов Server 2008 R2/Server 2012 никогда не слышали об MSA, но когда я излагаю этот сценарий своим скептически настроенным слушателям, изучающим AD, они удивляются. Какое отношение это имеет к PowerShell? Самое прямое, поскольку по какой-то причине создать MSA можно только с помощью средств PowerShell.

В PowerShell для обозначения MSA используется «существительное» –ADServiceAccount, и если вы хоть немного знакомы с PowerShell, то догадаетесь, что для создания MSA применяется команда new-adserviceaccount. Например, создание учетной записи с именем svc1 выглядит так:

new-adserviceaccount -name svc1

Если учетная запись создается в системе Server 2012, то добавляется –RestrictToSingleComputer:

new-adserviceaccount -name svc1 -RestrictToSingleComputer

После этого непосредственно на рядовом сервере, где будет работать служба, либо в ходе инициируемого с помощью Enter-PSSession интерактивного сеанса с этим компьютером (параметр –computername здесь не работает), мы внедряем созданную управляемую учетную запись службы рядовой сервер, для чего применяем команду install-adserviceaccount, вслед за которой через пробел указываем имя управляемой учетной записи службы, как показано ниже:

install-adserviceaccount svc1

Теперь остается лишь дать указание службе работать под этой учетной записью, для чего следует открыть оснастку Services и ввести имя учетной записи MSA, оставляя поле пароля пустым. MSA, как и учетная запись компьютера, в конце должна иметь символ $. В нашем примере для учетной записи svc1 в домене с NetBIOS-именем bigfirm это выглядит так:

bigfirmsvc1$

Остальное происходит автоматически. Надеюсь, что MSA для многих может стать решающим доводом в пользу освоения PowerShell.