Managed Service Accounts в Windows Server 2016

Управляемые учётные записи сервисов - Group Managed Service Accounts в Windows Server 2016

Привет.
 
Ранее я написал обзорную статью про MSA в Windows Server 2008 R2. Теперь, так как вышли новые версии платформы Windows Server, надо добавлять. Ведь есть что, и очень даже интересное. Это – обновлённая версия статьи; оригинальная была написана по Windows Server 2012 RTM, данная уже учитывает существование и Windows Server 2012 R2, и Windows Server 2016.
 

Работаем с Managed Service Accounts

  • Зачем нужны MSA
  • Функционал MSA – обычных MSA и современных gMSA
  • Подготавливаем лес Active Directory к работе с MSA и gMSA
  • Включаем и настраиваем Key Distribution Services
  • Создаём gMSA на Windows Server 2012 и выше
  • Дополнительные возможности

 
Приступим.
 

Зачем нужны MSA

Изначально в Windows NT такого понятия, как “специальный вид учётной записи для приложения-сервиса” не существовало. Была системная учётка SYSTEM, которая олицетворяла собой Одина, Будду, Ктулху и прочих интересных личностей в одном флаконе. Эта учётная запись была неявно включена в BUILTIN\Administrators и обладала всеми правами на системе, которые могут быть – ну а если чем-то не обладала, так от её лица можно было сделать take ownership на любом объекте, имеющем ACL, и в результате всё ж обладать всеми правами. От этой учётки работали все системные процессы, а также запускались сервисы – но подчеркну, сделана она была не именно для запуска сервисов, а чтобы олицетворять “всю систему”.
 
Вы могли запускать сервисы как от неё, так и от обычной учётной записи пользователя – это менялось в настройках примерно так же, как меняется сейчас:
 

 
Да и сервисы свои вы тоже могли создавать, для этого была специальная утилитка srvany, входившая в состав Resource Kit.
 
Вроде как всё хорошо, но на самом деле – проблемы.
 
Первая и очевидная состояла в небезопасности выдачи всех-всех-всех прав в системе любому приложению, которому надо было запускаться на фоне. Допустим, берём сервис DHCP Client. Что ему нужно от системы? Возможность доступа к сети, притом небольшую совсем, да возможность записи конфигурации в некоторые ветки реестра (где хранятся настройки сетевых интерфейсов). Всё, что он делает – обменивается несколькими видами ethernet-кадров, да пишет Надо ли ему доступ ко всем данным на всех дисках? К созданию пользователей и смене прав? К раздаче системных привилегий типа “shut down from remote system”? Нет конечно, зачем. Но всё это выдаётся, если работаешь от SYSTEM.
 
Вторая состояла в том, что даже если заводишь специальную учётную запись пользователя, от имени которой запускаешь этот сервис, то возникает новая пачка проблем, в том числе:
 

  • Надо старательно выдать этой учётной записи только минимально нужные для этой операции права и запретить изначально разрешаемые ей, но не нужные в данном сценарии использования (например, запретить сетевой вход);
  • Надо периодически менять у этой учётной записи пароль, а также сделать его стойким;
  • Пароль к этой учётной записи будет храниться в системе в виде открытого текста (надо ж при запуске сервиса сымитировать log on as a service, поэтому надо предоставить связку логин-пароль в исходном варианте);
  • Пароль может использоваться в нескольких местах (например, когда данная служба на нескольких серверах работает), и доступ к нему возможен на любом из этих серверов от любой учётной записи с правами локального администратора;

 
Всё это неудобно, небезопасно, заставляет тратить лишнее время, и зачастую сводится к “разово сделаем пароль, поставим галочку, чтобы мозг не конопатил, выдадим права локального админа этой учётке и забудем”.
 
Managed Service Accounts – MSA (я буду говорить уже именно про новые, gMSA, появившиеся в Windows Server 2012, новая буква g – это Group) – позволяют решить все эти проблемы.

Функционал MSA – обычных MSA и современных gMSA

