Служебные учетные записи windows

Этим постом мы завершаем публиковать перевод цикла статей по управлению службами Windows с помощью PowerShell, которые выходят на сайте 4sysops.com. В предыдущем посте было рассмотрено как осуществлять управление службами Windows в Server 2012 c помощью CIM-командлетов, представленных в PowerShell 3.0. В этом посте мы рассмотрим, как осуществлять управление служебными учетными записями с помощью WMI- и CIM-командлетов.
Итак, под катом приведен перевод статьи с портала 4sysops.com Managing Services the PowerShell way – Part 8

Предыдущие статьи:
Управляем службами Windows с помощью PowerShell. Часть 1. Получаем статус служб
Управляем службами Windows с помощью PowerShell. Часть 2. Остановка, запуск, пауза
Управляем службами Windows с помощью PowerShell. Часть 3. Конфигурируем службы с помощью WMI и CIM
Управляем службами Windows с помощью PowerShell. Часть 4. Изменение служб с помощью WMI
Управляем службами Windows с помощью PowerShell. Часть 5. CIM-командлеты

Используем WMI

Чтобы изменить пароль служебной учетной записи, нам нужна ссылка на объект службы. И я предполагаю, что это служба с учетной записью пользователя.

PS C:\> get-wmiobject win32_service -filter "name='yammmsvc'" | Select name,startname

name                                              startname
----                                              ---------
YammmSvc                                          .\Jeff

В этом посте мы рассматривали, что для этих целей можно использовать метод Change() для изменения пароля служебной учетной записи. Также помним, что параметры Invoke-WmiMethod не следует задокументированному на MSDN порядку.

PS C:\> $svc = get-wmiobject win32_service -filter "name='yammmsvc'"
PS C:\> $svc.GetMethodParameters("change")

__GENUS                    : 2
__CLASS                    : __PARAMETERS
__SUPERCLASS               :
__DYNASTY                  : __PARAMETERS
__RELPATH                  :
__PROPERTY_COUNT           : 11
__DERIVATION               : {}
__SERVER                   :
__NAMESPACE                :
__PATH                     :
DesktopInteract            :
DisplayName                :
ErrorControl               :
LoadOrderGroup             :
LoadOrderGroupDependencies :
PathName                   :
ServiceDependencies        :
ServiceType                :
StartMode                  :
StartName                  :
StartPassword              :
PSComputerName             :

Пароль находится на 11 месте. А это значит, что нам необходимо вставить пустые значения для 10 предыдущих параметров, которые не меняются.

PS C:\> $svc | Invoke-WmiMethod -Name Change -ArgumentList
@($null,$null,$null,$null,$null,$null,$null,$null,$null,$null,"P@ssw0rd")

__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 1
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ReturnValue      : 0
PSComputerName   :

0 в качестве возвращенного значения означает успешность нашего действия. Но помните, что изменение не вступит в силу, пока мы не перезапустим службы. Если вы забыли, как это сделать, то смотрите один из предыдущих постов.
Если вы хотите изменить имя учетной записи, необходимо уточнить его в предыдущем параметре.

PS C:\> $svc | Invoke-WmiMethod -Name Change -ArgumentList @($null,$null,$null,$null,$null,$null,$null,$null,$null,"LocalSystem","P@ssw0rd")

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

Используем CIM

Однако гораздо проще использовать CIM-командлеты для решения подобных задач. Еще раз поменяем учетную запись и пароль для службы.

PS C:\> Get-CimInstance win32_service -filter "name='yammmsvc'" | Invoke-CimMethod -Name Change -Arguments @{StartName=".\Jeff";StartPassword="P@ssw0rd"}

И снова возращенное значение должно быть равно 0. Введите startname в формате MACHINE\USERNAME или DOMAIN\USERNAME. В моем случае, Jeff – это локальная учетная запись. Если Вы хотите только изменить пароль, вам необходимо лишь откорректировать аргумент в хеш-таблице.
Отметим, что вы можете выполнить запрос и изменить его с помощью Invoke-CimMethod. Объект в него передавать не надо.

PS C:\> Invoke-CimMethod -Name Change -Arguments {StartName=".\Jeff";StartPassword="P@ssw0rd"} -Query "Select * from Win32_Service where name='yammmsvc'" –Computername JeffPC

