Среди изменений Active Directory (AD) в Windows Server 2008 R2 прежде всего обращает на себя внимание AD Recycle Bin — долгожданная возможность восстанавливать удаленные объекты без принудительного восстановления базы хранилища. Но начав работать с Server 2008 R2, пользователи замечают появление еще одной полезной функции managed service account (MSA), управляющей учетными записями служб. Функция MSA позволяет управлять служебными учетными записями, что существенно облегчает работу большинства организаций.

Почему MSA?

Многие службы основаны на взаимодействии с другими сетевыми ресурсами и службами каталогов вне локального компьютера. Обычно это означает, что служба работает как встроенная сетевая учетная запись службы Network Service Account, как встроенная учетная запись локальной системы Local System Account или как учетная запись пользователя домена. Применение учетных записей Network Service Account или Local System Account, которые взаимодействуют с другими сетевыми ресурсами, кажется заманчивым. Однако при использовании этих встроенных учетных записей возникает много проблем.

Службам часто требуются определенные права и привилегии. Применение встроенных учетных записей, особенно Local System Account, дает службе права и привилегии, намного превышающие фактическую целесообразность на локальной системе, а возможно, и сети. Это приводит к тому, что служба с чрезмерными привилегиями увеличивает степень уязвимости. Наша задача состоит в том, чтобы обеспечить службы только необходимыми разрешениями.

Именно проблема избыточных привилегий с Local System Account и была причиной реализации Network Service Account в Windows Server 2003, поскольку таким образом обеспечивается возможность иметь встроенную учетную запись без полных системных привилегий на локальной системе, но с сетевым доступом от имени учетной записи компьютера. Кроме проблемы избыточных привилегий, когда многие службы используют одну и ту же учетную запись, затрудняется проверка действий, выполненных на сервере.

Это приводит к необходимости задействовать одну выделенную учетную запись пользователя домена для служб. Для большинства приложений, которым необходим запуск в виде службы, обычно рекомендуется создать учетную запись пользователя домена с установленным набором привилегий. Администраторы часто пытаются минимизировать число учетных записей, поэтому применяется одна учетная запись домена для многих служб. Само по себе это плохо для разграничения привилегий учетных записей между разными службами. Кроме того, общая учетная запись использует и сумму всех требуемых прав для всех служб, совместно применяющих эту учетную запись, поэтому каждая служба фактически будет иметь больше разрешений, чем необходимо.

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

Без хлопот с паролями

Управляемые учетные записи служб MSA решают проблему управления паролями через их автоматическую регенерацию в процессе сетевой регистрации (процесс netlogon), с помощью которого пароль учетной записи компьютера автоматически переустанавливается. По умолчанию раз в 30 дней процесс netlogon генерирует новый пароль из последовательности случайных 240 символов и синхронизирует пароль в домене. Компьютерные объекты и учетные записи MSA игнорируются политиками безопасности домена и политиками тонкой настройки паролей, в результате чего пароль всегда состоит из 240 символов, в отличие от требований указанных выше политик, как, например, обязательности восьмисимвольных паролей. Для использования управляемых учетных записей служб MSA необходимо соответствие двум условиям.

  1. Лес AD должен быть предварительно подготовлен командой forest prep из Server 2008 R2, добавляющей новый класс объектов, msDS-ManagedServiceAccount, который хранит информацию для MSA в AD.
  2. Система, использующая MSA, должна работать под управлением Server 2008 R2 или Windows 7. В настоящее время не планируется поддерживать функциональность MSA в более ранних версиях Windows.

Домен не обязательно должен работать на уровне Server 2008 R2 или даже Server 2008. Однако, если все доменные контроллеры DC запускаются на Server 2008 R2, то от MSA можно получить дополнительную функциональность, о которой я расскажу позже.

Новый контейнер Managed Service Accounts создается в корневом каталоге домена; в нем по умолчанию находятся все управляемые учетные записи служб MSA, но можно их сохранить и в другом месте. Чтобы увидеть записи MSA, созданные в этом контейнере, включите просмотр в расширенном режиме Advanced Features в оснастке Active Directory Users and Computers (ADUC).

Нельзя управлять записями MSA с помощью графического интерфейса — как во многих других случаях при работе с AD в Server 2008 R2, но можно воспользоваться PowerShell для управления MSA. Чтобы задействовать управляемую учетную запись службы MSA, необходимо выполнить четыре операции.

  1. Создать запись MSA в AD с помощью команды New-ADServiceAccount PowerShell.
  2. Связать запись MSA с определенной компьютерной учетной записью в AD по команде Add-ADComputerServiceAccount PowerShell.
  3. Установить эту MSA на компьютер по команде Install-ADServiceAccount PowerShell.
  4. Настроить службы на компьютере на использование данной записи MSA, что можно сделать через оснастку Servicesв MMC (services.msc) или через другой интерфейс управления службами типа WMI, SC или PowerShell.

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

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

Создание и применение MSA

Давайте создадим учетную запись MSA, установим ее на сервер и настроим службу для использования MSA. Во всех случаях для запуска любой из команд PowerShell необходимо установить модуль Active Directory Module for Windows PowerShell, который является компонентом Remote Server Administration Tools (RSAT) и находится в разделе Active Directory Domain Services (AD DS) и Active Directory Light Directory Services (AD LDS) Tools, показанном на экране 1. Эти команды должны присутствовать как на компьютере, с которого управляют учетной записью MSA, так и на тех серверах, которые используют данную MSA.

