Управляемые учетные записи служб

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