технологія керованих службових записів (Керовані рахунки послуг – MSA) Вперше була представлена ​​в Windows Server 2008 R2 і призначена для автоматичного управління (зміни) паролів службових (сервісних) облікових записів. Завдяки використанню механізму Managed Service Accounts можна істотно знизити ризик компрометації системних облікових записів, з-під яких запущені системні служби (не секрет, що існує велика кількість утиліт, що дозволяють отримати паролі локальних користувачів з LSASS).

Для облікових записів MSA генерується пароль довжиною 240 символів, з яких половина – англійські букви, інша половина – службові символи. Пароль такого облікового запису змінюється автоматично (за замовчуванням кожні 30 днів) і не зберігається на локальній системі

Основним недоліком MSA є можливість використання подібної службової записи тільки на одному комп’ютері. Це означає, що службові облікові записи MSA не можуть працювати з кластерними і NLB службами (веб-ферми), які працюють одночасно на декількох серверах і використовують один обліковий запис і пароль.

Для подолання зазначеного недоліку Microsoft в Windows Server 2012 додала функціонал групових керованих облікових записів служб (gMSA – Групові керовані облікові записи послуг). Такі облікові записи можна одночасно використовувати на декількох серверах, щоб всі екземпляри служби використовували одну і ту ж обліковий запис, наприклад в службі балансування навантаження (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

Створюємо кореневий ключ для служби Microsoft Key Distribution Services

Створюємо обліковий запис 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) Керовані рахунки послуг з’явилася радна обліковий запис (за замовчуванням цей контейнер не відображається, щоб його побачити, потрібно в меню Переглянути оснащення включити опцію Розширені функції) Контейнер Керовані облікові записи служб в Active Directory

Установка 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 – все налаштовано правильно.

Install-ADServiceAccount - установка gMSA облікового запису на сервері

Далі у властивостях служби вкажемо, що вона буде запускатися їх під облікового запису gMSA. Для цього на вкладці Залогінитися потрібно вибрати Цей рахунок і вказати ім’я сервісної облікового запису. В кінці імені обов’язково вказується символ $, пароль вказувати не потрібно. Після збереження змін службу потрібно перезапустити.

Налаштування служби на запуск від імені груповий сервісної облікового запису

Сервісної облікового запису автоматично будуть надані права «Log On As a Service».

«Тонка» настроювання gMSA

Періодичність зміни пароля можна змінити (за замовчуванням 30 днів):

Set-ADServiceAccount gmsa1-ManagedPasswordIntervalInDays 60

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

$action = New-ScheduledTaskAction  “c:scriptbackup.cmd”
$trigger = New-ScheduledTaskTrigger -At 21:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID winitprogmsa1$ -LogonType PasswordRegister-ScheduledTask BackupDB –Action $action –Trigger $trigger –Principal $principal

Аргумент «-LogonType Password» означає, що пароль для цієї gMSA облікового запису буде отримано з контролера домену.

Примітка. Необхідно надати облікового запису gMSA права «Увійдіть як пакетне завдання»

Leave a Reply

Your email address will not be published. Required fields are marked *