Хотя запустить команду можно было и локально, я решил показать ее запуск на удаленном компьютере. Ниже приведен пример для изменения службы на нескольких компьютерах.

PS C:\> Invoke-CimMethod -Name Change -Arguments @{StartPassword="P@ssw0rd"} -Query "Select * from Win32_service where name='MyCustomService'" –computername $computers | out-file c:\work\results.txt

Как вы видите, я сбросил пароль для службы MyCustomService запущенной на всех компьютерах, перечисленных в переменной $computers. Результаты сохраняются в текстовый файл, в котором указаны имя компьютера и возращенное значение. Конечно, службы нужно перезапустить, чтобы изменения вступили в силу.

Подводим итоги

Если вам необходимо осуществлять управление служебной учетной записью, то вам потребуется использовать WMI – через WMI- или CIM-командлеты. Последние гораздо проще в использовании.

Предыдущие статьи:
1. Получаем статус служб
2. Остановка, запуск, пауза
3. Конфигурируем службы с помощью WMI и CIM
4. Изменение служб с помощью WMI
5. CIM-командлеты

Для безопасного запуска служб, приложений и заданий планировщика на серверах и рабочих станциях домена 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

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

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

Администраторы иногда используют свою учетную запись пользователя в качестве учетной записи службы. Это может показаться достаточно удобным. Что может пойти не так?

Множество аспеков. Во-первых, это дополнительный уровень воздействия для учетной записи администратора. Если хакер скомпрометирует учетную запись службы, он получит все привилегии, которыми обладает эта учетная запись, то есть не только запуск одного приложения, но и все остальное, что администратор может делать в домене. Это также разрушает подотчетность, поскольку журнал того, что сделала учетная запись администратора, теперь включает действия, которые фактически выполняются приложением. Наконец, непрерывность бизнеса: что происходит, когда администратор обновляет свой пароль или покидает организацию, а его учетная запись удаляется? Все приложения и службы, использующие эту учетную запись как учетную запись службы, внезапно перестают работать.

Чтобы избежать этих проблем, никогда не позволяйте администраторам использовать свои личные учетные записи в качестве учетных записей служб. Проводите обучение надлежащим процедурам и регулярно проверяйте использование учетной записи службы, чтобы выявить любые нарушения.

3. Для каждой службы используйте учетную запись службы Microsoft, предназначенную для этой службы.

Аналогичные проблемы возникают, если вы используете одну и ту же учетную запись службы для нескольких приложений. Начнем с безопасности. Встроенные учетные записи служб, такие как LocalSystem, часто используются для запуска нескольких служб. Каждая из этих учетных записей имеет свой набор разрешений по умолчанию, но со временем этот набор разрешений имеет тенденцию расширяться, поскольку тому или иному приложению требуются дополнительные права, и эти дополнительные разрешения могут использоваться всеми службами, а не только одной.

Ответственность и устранение неполадок также становится намного сложнее. Например, если пароль для общей учетной записи службы изменен, каждая попытка приложения пройти аутентификацию с использованием старого пароля будет неудачной; вы увидите, что приложения не работают, но определить основную причину может быть непросто. Более того, если общая учетная запись службы будет удалена или ее пароль будет изменен, у вас будет отключена не одна служба, а множество, что усугубит влияние на бизнес.

Чтобы обеспечить соблюдение этой передовой практики, регулярно используйте решение, такое как Enterprise Reporter, для сканирования всех ваших компьютеров и создания отчета о том, какие учетные записи используются в качестве службы. Если несколько служб совместно используют учетную запись службы Microsoft, вы можете правильно настроить каждую службу с помощью выделенной учетной записи.

4. Строго соблюдайте минимальные привилегии.

Также важно убедиться, что каждая учетная запись службы имеет только те разрешения, которые ей необходимы для выполнения поставленной перед ней задачи. Хотя строгое соблюдение минимальных привилегий никогда не бывает простым, все намного проще, когда у каждой службы есть собственная выделенная учетная запись службы Microsoft.

Имейте в виду, что поставщики часто говорят, что их приложения требуют прав администратора домена, но на самом деле это не всегда так. Часто этот уровень привилегий требуется только для первоначальной установки службы, а не для ее последующего запуска. Предоставляя каждой учетной записи службы только те разрешения, которые ей действительно необходимы (так же, как и для любой другой учетной записи), вы ограничиваете ущерб, который вы можете понести, если учетная запись будет скомпрометирована, приложение взломано или имеет серьезную программную ошибку.

