Ситуации, когда службы и приложения во всей компании работают от имени одной учётной записи с паролём 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:

 

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

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

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

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

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

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

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

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

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

Get-KDSRootKey

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

 Add-KDSRootKey –EffectiveImmediately

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

Add-KDSRootKey –EffectiveImmediately ((get-date).addhours(-10))

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

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

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

New-ADServiceAccount -Name %gMSAname% -DNSHostName %gMSAfqdn% -PrincipalsAllowedToRetrieveManagedPassword %SecurityPrincipals%

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

Test-ADServiceAccount

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

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

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

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

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

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

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

 

Что касается 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

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