технология управлявани записи за обслужване (Сметки за управлявани услуги - MSA) е представен за първи път в Windows Server 2008 R2 и е предназначен за автоматично управление (промяна) пароли за акаунти за услуга (услуга). Използвайки механизма за управлявани акаунти на услуги, можете значително да намалите риска от компрометиране на системните акаунти, под които се стартират системните услуги (не е тайна, че има голям брой помощни програми, които могат да извличат локални потребителски пароли от LSASS).
За MSA акаунти се генерира парола от 240 знака, от които половината са английски букви, другата половина са сервизни знаци. Паролата за такъв акаунт се променя автоматично (по подразбиране на всеки 30 дни) и не се съхранява в локалната система
Основният недостатък на MSA е възможността да се използва такъв запис на услуга само на един компютър. Това означава, че MSA услуги акаунти не могат да работят с клъстерирани и NLB услуги (уеб ферми), които работят на няколко сървъра едновременно и използват един и същ акаунт и парола..
За да преодолее този недостатък, Microsoft в Windows Server 2012 добави функционалността на групови акаунти за управление на услуги (gMSA - Групови управлявани акаунти за услуги). Такива акаунти могат да се използват едновременно на няколко сървъра, така че всички служебни инстанции да използват един и същ акаунт, например в услугата за балансиране на натоварването (NLB), клъстерни услуги и т.н..
Изисквания за GMSA:
За да се възползвате от възможностите на gMSA, инфраструктурата трябва да отговаря на следните изисквания:
- Ниво на схема на AD - Windows Server 2012 (как да го актуализирате е описано тук).
- Контролер на домейни на Windows Server 2012 (и по-горе) с услугата за разпространение на ключове на Microsoft - това е услугата, отговорна за генерирането на пароли
- Модул PowerShell за управление на Active Directory
- Като клиенти могат да се използват Windows Server 2012/2012 R2 и Windows 8 / 8.1
- Услугата, използваща gMSA, трябва да е съвместима с този тип акаунти (трябва да бъде посочена в документацията). В момента поддръжката на gMSA: SQL Server 2008 R2 SP1, 2012; IIS; AD LDS; Обмен 2010/2013
Създайте KDS ключ
Преди да започнете да създавате gMSA акаунт, трябва да извършите еднократна операция за създаване на корен ключ KDS (корен ключ KDS). За да направите това, изпълнете командата на контролера на домейна с права на администратор (Microsoft Key Services Services трябва да бъде инсталиран и активиран):
Add-KdsRootKey -EffectiveImmediate
В този случай ключът ще бъде създаден и достъпен след 10 часа, след като репликацията приключи.
съвет. В тестова среда можете да използвате командата за незабавна употреба:Add-KdsRootKey -EffectiveTime ((дата на получаване) .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 потребители и компютри) и да проверите дали тя е в контейнера (OU) Управлявани акаунти за услуги появи се съветващ акаунт (по подразбиране този контейнер не се показва, за да го видите, трябва да отидете в менюто изглед опция за включване на щрака Разширени функции) 
Инсталирайте gMSA на сървъра
Свържете модула Powershell, за да поддържате средата на Active Directory:
Add-WindowsFeature RSAT-AD-PowerShell
След това трябва да инсталираме управляван акаунт на сървърите, на които ще се използва (от под този акаунт в бъдеще ще стартира определена услуга). На първо място, трябва да проверите дали на този сървър е разрешено да получава паролата за gMSA акаунт от Active Directory. За да направите това, неговият акаунт трябва да бъде в групата на домейните, посочена по време на създаването (в нашия случай gmsa1Group). Инсталирайте записа на gmsa1 на този сървър:
Инсталиране-ADServiceAccount -Identity gmsa1
Можете да проверите дали акаунтът за групова услуга е инсталиран правилно, като направите това (за Windows PowerShell 4.0):
Test-ADServiceAccount gmsa1
Ако командата върне True - всичко е конфигурирано правилно.
Освен това в свойствата на услугата посочваме, че тя ще бъде стартирана под gMSA акаунта. За да направите това, в раздела Влезте в системата трябва да изберете Този акаунт и посочете името на услугата. Символът $ трябва да бъде посочен в края на името, не се изисква парола. След като запазите промените, услугата трябва да се рестартира.
Сервизният акаунт автоматично ще бъде предоставен Вход като права на услуга.
Фина настройка на gMSA
Честотата на промяна на паролата може да бъде променена (30 дни по подразбиране):
Set-ADServiceAccount gmsa1-ManagedPasswordIntervalInDays 60
Акаунтът на gMSA може да се използва и в задачи за планиране. Тънкият нюанс е, че задачата може да бъде конфигурирана само чрез PowerShell.
$ action = New-ScheduledTaskAction „c: \ script \ backup.cmd“ $ alarm = Нов-ScheduledTaskTrigger -At 21:00 -Daily $ Director = New-ScheduledTaskPrincipal -UserID winitpro \ gmsa1 $ -LogonType PasswordRegister-ScheduledTask BackupD-BackupDAk BackupD действие -Тригер $ тригер -Принципна $ главница
Аргументът „-LogonType Password“ означава, че паролата за този gMSA акаунт ще бъде получена от контролера на домейна.
забележка. Трябва да бъде предоставен GMSA акаунт "Влезте като пакетна работа"