Затем откройте окно PowerShell для импорта модуля ActiveDirectory, который обеспечит доступ к командам AD. Модуль надо импортировать всегда при старте нового экземпляра PowerShell и в случае необходимости использования команд AD. Для импорта модуля введите команду

Import-Module ActiveDirectory

Теперь можно создать новую учетную запись MSA. Хорошо иметь стандарт именования учетных записей MSA и связывать их с определенным компьютером, используя имя целевого компьютера как составную часть этого имени. Сначала я создаю учетную запись MSA по имени msa_ts01_purgesvc, которую буду задействовать на сервере savdalts01:

New-ADServiceAccount -name msa_ts

01_purgesvc -enabled $true

Потом свяжу MSA с сервером savdalts01:

Add-ADComputerServiceAccount -identity

savdalts01‑serviceaccount msa_ts01

_purgesvc

Затем я регистрируюсь на данном сервере, который будет использовать эту учетную запись MSA, в моем случае на сервере savdalts01. После регистрации проверяю установку модуля AD для PowerShell. Далее открываю окно PowerShell и импортирую этот модуль AD и затем устанавливаю учетную запись MSA:

Install-ADServiceAccount –identity

msa_ts01_purgesvc

Теперь учетная запись msa_ts01_purgesvc$ (например, savilltechmsa_ts01_purgesvc) доступна для использования службами на сервере. Обратите внимание на знак доллара в конце имени и имя домена AD в начале.

Я использую оснастку Services в MMC (services.msc), ввожу имя учетной записи MSA и проверяю, являются ли оба поля пароля пустыми на вкладке Log On, как показано на экране 2, а затем запускаю службу. Учетная запись MSA теперь действует, и можно не заботиться о переустановке пароля.

Настройка службы для использования MSA

Можно предоставлять разрешения учетным записям MSA и добавлять учетные записи MSA в группы, как и любую другую учетную запись. Также можно пользоваться Active Directory Users and Computers, командами PowerShell типа Add-ADGroupMember или обычными утилитами управления группами. В случае необходимости переустановки пароля MSA воспользуйтесь командой

Reset-ADServiceAccountPassword –identity

[MSA name]

Впрочем, это редко бывает нужно.

Если больше не требуется использовать учетную запись, необходимо обновить службу (службы), используя MSA для регистрации как альтернативную учетную запись, а затем ввести команду

Remove-ADServiceAccount –identity

[MSA name]

Service Principal Name Delegation

Учетные записи MSA также позволяют устранить другой недостаток учетных записей служб — управление именами Kerberos Service Principal Name (SPN), которые регистрируются службами в AD. Клиенты осуществляют поиск по этим именам, чтобы найти учетную запись пользователя или компьютера, которые применяет служба для облегчения взаимной аутентификации. SPN являются частью объекта компьютера или пользователя.

Обычно эти SPN могут обновлять только администраторы доменов. Однако иногда служба может обновлять SPN, если она запускается с учетной записью Local System. Учетные записи MSA позволяют делегировать управление SPN администраторам службы после настройки MSA для делегирования. Воспользуйтесь командой:

Set-ADServiceAccount

-TrustedForDelegation

$true -identity [MSA name]

Она включает делегирование и позволяет делегату управлять этими SPN для объекта. Управление SPN для учетных записей MSA проще, однако домен должен работать в функциональном режиме Server 2008 R2; это означает, что все DC должны работать под Server 2008 R2. Если вы работаете в функциональном режиме Server 2008 R2, то теперь можно использовать автоматическое обновление SPN в следующих сценариях работы (когда не требуется обновление вручную):

  • переименование учетной записи компьютера;
  • изменение свойства dnshostname учетной записи компьютера;
  • изменение свойства addition­aldnshostname учетной записи компьютера;
  • изменение свойства additionalsam­accountname учетной записи компьютера.

Виртуальные учетные записи

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

Поскольку виртуальная учетная запись действует как самостоятельный клон встроенной учетной записи Network Service, при взаимодействии службы с другими ресурсами по сети она действует как учетная запись объекта «компьютер». Необходимо быть локальным администратором, чтобы управлять настройками виртуальных учетных записей.

Как и учетные записи MSA, виртуальные учетные записи доступны только на системах Server 2008 R2 и Windows 7; однако здесь нет требований к домену или схеме, и вы не создаете виртуальные учетные записи и не управляете ими. Для использования виртуальной учетной записи введите «NT SERVICE[service name]» во вкладке Log On службы и убедитесь, что оба поля пароля пустые.

Имя службы, которое вводится как имя учетной записи, должно точно соответствовать имени службы (но не длинному отображаемому имени). На экране 3 показан настроенный удаленный отладчик Visual Studio (VS) для использования с виртуальной учетной записью под именем учетной записи NT Servicemsvsmon90 с пустыми паролями.

Настройка удаленного отладчика Visual Studio на использование виртуальной учетной записи

При нажатии на кнопку Apply поля паролей автоматически заполняются. Можно получить короткое имя службы разными способами: просмотрите раздел HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices; запустите команду SC QUERY. Или самый простой способ — просто посмотрите значение параметра Service на вкладке General в свойствах службы.

Поддержим MSA

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

Многие приложения и функции поддерживают учетные записи MSA, в том числе идентификация пула приложений IIS 7.5. Надеюсь, что в Windows 8 учетные записи MSA будут поддерживать многокомпьютерные сценарии для работы кластеров и NLB. В любом случае учетные записи MSA — отличная функция, снимающая много проблем, связанных с учетными записями служб.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security и Messaging MCSE для Windows Server 2003 и звание MVP  

Установка команд PowerShell в Active Directory

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF