технологія керованих службових записів (Managed Service Accounts - MSA) Вперше була представлена в Windows Server 2008 R2 і призначена для автоматичного управління (зміни) паролів службових (сервісних) облікових записів. Завдяки використанню механізму Managed Service Accounts можна істотно знизити ризик компрометації системних облікових записів, з-під яких запущені системні служби (не секрет, що існує велика кількість утиліт, що дозволяють отримати паролі локальних користувачів з LSASS).
Для облікових записів MSA генерується пароль довжиною 240 символів, з яких половина - англійські букви, інша половина - службові символи. Пароль такого облікового запису змінюється автоматично (за замовчуванням кожні 30 днів) і не зберігається на локальній системі
Основним недоліком MSA є можливість використання подібної службової записи тільки на одному комп'ютері. Це означає, що службові облікові записи MSA не можуть працювати з кластерними і NLB службами (веб-ферми), які працюють одночасно на декількох серверах і використовують один обліковий запис і пароль.
Для подолання зазначеного недоліку Microsoft в Windows Server 2012 додала функціонал групових керованих облікових записів служб (gMSA - Group Managed Service Accounts). Такі облікові записи можна одночасно використовувати на декількох серверах, щоб всі екземпляри служби використовували одну і ту ж обліковий запис, наприклад в службі балансування навантаження (NLB), кластерних службах тощо.
Вимоги gMSA:
Щоб скористатися можливостями gMSA, потрібно, щоб інфраструктура відповідала наступним вимогам:
- Рівень схеми AD - Windows Server 2012 (як її оновити описано тут).
- Контролер домену Windows Server 2012 (і вище) зі службою Microsoft Key Distribution Service (служба поширення ключів) - саме це служба відповідає за генерацію паролів
- PowerShell модуль для управління Active Directory
- В якості клієнтів можуть використовуватися Windows Server 2012/2012 R2 і Windows 8 / 8.1
- Служба, яка використовує gMSA повинна бути сумісна з цим типом акаунтів (повинно бути вказано в документації). На даний момент gMSA підтримують: SQL Server 2008 R2 SP1, 2012; IIS; AD LDS; Exchange 2010/2013
Створюємо KDS ключ
Перш, ніж приступити до створення облікового запису gMSA, необхідно виконати разову операцію зі створення кореневого ключа KDS (KDS root key). Для цього на контролері домену з правами адміністратора виконайте команду (служба Microsoft Key Distribution Services повинна бути встановлена і включена):
Add-KdsRootKey -EffectiveImmediately
У цьому випадку ключ буде створено і доступний через 10 годин, після закінчення реплікації.
Порада. У тестовій середовищі для негайного використання можна скористатися командою:Add-KdsRootKey -EffectiveTime ((get-date) .addhours (-10))
Перевіримо, що кореневої ключ KDS створився успішно:
Get-KdsRootKey
Створюємо обліковий запис gMSA
Створимо новий обліковий запис gMSA командою:
New-ADServiceAccount -name gmsa1 -DNSHostName dc1.winitpro.ru -PrincipalsAllowedToRetrieveManagedPassword "gmsa1Group"
де, gmsa1 - ім'я створюваної облікового запису gMSA
dc1.winitpro.ru - ім'я DNS сервера
gmsa1Group - група Active Directory, в яку включені всі системи, які будуть використовувати цю групову обліковий запис (група повинна бути створена попередньо)
Після виконання команди потрібно відкрити консоль ADUC (Active Directory Users and Computers) і перевірити, що в контейнері (OU) Managed Service Accounts з'явилася радна обліковий запис (за замовчуванням цей контейнер не відображається, щоб його побачити, потрібно в меню View оснащення включити опцію Advanced Features) 
Установка gMSA на сервері
Підключимо модуль Powershell для підтримки середовища Active Directory:
Add-WindowsFeature RSAT-AD-PowerShell
Далі нам потрібно встановити керовану обліковий запис на сервера, на яких вона буде використовуватися (з-під цієї учеткі надалі буде запущений якийсь сервіс). В першу чергу потрібно перевірити, що цього сервера дозволено отримувати пароль облікового запису gMSA з Active Directory. Для цього його обліковий запис повинен складатися у зазначеній при створенні доменної групі (в нашому випадку gmsa1Group). Встановимо запис gmsa1 на даному сервері:
Install-ADServiceAccount -Identity gmsa1
Перевірити, що облікова групова сервісний запис встановлена коректно можна так (для Windows PowerShell 4.0):
Test-ADServiceAccount gmsa1
Якщо команда поверне True - все налаштовано правильно.
Далі у властивостях служби вкажемо, що вона буде запускатися їх під облікового запису gMSA. Для цього на вкладці Log on потрібно вибрати This account і вказати ім'я сервісної облікового запису. В кінці імені обов'язково вказується символ $, пароль вказувати не потрібно. Після збереження змін службу потрібно перезапустити.
Сервісної облікового запису автоматично будуть надані права "Log On As a Service".
"Тонка" настройка gMSA
Періодичність зміни пароля можна змінити (за замовчуванням 30 днів):
Set-ADServiceAccount gmsa1-ManagedPasswordIntervalInDays 60
Обліковий запис gMSA можна використовувати і в завданнях планувальника. Тонкий нюанс в тому, що завдання можна налаштувати тільки через PowerShell.
$ Action = New-ScheduledTaskAction "c: \ script \ backup.cmd" $ trigger = New-ScheduledTaskTrigger -At 21:00 -Daily $ principal = New-ScheduledTaskPrincipal -UserID winitpro \ gmsa1 $ -LogonType PasswordRegister-ScheduledTask BackupDB -Action $ action -Trigger $ trigger -Principal $ principal
Аргумент "-LogonType Password" означає, що пароль для цієї gMSA облікового запису буде отримано з контролера домену.
Примітка. Необхідно надати облікового запису gMSA права "Log on as a batch job"