5. Оценивайте необходимость интерактивного входа в систему для сервисных учетных записей

Обратите особое внимание на то, должна ли служба иметь возможность входа в систему в интерактивном режиме. Интерактивный вход в систему обычно ограничен отдельными лицами, которым необходимо взаимодействовать с ИТ-средой путем создания документа, обмена сообщениями с товарищем по команде, создания заявки в службу поддержки и т. д. Учетные записи служб, с другой стороны, обычно запускают службы за кулисами, без необходимости такого взаимодействия. Действительно, некоторые эксперты советуют относиться к сервисным учетным записям, выполняющим интерактивный вход, как к тревожному сигналу. Один из способов применить эту передовую практику — поместить все учетные записи служб Microsoft в специальную группу безопасности AD и использовать групповую политику, чтобы предотвратить интерактивный вход любой учетной записи в этой группе.

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

6. По возможности используйте MSA.

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

7. Если вы не можете использовать MSA, обязательно измените пароли сервисных учетных записей регулярно.

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

• Никогда не оставляйте для учетной записи службы пароль по умолчанию, выбранный поставщиком приложения. Хакеры могут легко найти эти пароли в Интернете и проникнуть в вашу сеть.
• Не выбирайте простые пароли. Фразы «1234» или «пароль» легко ввести, но невероятно легко взломать.
• Не устанавливайте бессрочный пароль. Слишком часто организации годами оставляют пароли сервисных учетных записей неизменными, что значительно увеличивает риск неправомерного использования или компрометации учетной записи.

Вместо этого выберите очень сложный пароль для каждой учетной записи службы и убедитесь, что он постоянно меняется. Рассмотрите возможность инвестирования в решение для управления привилегированными учетными записями (PAM), которое может управлять учетными данными для вас; таким образом, ни один человек никогда не узнает, что такое пароль, и его можно будет автоматически изменить.

8. Убедитесь, что вы можете быстро восстановить учетную запись службы или ее пароль.

Конечно, изменение пароля для учетной записи службы Microsoft сопряжено с риском: если изменение не будет выполнено должным образом, приложение или служба, с которыми оно связано, больше не смогут функционировать. Кроме того, может быть удалена сама учетная запись службы — например, она может быть удалена во время плановой очистки учетной записи или, как упоминалось выше, в рамках обычной деинициализации, когда администратор покидает организацию, но его учетная запись используется в качестве сервисного аккаунта.

Если это произойдет, критически важные бизнес-процессы могут быть легко нарушены, а часы тикают. Поэтому рекомендуется убедиться, что вы можете быстро восстановить любую учетную запись службы Microsoft, которая была удалена по ошибке, а также выборочно восстановить свойства учетной записи, такие как пароли, инвестируя в комплексное решение для резервного копирования и восстановления Active Directory.

9. Всегда ограничивайте делегирование учетных записей служб.

Учетную запись службы Майкрософт можно настроить таким образом, чтобы ей разрешался доступ к ресурсам от имени пользователя без необходимости входа в систему от имени этого другого пользователя. Например, предположим, что у вас есть веб-сервер, которому требуется доступ к данным в базе данных SQL Server. Вероятно, вы не хотите предоставлять учетной записи службы, которая запускает веб-сервер, разрешения на прямой доступ к базе данных; используя делегирование, вы можете включить его для запроса этих ресурсов от имени пользователя, который вошел в систему, используя свои собственные учетные данные.

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

Чтобы ограничить делегирование учетной записи службы Microsoft, откройте «Пользователи и компьютеры Active Directory», перейдите к «Просмотр» и включите «Дополнительные функции». Щелкните правой кнопкой мыши учетную запись службы и выберите Делегирование. Затем выберите «Доверять этому пользователю делегирование только указанным службам» и выберите соответствующие службы в поле ниже. Также разумно разрешить использование только протокола Kerberos, так как это самый безопасный протокол аутентификации. (Обратите внимание, что для использования проверки подлинности Kerberos учетная запись службы должна иметь имя участника-службы (SPN), зарегистрированное в Active Directory.)

Рассказывая об администрировании 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.