Group Managed Service Accounts в Windows Server

ManagedServicesСитуации, когда службы и приложения во всей компании работают от имени одной учётной записи с паролём Qwerty123, который, к тому же, знают все эникейщики “на всякий случай”, к сожалению, встречаются до сих пор.

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

MSA, кстати, были переименованы в sMSA – Standalone Manager Service Accounts.

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

Преимущества MSA/gMSA :

  • Надёжный пароль из 120 знаков;
  • Пароль не известен никому;
  • Пароль автоматически меняется по расписанию (по-умолчанию раз в 30 дней);
  • Смена пароля “подхватывается” приложениями которые используют gMSA автоматически;

Обратите внимание, командленты которые раньше использовались для MSA в 2012 используются по-умолчанию для gMSA.

Работа MSA в Windows Server 2008R2 была во многом похожа на “классическую” работу компьютерных учётных записей, что делало применение MSA весьма ограниченным.

Обратите внимание,  MSA/gMSA по-умолчанию являются членами группы Domain Computers:

Screenshot at Mar 16 12-17-32

 

Основные ограничения заключались в том, что MSA не поддерживали SQL и Task Scheduler и один аккаунт мог быть использован только на одном сервере.

Group Managed Service Accounts в Windows Server 2012 могут быть использованы на произвольном количестве серверов, и могут быть использованы для Task Scheduler.

Достигается это, кстати за счёт использования в WS2012 Key Distribution Service для управления паролями gMSA. Этот момент важен, поэтому остановлюсь на нем подробнее.

Очевидно, что сервера, использующие gMSA будут обращаться к контроллерам домена по вопросам паролей gMSA.

Контроллеры домена будут отвечать только тем серверам, которым мы разрешили использование конкретных gMSA.

Эти сервера перечислены в атрибуте msDS-GroupMSAMembership аккаунта:

Screenshot at Mar 16 11-58-24

Как я уже говорил выше, для MSA/gMSA пароли генерируются автоматически службой KDS.

После инициации смены пароля, все участники KDC в организации генерируют пароль по такому же алгоритму.

Для этого, на всех участниках KDS должен использоваться один и тот же Root Key ID,возможно в вашей инфраструктуре он уже сгенерирован и синхронизирован, проверить можно так:

Screenshot at Mar 16 12-36-10

Если ключ нужно создать, делается это так:

По-умолчанию даётся 10 часов на репликацию ключа между всеми участниками KDS, но в лабе где репликация отсутствует можно 10 часов тайм-аута убрать (в продакшене не поленитесь проверить результат репликации):

После того как ключ создан и распространён, нужно создать группы участников для каждого gMSA – с помощью групп давать доступ намного удобнее, чем добавлять сервера в каждую gMSA.

Я, для примера, сделал такую группу:

Screenshot at Mar 16 12-42-38

Теперь можно приступить к созданию gMSA:

На сервере где gMSA будет использоваться можно проверить доступность для него gMSA:

Такой результат будет на сервере для которого использование gMSA не разрешено:

Screenshot at Mar 16 13-01-04

… а такой, для которого разрешено (является членом ранее созданной группы gMSA_users):

Screenshot at Mar 16 13-01-33

Как видите, управление gMSA это скорее административная чем техническая задача.

Учитывая что командлеты PowerShell для управления gMSA (по непонятной причине) не так хороши, как для управления другими Security Principals, а GUI по-умолчанию не даёт возможности управления, единственным вариантом остаётся использование стороннего GUI, например от CJWDEV – http://www.cjwdev.com/Software/MSAGUI/Info.html

Утилита бесплатная, удобная и умеет все, что нужно и значительно ускоряет работу оператора (администратора, аудитора и т.д.) MSA/gMSA:

Screenshot at Mar 16 13-24-55

В сервисах, где gMSA  будет использоваться добавить его очень просто, нужно ввести Domain-Level Logon Name, в конце добавить знак $ (как у стандартного компьютерного аккаунта) и не вводить пароль – %domain%\%gMSAname%$

Вот несколько примеров (в Object Types не всегда включены Service Accounts по-умолчанию):

Screenshot at Mar 16 13-39-19 Screenshot at Mar 16 13-40-43 Screenshot at Mar 16 13-41-54 Screenshot at Mar 16 13-43-18 Screenshot at Mar 16 13-44-02

 

Что касается SQL, то до сих пор MSA/gMSA остаётся рабочим, но не поддерживаемым официально вариантом.

По каждому конкретному продукту поддержку им MSA/gMSA лучше уточнять в документации, и проверять в лабе.

Также обратите внимание, что для использование gMSA необходим уровень леса 2012.

Полезные материалы по теме:

https://technet.microsoft.com/en-us/library/jj128431.aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/aa378170(v=vs.85).aspx

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.