共用方式為

Управляемые служебные учетные записи (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 можно на следующих ресурсах:

Дерзайте – вы талантливы :-)

Comments

  • Anonymous
    January 01, 2003
    Полезно было почитать, спасибо!