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

Различие между MSA и gMSA

Жан де Клерк

Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft

Вопрос: В чем состоит различие между управляемыми учетными записями служб (MSA) и групповыми управляемыми учетными записями служб (gMSA)?

Ответ: MSA – это особый тип доменных учетных записей, поддерживаемый в Active Directory (AD), начиная с Windows Server 2008 R2. MSA позволяет решать проблемы управления паролями, возникающие у администраторов при настройке особых доменных учетных записей для аутентификации службы. Администраторы обычно предпочитают создавать особые учетные записи, позволяющие более точно задавать привилегии приложения, а не использовать встроенные высокопривилегированные локальные учетные записи (например, локальная система Local System, локальная служба Local Service, сетевая служба Network Service). Однако, в отличие от встроенных высокопривилегированных локальных учетных записей, для особых учетных записей нет автоматического управления паролями. Поэтому при использовании особых учетных записей приходится вручную управлять их паролями или создавать специальное решение для управления ими.

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

В Windows Server 2012 групповые управляемые учетные записи служб (gMSA) решают эту проблему для служб балансировки нагрузки в веб-фермах. К сожалению, на момент написания этой статьи они пока не работают для кластерных служб в кластере с обходом отказов.

В основе gMSA лежит новая служба распространения ключей Microsoft Key Distribution Service, запускаемая на каждом контроллере домена Server 2012. Эта служба гарантирует, что пароль одной учетной записи службы, используемый экземплярами службы веб-фермы, синхронизируется между разными экземплярами. Использование gMSA требует обновления схемы AD до Server 2012. Кроме того, на одном или нескольких контроллерах домена Server 2012 должна быть запущена служба Microsoft Key Distribution Service. Служба автоматически устанавливается на каждый контроллер домена, но по умолчанию ее запуск осуществляется вручную. Следует отметить, что только службы, работающие под управлением Server 2012, могут использовать gMSA. Создавать и администрировать gMSA можно с помощью команд Windows PowerShell. Подробнее о gMSA рассказано в статье Microsoft «Getting Started with Group Managed Service Accounts» (http://technet.microsoft.com/en-us/library/jj128431).

 

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

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