Управляемые служебные учетные записи (Managed Service Accounts, MSA)
Автор - Нед Пайл (https://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx)
Сегодня я хочу представить вашему вниманию одну из новых фишек Windows Server 2008 R2/Windows 7 - управляемые служебные учетные записи.
Что это такое и для чего они вообще нужны, эти управляемые записи?
MSA - это специальные учетные записи, призванные упростить администрирование и повысить безопасность систем. Основным отличием MSA от существующих служебных записей является управление паролями и SPN этих записей при помощи Windows. То есть, когда придет время менять пароль учетной записи, управляющей некоей службой, не придется тормозить службу, вручную лезть в свойства учетной записи и менять пароль, после чего снова запускать службу. Все будет делаться автоматически, без перебоев. Соответственно, мы получаем более надежную и безопасную систему.
Несколько подробнее об общем принципе работы MSA
В схеме Windows Server 2008 R2 введен новый класс объекта: msDS - ManagedServiceAccount. MSA обладает интересной структурой наследования в атрибуте objectClass:
Computer
msDS - ManagedServiceAccount
organizationalPerson
Top
User
Объект является одновременно компьютером и пользователем, почти как учетная запись компьютера. Однако в отличие от нее, класс объекта personздесь отсутствует – вместо него установлен класс msDS - ManagedServiceAccount. MSA наследует от родительского объекта класс “Computer”, но также является и пользователем. Никаких новых атрибутов от обновления схемы до уровня Win2008 R2 MSA не получают.
Обновление пароля у MSA, являющегося псевдокомпьютерным объектом, происходит аналогично смене пароля компьютеров. Пароль меняется синхронно со сменой пароля компьютера (по умолчанию – раз в 30 дней). Управлять сменой пароля можно при помощи следующих параметров реестра (тип DWORD):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
DisablePasswordChange= [0 либо 1, если параметр отсутствует, принимается равным 0]
MaximumPasswordAge= [1-1,000,000 в днях, если параметр отсутствует, принимается равным 30]
Как и компьютеры, MSA не подчиняются доменной политике паролей. Для них используется комплексный автоматически генерируемый пароль из 240 символов в случайном порядке. MSA не могут быть заблокированы и не могут выполнять интерактивный вход. При желании администраторы могут задавать пароль MSA явно, хотя лично я особенного смысла в этом не вижу.
Все MSA по умолчанию создаются в контейнере CN = ManagedServiceAccounts , DC =< domain >, DC =< com > . Просмотреть его можно, настроив отображение дополнительных возможностей в консоли ADUC:
Однако, это всего лишь необязательное дополнение – основное управление MSA осуществляется при помощи PowerShell.
MSA автоматически поддерживают свои имена участника-службы (SPN) Kerberos, могут быть привязаны только к одному компьютеру и поддерживают делегирование. На нижеприведенном кадре сетевого обмена показан правильно настроенный MSA относительно Kerberos:
Разворачиваем MSA
Требования к ОС и лесу
Обязательные требования для MSA таковы:
- Наличие Active Directory
- Уровень схемы – Windows Server 2008 R2
- Службы, которые будут выполняться от имени MSA, должны размещаться на компьютерах под управлением Windows Server 2008 R2 либо Windows 7 – использование MSA с более ранними версиями ОС невозможно.
- Наличие на компьютерах, работающих с MSA PowerShell, AD PowerShell (входит в состав RSAT), и .Net 3.5x Framework
Что до уровня леса, то особенных ограничений на него нет.
С уровнем домена, однако, все не так гладко – если он отличен от Server 2008 R2, часть функционала MSA теряется, то есть:
- Уровень Server 2008 R2 – полностью работоспособны автоматическое управление паролями и SPN.
- Уровень Server 2008 и ниже – автоматическое управление SPN перестает работать и обслуживание возлагается на администраторов. Управление паролями работает как ни в чем не бывало.
Развертывание
MSA разворачивается в 4 этапа:
1. Создаем MSA в AD.
2. Привязываем MSA к компьютеру в AD.
3. Устанавливаем MSA на компьютер из шага 3.
4. Настраиваем службы на использование MSA
Чтобы создать MSA, запускаем PowerShell – на сервере или на Windows 7 с установленным RSAT. Команды, естественно, выполняем с повышенными привилегиями.
1. Запускаем PowerShell.
2. Импортируем модуль AD module:
Import-Module ActiveDirectory
3. Создаем MSA:
New-ADServiceAccount -Name < уникальное имя учетной записи MSA> -Enabled $true
Замечание: на текущий момент имя MSA не может быть длиннее 15 символов. В противном случае вам будет выдана ошибка:
Install-ADServiceAccount : Cannot install service account. Error Message: 'Unknown error (0xc0000017)'.At line:1 char:25+ install-adserviceaccount <<<< -identity SVC_SQL01_LongName + CategoryInfo : WriteError: (SVC_SQL01_LongName:String) [Install- ADServiceAccount], ADException + FullyQualifiedErrorId : InstallADServiceAccount:PerformOperation:Install ServiceAcccountFailure,Microsoft.ActiveDirectory.Management.Commands.InstallADServiceAccount
Работа над этой проблемой ведется, так что мое предупреждение в какой-то момент может оказаться неактуальным – просто имейте это в виду.
4. Привязываем созданный MSA к целевому компьютеру в AD:
Add - ADComputerServiceAccount - Identity <компьютер, к которому привязываем MSA > - ServiceAccount <Учетная запись MSA , созданная на шаге 3>
5. Заходим на компьютер, к которому привязали MSA. Проверяем наличие следующих компонентов (скриншоты даны для Server 2008 R2)::
- Active Directory Module for Windows PowerShell
- .NET Framework 3.5.1
6. Запускаем PowerShell.
7. Импортируем модуль AD:
Import-Module ActiveDirectory
8. Устанавливаем MSA:
Install-ADServiceAccount -Identity < учетная запись MSA , созданная на шаге 3>
Замечание: учетная запись, от имени которой выполняется этот шаг, должна иметь права изменения MSA в AD. Фактически, это должен быть администратор домена либо учетная запись с делегированным правом изменения служебной учетной записи в AD.
9. Ассоциируем MSA со службами:.
Через графический интерфейс:
a. Запускаем services . msc.
b. Редактируем свойства службы.
c. На вкладке LogOn в поле “ThisAccount” вписываем имя нашего MSA в формате domain \ name $ (значок $ после имени критичен!). Например, если имя MSA “AskDS” в домене “contoso.com”, запись будет выглядеть вот так:
contoso \ askds $
d. Из полей PasswordиConfirmpassword удаляем все данные – это важно!
e. Нажимаем Apply и Ok; появится сообщение “Logon as a Service Right granted”:
f. Запускаем службу. Все должно пройти гладко.
При помощи PowerShell :
a. Запускаем PowerShell.
b. Вставляем образец скрипта в текстовый файл:
# Sample script for setting the MSA password through PowerShell # Provided "AS IS" with no warranties, and confers no rights. # See https://www.microsoft.com/info/cpyright.mspx # Edit this section: $MSA="contoso\askds$ " $ServiceName="'testsvc'" # Don't edit this section: $Password=$null $Service=Get-Wmiobject win32_service -filter "name=$ServiceName" $InParams = $Service.psbase.getMethodParameters("Change") $InParams["StartName"] = $MSA $InParams["StartPassword"] = $Password $Service.invokeMethod("Change",$InParams,$null) |
c. Заменяем значения, выделенные красным, на корректные имена MSA (не забываем про значок $) и службы.
d. Сохраняем файл под именем MSA . ps1.
e. В консоли PowerShell вызываем политику выполнения скриптов:
Get-ExecutionPolicy
f. Устанавливаем политику в режим дистанционного подписывания:
Set-ExecutionPolicy remotesigned
g. Запускаем скрипт:
h. Возвращаем политику выполнения в исходное состояние (у меня было restricted):
Удаление
Удаление MSA происходит в два этапа:
1. При помощи командлета удаляем MSA с локального компьютера:
Remove-ADServiceAccount –identity < имя MSA>
2. При желании удаляем MSA из AD. Если нужно только изменить привязку MSA, этот шаг пропускаем:
Remove - ADComputerServiceAccount – Identity <компьютер, к которому MSA был привязан> - ServiceAccount <имя MSA >
Членство в группах
Командлеты Set - ADServiceAccount и New - ADServiceAccountдля включения MSA в группы не годятся. Для этой цели придется использовать консоль ADUC либо командлет Add - ADGroupMember.
AD Users and Computers:
1. Запускаем DSA.MSC.
2. Выбираем группу ( не MSA).
3. Добавляем MSA через вкладку Members:
PowerShell :
1. Запускаем PowerShell.
2. Выполняем:
Add - ADGroupMember "<группа>" "< DNMSA > "
Например:
Замечание : используйте различающееся имя (DN) MSA; в противном случае Add - ADGroupMember вернет ошибку “ cannotfindobjectwithidentity ” . Не пытайтесь использовать команду NETGROUP – она не умет определять MSA.
Ограничения
Управляемые служебные учетные записи весьма полезны в большинстве служебных сценариев. Однако, как и везде, здесь есть свои ограничения, которые крайне желательно знать, чтобы в дальнейшем сэкономить время.
- MSA не могут работать с несколькими компьютерами – MSA привязывается к одному компьютеру и не может быть установлен более чем на один компьютер. На практике это означает, что MSA нельзя применять для:
- Узлов кластера
- Балансировки нагрузки с проверкой подлинности посредством Kerberos для группы веб-серверов.
В силу этой своей особенности MSA несовместимы с отказоустойчивыми кластерами. Проверка подлинности через балансировщик будет требовать предоставления SPN MSA – что тоже не сработает. Так что если вы работаете с кластерами или с балансировщиками – используйте старые служебные учетные записи, другого пути нет.
Ключевой момент: На один компьютер можно привязать сколь угодно много MSA. Так что, если у вас есть приложение, использующее, скажем, пять служб, можно как назначить один MSA для всех пяти, так и по одному MSA для каждой службы.
- Поддержка MSA определяется компонентом, а не операционной системой. – То, что ваша ОС поддерживает MSA, еще не значит, что MSA поддерживается службой, для которой вы хотите его использовать. Так что если у вас не получится привязать MSA к SQL, и поддержка скажет вам «Мы не поддерживаем MSA в версии номер такой-то» - это так и есть, и остается лишь дожидаться выхода версии, в которой будет поддержка MSA.
Решение проблем
В большинстве случаев ошибки MSA легко читаемы и понимаемы, однако есть несколько ошибок, с которыми люди сталкиваются весьма часто:
Ошибка : Error 1069: The service did not start due to a logon failure.
Причина: Как правило, появляется если MSA отключен. Включите его при помощи командлета Set - ADServiceAccount.
Ошибка : Duplicate Backlink. The service account 'AskDS2' has backlinks to computer 'CN=2008R2-F-05,CN=Computers,DC=contoso,DC=com'. This add operation will potentially disable service accounts installed on the other computer. Cannot install service account. Error Message: 'Unknown error (0xc000005a)
Причина: Попытка привязать уже привязанный MSA к другому компьютеру Ошибка указывает на сервер (в данном примере 2008r2-f-05), который в данный момент использует MSA. Удалите MSA с этого компьютера и отвяжите его прежде, чем привязывать к другому компьютеру.
Ошибка : Add-ADComputerServiceAccount : The object could not be found on the server.
Причина: указан некорректный идентификатор MSA, и PowerShell не может его найти. MSA мог быть удален, или указано неверное имя.
Ошибка: Please enter a valid password.
Причина: При редактировании свойств службы на вкладке LogOnне был очищены поля пароля. См. ранее приведенные указания по настройке.
Ошибка : The account name is invalid or does not exist, or the password is invalid for the account name specified.
Причина: Как правило, происходит из-за того, что после имени на вкладке LogOn в свойствах службы не был написан знак $. Также эта ошибка может появиться из-за банальной опечатки в имени учетной записи или указания неверного имени домена.
Дополнительная информация
Получить дополнительную информацию о MSA можно на следующих ресурсах:
Дерзайте – вы талантливы :-)