Managed Service Accounts будут различаться – самый первый вариант, появившийся в Windows Server 2008 R2 (про него предыдущая статья про MSA), будет уметь работать только с одним сервером, и, так как в следующей же операционной системе, Windows Server 2012, появились gMSA, лишённые этого ограничения, речь пойдёт сразу же про них. Называть я их буду MSA, без буквы g, так проще.
 
Итак, как MSA решают все вышеперечисленные вопросы?
 

  • Проблема с минимизацией прав упростилась – MSA – это не пользовательская учётка, выкорчёвывать лишние полномочия не нужно, изначально на локальной системе никаких прав у MSA нет, громоздкий профиль, как пользователь, при логине, она тоже не создаёт. Вы просто добавляете её в нужные группы, чтобы предоставить соответствующие задаче права и полномочия.
  • Периодичность смены пароля у MSA задаётся через групповые политики и проводится автоматически.
  • Пароль у MSA генерится очень стойкий – 240 символов, половина латинские буквы, половина – цифры. Такой пароль нет смысла подбирать bruteforce’ом, потому что это займёт времени больше, чем линейный перебор всех значений хэша.
  • При использовании MSA на нескольких серверах проблемы со сменой пароля также нет – всё делается автоматически.

 
Из дополнительных преимуществ – MSA использует только Kerberos, поэтому хоть NTLM дополнительно обезопасить можно, в случае с MSA это просто не нужно – проблем с безопасностью LM, NTLMv1 и NTLMv2 у этих учёток нет.
 
В результате получается очень удобный вид учётных записей для упрощения обслуживания и улучшения ситуации с безопасностью.
 
Давайте внедрять.
 

Подготавливаем лес Active Directory к работе с MSA и gMSA

Домиком для всех видов MSA – обычных, которые msDS-ManagedServiceAccount, и новых, которые msDS-GroupManagedServiceAccount будет контейнер CN=Managed Service Accounts,DC=контекст домена, находящийся в корне domain partition вашего домена:
 

 
Для работы MSA надо будет также включить специальный сервис на выбранном хосте, который будет отвечать за централизованное управление паролями. Этот сервис будет называться KDS – Key Distribution Services.
 
Необходимые для работы этого сервиса объекты в Active Directory будут создаваться либо сразу, когда поднимается новый лес, либо когда идёт /forestprep при установке первого DC на базе Windows Server 2012. Проверить, что данные операции на уровне леса прошли удачно, можно отследить по трекеру Forest Updates – зайдите в ADSI-редактор и откройте вот такой контейнер:
 

 
В нём должны (если всё хорошо) быть GUID’ы выполненных операций, 4 штуки:

  • {defc28cd-6cb6-4479-8bcb-aabfb41e9713}
  • {d6bd96d4-e66b-4a38-9c6b-e976ff58c56d}
  • {bb8efc40-3090-4fa2-8a3f-7cd1d380e695}
  • {2d6abe1b-4326-489e-920c-76d5337d2dc5}

 
Там, конечно, много всяких других, благо с 2000го Windows Server в Active Directory изменения есть, но нам надо, чтобы были все эти 4 – это будет обозначать, что дефолтные объекты для работы Key Distribution Services были созданы.
 
Дополнительно можно глянуть рядом расположенный объект, CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=atraining,DC=z. Он будет содержать атрибут revision – нам надо, чтобы этот атрибут был как минимум 11.
 

 
Если всё ОК, то продолжаем.

Включаем и настраиваем Key Distribution Services

Начиная с Windows Server 2012, в Active Directory появляется новый контейнер для хранения данных, находящийся в лесном разделе Configuration:
 

 
Обращающиеся к нему сервисы работают на всех DC под управлением Windows Server 2012 и старше, технически выглядят как вызываемые из библиотеки kdssvc.dll функции по управлению ключевой информацией. Эти функции и будут составлять собой Microsoft Key Distribution Services.
 
Внутри контейнера CN=Group Key Distribution Service есть два других – один для общих настроек Microsoft Key Distribution Services, называется Server Configuration:
 

 
а второй – для самих ключей, он будет называться Master Root Keys:
 

 
Что в них?

Server Configuration

Здесь будет находиться единственный объект с названием Group Key Distribution Service Server Configuration, класса msKds-ProvServerConfiguration. Из интересного в нём разве что атрибут msKds-Version, равный единице со времён Windows Server 2012 – двойка пока нигде, включая Windows Server 2016 TP5, не обнаружена.
 

 

Master Root Keys

Здесь будут находиться сами ключи. Идентифицироваться они будут по CN, равному GUID ключа, класс объекта у них будет msKds-ProvRootKey, а интересных атрибутов у них будет много:
 

Атрибуты Master Root KeyАтрибуты Master Root Key
(кликните для увеличения до 400 px на 455 px)
Учебный центр Advanced Traininginfo@atraining.ru

 
Два параметра msKds-CreateTime и msKds-UseStartTime будут содержать время создания объекта и время начала возможности его использования. Логика такова, что после создания объекта ему даётся время на то, чтобы среплицироваться на все DC в лесу. Это время стандартно и составляет 10 часов. До наступления msKds-UseStartTime данный ключ не будет использоваться, DC просто не будут находить его по запросам со стороны функций, работающих с gMSA.
 
Криптографические параметры будут задавать длины закрытого (msKds-PrivateKeyLength) и открытого (msKds-PublicKeyLength) ключа RSA, алгоритм совместной генерации общего секретного ключа (msKds-SecretAgreementAlgorithmID, в нашем случае DH) и сами блобы этих криптографических параметров. В атрибуте msKds-Version будет версия – такая же, как и в предыдущем объекте, а в msKds-KDFAlgorithmID будет название KDF-функции – сейчас там значение SP800_108_CTR_HMAC, пока оно стандартное, но API допускает и возможность других значений из подмножества поддерживаемых CNG KDF-функций (например, SP80056A_CONCAT, или PBKDF2). Посмотреть фактическую поддержку KDF на хосте (контроллере домена Active Directory или просто Windows-машине – неважно), можно командой show crypto algo:
 

Просмотр списка KDFПросмотр списка KDF
(кликните для увеличения до 979 px на 599 px)
Учебный центр Advanced Traininginfo@atraining.ru

 
KDF, если что – это аббревиатура от Key Derivation Function, т.е. способа генерации ключа нужной длины из не-криптографического материала (например, из пароля).
 
Эти параметры можно также просмотреть через командлет Get-KdsConfiguration:
 

 
Он, в общем-то, эти же атрибуты и выводит. Парный к нему командлет, Set-KdsConfiguration, позволит изменять параметры – алгоритмы, длины ключей, и всё остальное. Например, можно сменить стандартную KFD-функцию на другую:
 
Set-KdsConfiguration -KdfAlgorithm "PBKDF2"
 
По идее, можно ещё сменить сам алгоритм генерации ключевого материала со старого DH на ECDH, или хотя бы увеличить количество бит у DH с 2048 до 4096, но только вот это сейчас (в Windows Server 2016 TP5) не работает по неизвестной причине – надеюсь, к RTM доделают. Меняется т.е. пока только KDF-функция – список доступных вы можете просмотреть через ATcmd, пример есть выше.
 
Давайте теперь создадим ключ.

Создание нового Root Key

Это несложно – используется командлет Add-KdsRootKey, из параметров у которого только разве что время начала действия ключа. Самый простой способ – создать так:
 
Add-KdsRootKey -EffectiveImmediately
 
Тогда ключ создастся и начнётся отсчёт 10 часов – для подстраховки, чтобы среплицировалось во всём лесу Active Directory. Если не хотите ждать – не вопрос. Можно сделать хитро – сгенерить ключ с “минус десятью часами начала работы”:
 
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
 
В этом случае ключ будет работоспособен сразу же. После создания Вы увидите GUID ключа:
 

 
Можно зайти в контейнер с ключами и посмотреть его параметры – опять же, из интересного там пока что будет разве что сервер, на котором Вы создали этот ключ – в атрибуте msKds-DomainID.
 
Теперь можно и gMSA создать.

Создаём gMSA

Для начала, выберем хост, на котором мы создадим gMSA. Хост должен быть строго на Windows Server 2012 и выше и обладать установленным .NET Framework 4.5 (это будет само собой, если там развёрнуты службы AD DS).
 
Создание будет несложным – используется тот же командлет, что и раньше:
 
New-ADServiceAccount
 
В качестве обязательных параметров будет имя, которое можно указать сразу после командлета (например, msa1):
 
New-ADServiceAccount msa1
 
И надо выбрать – создаём ли “обычный” MSA, привязанный к одному серверу – тогда это выглядит так:
 
New-ADServiceAccount msa2 -RestrictToSingleComputer
 
Или создаём именно gMSA, пригодную для использования в кластерах, и тогда надо указать FQDN хоста, на котором мы заводили KDS-ключ (например, server-a.atraining.z):
 
New-ADServiceAccount msa1 -DNSHostName server-a.atraining.z
 
А после – указать все те учётки computer’ов, которые смогут получать доступ к security-информации (паролю, например) новорожденной gMSA, задав их перечень в параметре -PrincipalsAllowedToRetrieveManagedPassword (например, разрешим учётке DC1):
 
New-ADServiceAccount msa1 -DNSHostName server-a.atraining.z -PrincipalsAllowedToRetrieveManagedPassword DC1$
 
Можно ещё добавить в конец -Enabled $true, и тогда будет полный вариант.
 
Вот так выглядят созданные учётки (я сделал msa1 нормальной, gMSA, а msa2 – ‘устаревшей’ MSA, чтобы было видно, что в зависимости от параметров командлета New-ADServiceAccount создаются разные типы объектов Active Directory):
 

MSA и gMSAMSA и gMSA
(кликните для увеличения до 745 px на 530 px)
Учебный центр Advanced Traininginfo@atraining.ru

 
Дальнейшее использование простое – надо пойти на хосты, на которых планируется использование этой gMSA, и выполнить на них Install-ADServiceAccount. Всё идентично обычному MSA, только можно установить больше чем на 1 хост.

Дополнительные возможности

Вы можете задать криптоалгоритмы, используемые для тикетов Kerberos, выдаваемых этой MSA. Это делается, используя параметр -KerberosEncryptionTypes. Задавать можно несколько, выбор есть из DES, RC4, AES128 и AES256. Например, так:
 
New-ADServiceAccount msa1 -KerberosEncryptionType AES128|AES256
 
Можно (и нужно) явно задать промежуток смены пароля для gMSA – теперь же нет явного “хоста-монопольного-владельца-MSA”, от настроек которого это было зависимо:
 
New-ADServiceAccount msa1 -ManagedPasswordIntervalInDays 60
 
60, как понятно – это в днях.
 
Интересный момент – Вы не сможете получить полный доступ к вкладке Attributes у gMSA, если подключаетесь по обычному LDAP. Только если по LDAPS. Ну, это тема отдельного разговора о безопасности Active Directory. Намекну, что сможете через ATcmd.exe :).

В качестве заключения

Очередная технология, ощутимо поднимающая безопасность и упрощающая управление сервисами стала только лучше. Категорически рекомендуется к использованию – более того, ранее заведённые MSA проще переделать как gMSA – чтобы был единый тип объектов, а не два разных. Конечно, это потребует, чтобы в лесу Active Directory были как минимум NT 6.2-системы, но плюсы очевидны – проще делать gMSA, привязанные к 1й машине, чем специальный устаревший тип объектов с неполным функционалом.
 
Удач!

Возможно, вам будет также интересно почитать эти статьи с нашей Knowledge Base

  • Dmitry

    Руслан день добрый!
    Скрины куда то делись, можно восстановить ?
    Спасибо!

  • Скрины появились, текст тоже дописал чуток и актуализировал.