Управляемые служебные учетные записи (Managed Service Accounts, MSA)


 

Автор — Нед Пайл (http://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 введен новый класс объекта: msDSManagedServiceAccount. MSA обладает интересной структурой наследования в атрибуте objectClass:

Computer
msDSManagedServiceAccount
organizationalPerson
Top
User

Объект является одновременно компьютером и пользователем, почти как учетная запись компьютера. Однако в отличие от нее, класс объекта person здесь отсутствует – вместо него установлен класс msDSManagedServiceAccount. 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=Managed Service Accounts, 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:

AddADComputerServiceAccountIdentity <компьютер, к которому привязываем 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. На вкладке Log On  в поле “This Account” вписываем имя нашего MSA в формате domain\name$ (значок $ после имени критичен!). Например, если имя MSA “AskDS”  в домене “contoso.com”, запись будет выглядеть вот так:

contoso\askds$

d. Из полей Password и Confirm password удаляем все данные – это важно!


 

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 http://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, этот шаг пропускаем:

RemoveADComputerServiceAccountIdentity <компьютер, к которому MSA был привязан>ServiceAccount <имя MSA>

 

 

Членство в группах

Командлеты SetADServiceAccount и NewADServiceAccount  для включения MSA в группы не годятся. Для этой цели придется использовать консоль ADUC либо командлет AddADGroupMember.

AD Users and Computers:

1. Запускаем DSA.MSC.

2. Выбираем группу (не MSA).

3. Добавляем MSA через вкладку Members:


 

PowerShell:

1. Запускаем PowerShell.

2. Выполняем:

AddADGroupMember «<группа>» «<DN MSA>«

Например:


 

Замечание:  используйте  различающееся имя (DN) MSA; в противном случае AddADGroupMember вернет ошибку cannot find object with identity. Не пытайтесь использовать команду NET GROUP – она не умет определять 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 отключен. Включите его при помощи командлета  SetADServiceAccount.

Ошибка: 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.

Причина: При редактировании свойств службы на вкладке  Log On не был очищены поля пароля. См. ранее приведенные указания по настройке.

Ошибка: The account name is invalid or does not exist, or the password is invalid for the account name specified.

Причина: Как правило, происходит из-за того, что после имени на вкладке Log On в свойствах службы не был написан знак $. Также эта ошибка может появиться  из-за банальной опечатки в имени учетной записи или указания неверного имени домена.

Дополнительная информация

Получить дополнительную информацию о MSA можно на следующих ресурсах:

Дерзайте – вы талантливы 🙂

 

 

Comments (1)

  1. Аноним:

    Полезно было почитать, спасибо!

Skip to main content