Используем сервисные учетные записи AD (MSA и gMSA) для запуска сервисов и заданий Windows

05.03.2024

Active Directory, PowerShell, Windows Server 2019, Windows Server 2022

Для безопасного запуска служб, приложений и заданий планировщика на серверах и рабочих станциях домена Active Directory можно использовать управляемые учетные записи служб (Managed Service Accounts – MSA). MSA – это специальный тип учетной записи, для которых AD генерирует сложный пароль (240 символов) и автоматически меняет его каждые 30 дней. Интерактивный вход под MSA не возможен, пароль не известен никому и не хранится в локальной системе (нельзя извлечь пароль из системного процесса LSASS с помощью mimikatz или аналогичных утилит). Таким образом для запуска служб или заданий, вам не нужно создавать отдельных сервисных пользователей в AD и управлять их паролями

В этой статье, мы покажем, как создать сервисные учетные записи MSA и использовать их для запуска служб и сервисов на серверах.

Содержание:

Создать корневой ключ Key Distribution Services
Создать управляемую учётную запись MSA в Active Directory
Создать групповую сервисную учетную запись gMSA для нескольких серверов
Установка учетных записей MSA и gMSA на хостах Windows
Запуск службы Windows от имени Managed Service Account
Запуск задания планировщика от имени сервисной учетной записи gMSA

Существует два типа сервисных учетных записей в AD:

Managed Service Accounts (MSA) – появились в Windows Server 2008 R2 (тип объекта msDS-ManagedServiceAccount ). Основное ограничение – такую учетную запись можно использовать только на одном сервере (т.е. их нельзя использовать с кластерными службами).
Group Managed Service Accounts (gMSA) – появились в Windows Server 2012 (тип объекта msDS-GroupManagedServiceAccount ). gMSA аккаунты можно одновременно использовать на нескольких серверах.

Создать корневой ключ Key Distribution Services

Перед началом использования сервисных учетных записей AD нужно выполнить разовую операцию по созданию корневого ключа KDS (KDS root key) на контроллере домена с включенной службой KdsSvc. Этот ключ будет использовать для генерации паролей gMSA.

Add-KdsRootKey –EffectiveImmediately

Ключ будет создан и доступен для использования через 10 часов, после окончания репликации между контролерами домена.

Совет. В тестовой среде для немедленного использования KDS ключа можно воспользоваться командой:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Проверить, что корневой ключ KDS создался успешно:

Get-KdsRootKey

Add-KdsRootKey создать корневой ключ KDS в active directory

Для проверки ключа используется команда:

Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

Test-KdsRootKey

Создать управляемую учётную запись MSA в Active Directory

Чтобы создать новую управляемую учетную запись MSA в AD воспользуйтесь командой:

New-ADServiceAccount -Name msaMskSrv1Tasks –RestrictToSingleComputer

Привяжите сервисную учетную запись MSA к определенному серверу (для привязки используется атрибут msDS-HostServiceAccount в свойствах учетной записи компьютера):

$Identity = Get-ADComputer -identity msk-srv01 Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaMskSrv1Tasks

Напоминаю, что вы можете использовать MSA аккаунт только на одном сервере.

Откройте консоль dsa.msc (ADUC, Active Directory Users and Computers) и проверьте, что в корневом контейнере CN=Managed Service Accounts появилась новая учетная запись типа msDS-ManagedServiceAccount.

контейнер Managed Service Accounts в active directory

По умолчанию этот контейнер скрыт, чтобы показать его выберите View -> Advanced Features в консоли ADUC.

Создать групповую сервисную учетную запись gMSA для нескольких серверов

Прежде чем создавать учетную запись gMSA, создайте доменную группу и добавьте в нее сервера, которым будет разрешено использовать пароль учетной записи gMSA. Проще всего создать и наполнить группу с помощью PowerShell:
New-ADGroup MskSQL1 -path 'OU=Groups,OU=MSK,OU=RU,dc=winitpro,DC=ru' -GroupScope Global -PassThru –Verbose

Add-AdGroupMember -Identity MskSQL1 -Members msk-sql01$, msk-sql02$, msk-sql03$

создать группу в active directory

Создать групповую учетную запись Group Managed Service Account (gMSA) и привязать ее к группе MskSQL1:

New-ADServiceAccount -name gmsaMskSQL1 -DNSHostName gmsaMskSQL1.winitpro.ru -PrincipalsAllowedToRetrieveManagedPassword MskSQL1 –verbose

New-ADServiceAccount создать Group Managed Service Account (gMSA) с помощью powershell

Сервера, добавленные группу нужно перезагрузить для обновления состава группы, либо вы можете обновить членство в группах AD без перезагрузки:

klist.exe -lh 0 -li 0x3e7 purge

Учётная запись gMSA также по умолчанию создается в OU Managed Service Accounts. Привязка учетной записи к серверу или группе выполняется через атрибут msDS-GroupMSAMembership в свойствах учетной записи gMSA.

объект msDS-GroupManagedServiceAccount в acttive directory

Для корректной работы Kerberos аутентификации в некоторых сервисах нужна регистрация Service Principal Name (SPN). Сервисные учетные записи gMSA можно использовать при регистрации SPN:

setspn -s MSSQLSvc/sql01 winitpro\gmsaMskSQL1$ setspn -s MSSQLSvc/sql01.winitpro.loc winitpro\gmsaMskSQL1$

Установка учетных записей MSA и gMSA на хостах Windows

Для использования сервисных аккаунтов MSA/gMSA на целевых серверах или рабочих станциях сначала нужно установить модуль PowerShell для Active Directory и .NET Framework 3.5+:

Add-WindowsFeature RSAT-AD-PowerShell

Установите учетную запись MSA на сервере:

Install-ADServiceAccount -Identity gmsaMskSQL1

Устанавливать таким образом нужно только MSA аккаунты. Для gMSA этот шаг можно пропустить. Достаточно того, чтобы этот сервер был добавлен в атрибуте PrincipalsAllowedToRetrieveManagedPassword учетной записи:

Get-ADServiceAccount gmsaMskSQL1 -Properties PrincipalsAllowedToRetrieveManagedPassword

Проверьте, сервисная учетная запись установлена корректно:

Test-ADServiceAccount gmsaMskSQL1

Если команда вернет True – все настроено правильно.

установка Install-ADServiceAccount на сервере

Если команда вернула False, скорее всего учетная запись MSA не установлена на сервере или у данного компьютера нет прав на нее:

this computer does not have permission to use the group MSA

WARNING: Test failed for Managed Service Account gmsaMskSQL1. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA.

Можно изменить периодичность смены пароля (по умолчанию 30 дней):

Set-ADServiceAccount gmsaMskSQL1 -ManagedPasswordIntervalInDays 60

Получить время последней смены пароля можно так:

Get-ADServiceAccount -Identity gmsaMskSQL1 -Properties passwordlastset

Get-ADServiceAccount passwordlastset

Для проверки работы служб и скриптов от имени сервисной учетной записи MSA не получится использовать стандартный RunAs. Вместо этого воспользуйтесь утилитой PsExec (ранее мы показывали, как использовать psexec для запуска командной строки от имени System).

Откройте командную строку с правами администратора;
Выполните команду: PsExec64.exe -i -u winitpro\gmsaMskSQL1$ -p ~ cmd.exe
Вместо пароля указан знак ~ , это значит что пароль нужно получить из AD.
В открывшемся окне cmd выполните команду whoami , чтобы убедиться, что консоль запущена от имени аккаунта gMSA.
Проверьте запуск скриптов, программ или служб от имени учетной записи Managed Service Account.

Теперь осталось настроить запуск нужных вам служб Windows, заданий Task Scheduler, пулов IIS (и т.д) от имени сервисных аккаунтов MSA/gMSA.

Запуск службы Windows от имени Managed Service Account

Рассмотрим, как настроить запуск произвольной службы Windows из-под сервисной записи MSA иди gMSA.

Откройте консоль services.msc ;
Откройте свойства нужной службы и перейдите на вкладку Log on;
Выберите опцию This account и укажите имя MSA аккаунта. В конце имени обязательно указывается символ $ (пароль указывать не нужно);
Сервисной учетной записи MSA будут автоматически предоставлены права Log On As a Service;
После сохранения изменений службу нужно перезапустить.

Для запуска пула IIS от имени gMSA, откройте расширенные настройки ApplicationPool (Advanced Settings) и в поле Identity измените ApplicationPoolIdentity на Custom Account -> winitpro\gmsaMskSQL01$ (пароль оставьте пустым):

запуск пула iis под сервисной учетой записью gmsa

Или вы можете указать учетную запись MSA для пула с помощью PowerShell:

Import-Module WebAdministration $pool = Get-Item IIS:\AppPools\wpad $pool.processModel.identityType = 3 $pool.processModel.userName = "winitpro\gmsaMskSQL01$" $pool.processModel.password = '' $pool | Set-Item

Для запуска сложных сервисов с помощью gMSA, проверьте в документации, что это поддерживается. На данный момент gMSA поддерживаются в SQL Server, IIS, AD LDS, Exchange Server.

Запуск задания планировщика от имени сервисной учетной записи gMSA

От имени сервисной учетной записи gMSA удобно запускать задания планировщика Windows Task Scheduler. Это удобно, так как пароли учетной записи gMSA не хранятся в скриптах в явном виде, вам не нужно их шифровать или защищать. При изменении пароля не нужно перенастраивать задание.

Настроить задание для запуска от имени gMSA можно только с помощью PowerShell. Например, следующий скрипт создаст новое задание планировщика, которое ежедневно в 21:00 запускает PowerShell скрипт для резервного копирования базы данных:

$action = New-ScheduledTaskAction -Execute powershell.exe -Argument "-file C:\PS\DB\BackupDB.ps1 -executionpolicy bypass -NoProfile" $trigger = New-ScheduledTaskTrigger -At 21:00 -Daily $principal = New-ScheduledTaskPrincipal -UserID winitpro\gmsaMskSQL1$ -LogonType Password -RunLevel Highest Register-ScheduledTask BackupDB –Action $action –Trigger $trigger –Principal $principal

Подробнее об управлении заданиями планировщика из PowerShell.

powershell создать задание планировщика для запуска от аккаунта Group Managed Service Accounts (gMSA)

Также вы можете создать задание планировщика с нужными настройками из графической консоли. Затем с помощью утилиты schtasks.exe из cmdможно настроить, чтобы оно запускалось от имени Managed Service Account:

schtasks /Change /TN BackupDB /RU "winitpro\gmsaMskSQL1$" /RP ""

Предоставьте учетной записи MSA/gMSA необходимые права доступа к сервису и NTFS разрешения на файловой системе. Например, я добавил учетную запись gMSA в локальную группу Backup Operators на сервере:

Add-LocalGroupMember -Group "Backup Operators" -Member winitpro\gmsaMskSQL1$

добавить gmsa аккаунт в локальную группу на сервере

Для запуска заданий планировщика нужно предоставить учетной записи gMSA права Log on as a batch job. На отдельном компьютере это можно сделать через редактор локальной GPO: gpedit.msc -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment. Добавьте в политику учетную запись: winitrpo\gmsaMskSQL1$

Параметр локальной GPO: Log on as a batch job Вход в качестве пакетного задания

Предыдущая статья Следующая статья

Привязка серверов WSUS к различным сайтам Active Directory

Поиск учетных записей администратора в Active Directory

Сброс пароля администратора Active Directory

Get-ADUser: получение информации о пользователях Active Directory из PowerShell

Windows LAPS: Управление паролями локальных администраторов на компьютерах в AD

Ищем источник блокировки учетной записи пользователя в Active Directory

Настройка параметров браузера Google Chrome с помощью групповых политик

Комментариев: 54 Оставить комментарий

Pavel 05.11.2014
gmsa1Group – это обычная глобальная группа безопасности, в которую включены необходимые сервера, на которые потом будет проинсталирована gmsa1
Ответить
- Pavel 11.11.2014
  Собственно это был вопрос, а не констатация факта.
  Может быть кто-нибудь пояснит, как связать группу ПК с уч. записью gMSA ?
  Ответить
  - itpro 11.11.2014
    В нашем примере связь идет через группу gmsa1Group. Т.е. эта группа в AD, в которую включены ПК которые нужно будет связать с групповой учеткой.
    
    Ответить
    - Pavel 11.11.2014
      Все я разобрался после того как сервера будут добавлены в группу, которая в свою очередь будет «привязана» к gMSA, их необходимо перегрузить для того что бы отобразить их членство в группе.
      Т.к. без этого происталировать gMSA на этом сервере не удастся из-за отказа в доступе.
      Таким образом не нужно привязывать к gMSA необходимые сервера, а можно привязать группу из серверов, но с одним но:
      2. Create and configure the gMSA
      http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx
      Ответить
Aleksey 29.02.2016
У меня после запуска службы от имени MSA аккаунта, вкладка Log On (Вход в систему) стала не активной.
Как это можно исправить?
Ответить
- itpro 01.03.2016
  У меня было то же самое на Windows Server 2012 R2, на 2012 — вкладка остается активной. Видимо какая-то недокументированная фича/бага.
  Чтобы переключить запуск сервиса на SYSTEM или другой аккаунт придется воспользоваться sc.exe
  Ответить
  - Иван 15.07.2023
    Может добавить в конце на счет не активной вкладки «Вход в систему»?
    sc config service_name obj=localsystem
    Ответить
- Сергей 06.07.2024
  sc managedaccount «1C:Enterprise 8.3 Server Agent (x86-64)» false
  Ответить
Владимир 18.03.2019
Подскажите как создать задание в планировщике заданий, на еженедельную перезагрузку ПК от имени MSA?
Я так понял это можно сделать только через PS?
Ответить
- itpro 19.03.2019
  Напрямую из планировщика задание, которо запускается от имени gMSA аккаунта создать нельзя. Но есть небольшой трюк — создаете и настраиваете новое задание через графический интерфейс Task Scheduler от имени просто пользователя, а потом меняете акканунт на gMSA командой
  schtasks /change /TN \TaskName /RU DOMAIN\gMSA_account$ /RP
  На запрос пароля отсавляете его пустым.
  Ответить
  - Tony 28.04.2021
    itpro! Пожалуйста добавьте в абзац ««Тонкая» настройка gMSA» мой PS-скрипт для удобного пересоздания текущих существующих задач в планировщике на учётную запись gMSA. Долго искал такой скрипт и не нашел вообще. Очень удобно использовать, т.к. не надо мучится с powershell, а работать через привычный GUI.
    #ЕгоркинА.Н. 10:27 28.04.2021
    #Gtht*****************
    $domain=»corp»
    $ObjectClass=»msDS-GroupManagedServiceAccount»
    #***************************
    clear
    Write-host «*********************************************************************»
    Write-host «Скрипт перевода задач на служебную учётную запись»
    Write-host «Скрипт запускаем на конкретном сервере с правами администратора и, желательно, с доступом к AD для поиска gMSA»
    Write-host «Выбираем задачу и затем новую учётную запись gMSA — создастся новая задача и старая перейдёт в disable»
    Write-host
    Write-host «*********************************************************************»
    pause
    clear
    #Показываем все доступные задачи
    Write-host «————————————————————————————————»
    Write-host Список всех задач из корня \
    Write-host
    Get-ScheduledTask -TaskPath «\» -TaskName «*»
    [string]$schedule_name = $(read-host «Введите (часть или полное) название задачи, в которой хотите поменять пользователя»)
    #Выбираем задачу
    $schedule_name_search = $schedule_name+»*»
    $tasks_name_sel = Get-ScheduledTask -TaskPath «\» -TaskName $schedule_name_search
    Write-host
    Write-host Выбрана задача $tasks_name_sel.TaskName
    Write-host
    #Выбираем gMSA учётную запись
    Write-host «————————————————————————————————»
    Write-host Список всех gMSA учётных записей в домене Corp
    Get-ADObject -LDAPFilter «(&(ObjectClass=$ObjectClass)(name=*))» -Server ‘Corp’ | select Name, ObjectGUId | format-table
    [string]$gmsa_name = $(read-host «Введите название сервисной учётной записи (двойной клик на имя левой и двойной клик правой кнопкой)»)
    #Проверка что gMSA примаплена к текущему серверу
    $gmsa_name_search=$domain+»\»+$gmsa_name+»$»
    $gmt = Test-ADServiceAccount -Identity $gmsa_name
    if ($gmt -eq $True) {
    Write-host
    Write-host «Успешно — учетная запись $gmsa_name найдена и привязана к этому компьютеру»
    Write-host «————————————————————————————————»
    }
    else {
    Write-host
    Write-host «Иными словами, учетная запись $gmsa_name не привязана к этому компьютеру:»
    Write-host «или вы ошиблись в выборе учётной записи, или кто-то забыл про команду»
    Write-host «Install-ADServiceAccount -Identity $gmsa_name»
    Write-host
    Write-host «при этом, учетная запись gMSA создается следующей командой от имени доменного администратора:»
    Write-host «New-ADServiceAccount -Name имя_gMSA_учётной_записи -DNSHostName hq-dc01 -PrincipalsAllowedToRetrieveManagedPassword имя_целевого_сервера$»
    Write-host «————————————————————————————————»
    pause
    exit
    }
    pause
    Write-host «————————————————————————————————»
    #Экспортируем выбранную задачу в формате xml в переменную schedule
    $schedule = Export-ScheduledTask -TaskName $schedule_name
    #Заменяем старую учётную запись на новую gMSA
    $schedule_user_bad = $schedule | findstr «UserId»
    $schedule_user_bad = $schedule_user_bad.Replace(» «,»»)
    $schedule_user_good = »+$gmsa_name_search+»
    $schedule_good = $schedule.Replace($schedule_user_bad,$schedule_user_good)
    #Заменяем тип запуска задачи на корректный
    $schedule_user_bad = $schedule | findstr «LogonType»
    $schedule_user_bad = $schedule_user_bad.Replace(» «,»»)
    $schedule_user_good = ‘Password’
    $schedule_good = $schedule_good.Replace($schedule_user_bad,$schedule_user_good)
    #Удаляем тип запуска «с наивысшими привилегиями»
    $schedule_Run_level = ‘ HighestAvailable’
    $schedule_good = $schedule_good.Replace($schedule_Run_level,»»)
    #Переводим старую задачу в Disable
    Disable-ScheduledTask -TaskName $schedule_name
    #Регистрируем новую задачу с припиской gMSA в названии
    Register-ScheduledTask -Xml ($schedule_good) -TaskName $schedule_name»_gMSA»
    Write-host «Работа скрипта завершена успешно. Но, это не означает корректность работы самой задачи в части наличия прав на отработку полезной нагрузки»
    Write-host
    Ответить
    - Tony 28.04.2021
      #ЕгоркинА.Н. 10:27 28.04.2021 #peremennye***************** $domain="corp" $ObjectClass="msDS-GroupManagedServiceAccount" #*************************** clear Write-host "*********************************************************************" Write-host "Скрипт перевода задач на служебную учётню запись" Write-host "Скрипт запускаем на конкретном сервере с правами администратора и, желательно, с доступом к AD для поиска gMSA" Write-host "Выбираем задачу и затем новую учётную запись gMSA - создастся новая задача и старая перейдёт в disable" Write-host Write-host "*********************************************************************" pause clear #Показываем все доступные задачи Write-host "------------------------------------------------------------------------------------------------" Write-host Список всех задач из корня \ Write-host Get-ScheduledTask -TaskPath "\" -TaskName "*" [string]$schedule_name = $(read-host "Введите (часть или полное) название задачи, в которой хотите поменять пользователя") #Выбираем задачу $schedule_name_search = $schedule_name+"*" $tasks_name_sel = Get-ScheduledTask -TaskPath "\" -TaskName $schedule_name_search Write-host Write-host Выбрана задача $tasks_name_sel.TaskName Write-host
      #Выбираем gMSA учётную запись Write-host "------------------------------------------------------------------------------------------------" Write-host Список всех gMSA учётных записей в домене Corp Get-ADObject -LDAPFilter "(&(ObjectClass=$ObjectClass)(name=*))" -Server 'Corp' | select Name, ObjectGUId | format-table [string]$gmsa_name = $(read-host "Введите название сервисной учётной записи (двойной клик на имя левой и двойной клик правой кнопкой)")
      #Проверка что gMSA примаплена к текущему серверу $gmsa_name_search=$domain+"\"+$gmsa_name+"$" $gmt = Test-ADServiceAccount -Identity $gmsa_name if ($gmt -eq $True) { Write-host Write-host "Успешно - учетная запись $gmsa_name найдена и привязана к этому компьютеру" Write-host "------------------------------------------------------------------------------------------------" } else { Write-host Write-host "Иными словами, учетная запись $gmsa_name не привязана к этому компьютеру:" Write-host "или вы ошиблись в выборе учётной записи, или кто-то забыл про команду" Write-host "Install-ADServiceAccount -Identity $gmsa_name" Write-host Write-host "при этом, учетная запись gMSA создается следующей командой от имени доменного администратора:" Write-host "New-ADServiceAccount -Name имя_gMSA_учётной_записи -DNSHostName hq-dc01 -PrincipalsAllowedToRetrieveManagedPassword имя_целевого_сервера$" Write-host "------------------------------------------------------------------------------------------------" pause exit } pause
      Write-host "------------------------------------------------------------------------------------------------" #Экспортируем выбранную задачу в формате xml в переменную schedule $schedule = Export-ScheduledTask -TaskName $schedule_name
      #Заменяем старую учётную запись на новую gMSA $schedule_user_bad = $schedule | findstr "UserId" $schedule_user_bad = $schedule_user_bad.Replace(" ","") $schedule_user_good = ''+$gmsa_name_search+'' $schedule_good = $schedule.Replace($schedule_user_bad,$schedule_user_good)
      #Заменяем тип запуска задачи на корректный $schedule_user_bad = $schedule | findstr "LogonType" $schedule_user_bad = $schedule_user_bad.Replace(" ","") $schedule_user_good = 'Password' $schedule_good = $schedule_good.Replace($schedule_user_bad,$schedule_user_good)
      #Удаляем тип запуска "с наивысшими привилегиями" $schedule_Run_level = ' HighestAvailable' $schedule_good = $schedule_good.Replace($schedule_Run_level,"")
      #Переводим старую задачу в Disable Disable-ScheduledTask -TaskName $schedule_name
      #Регистрируем новую задачу с припиской gMSA в названии Register-ScheduledTask -Xml ($schedule_good) -TaskName $schedule_name"_gMSA"
      Write-host "Работа скрипта завершена успешно. Но, это не означает корректность работы самой задачи в части наличия прав на отработку полезной нагрузки" Write-host
      Ответить
      - itpro 06.05.2021
        Спасибо за инфу, идея хорошая!
        Обязательно попробую твой скрипт в деле и отпишусь о результатах.
      - itpro 07.05.2021
        Обновил статью, добавил упоминание про ваш скрипт. Действительно, удобно.
        Спасибо!
      - Руслан 22.08.2022
        выдает вот такую ошибку
        egister-ScheduledTask : XML-код задачи содержит значение в неправильном формате или за пределами допустимого диапазона. (9,29):Principal:medibor\msaSrv2Tasks$ Password D:\Admin\sheduled_2.ps1:80 знак:1 + Register-ScheduledTask -Xml ($schedule_good) -TaskName $schedule_name ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (PS_ScheduledTask:Root/Microsoft/...S_ScheduledTask) [Register-ScheduledTask], CimExcept ion + FullyQualifiedErrorId : HRESULT 0x80041318,Register-ScheduledTask
        это потому что в конечном xml:
        
        medibor\msaSrv2Tasks$ -Password
        я так понимаю, там должно быть и
  - Илья 28.07.2022
    Здравствуйте. «Теперь» (на момент написания ответа) можно. Правда немного через ж0*у
    Ответить
  - Юрий 17.01.2023
    Или лучше так: Set-ScheduledTask -TaskName $TaskFullPath -Principal $Principal. $Principal как в статье выше.
    Ответить
Yaromax 19.08.2020
Есть ли срок действия у корневого ключа KDS, и если да — то как его обновить без угрозы простоя сервисов?
Ответить
Hexen05 05.03.2021
-DNSHostName dc1.winitpro.ru , где dc1.winitpro.ru – имя DNS сервера
из документации
-DNSHostName
Specifies the DNS host name of Service Account.
Ответить
Александр 17.04.2022
Не освещена проблема «двойного прыжка» (double-hop) при установке учётной записи на сервер через «PSRemouting», ходить для этого на сервер через RDP как минимум странно да и просто не удобно если сервер не один.
Ответить
Артём 02.08.2022
schtasks /Change /TN BackupDB /RU «winitpro\gmsaMskSQL1$» /RP «»
Не работает в случае Windows Server 2008R2. Выдаёт ошибку:
ERROR: Logon failure: unknown user name or bad password.
Как это можно победить?
Создать через PowerShell тоже не удаётся — командлеты ScheduledTaskAction в Windows Server 2008R2, судя по всему, не поддерживаются.
Ответить
- itpro 17.08.2022
  gmsa появились в windows server 2012
  в 2008 r2 по идее должны работать обычны MSA аккаунты. Но на 2008 не пробовал, да и не осталось уже таких хостов.
  Ответить
Данид 16.09.2022
Добрый день, не подскажете в чем может быть проблема при выполнении TaskScheduler из под gMSA, не происходи отправка почтового сообщения прописанного в скрипте, при выполнении этого же скрипта из под обычной учетной записи все работает прекрасно.
Ответить
- itpro 28.09.2022
  Отлаживайте скрипт, внимательно продумайте его логику, что и под кем он делает.
  Может быть проблема с аутентификацией (от чьего имени отправляется файл) или просто у пользователя gMSA нет доступа к службе/файлу.
  Например, exchange может запрешать отправку от пользователей без ящика или еще тчо-то подобное.
  Ответить
Стас 14.12.2022
Здравствуйте. Команда проверки gMSA возвращает true даже без Install-ADServiceAccount на целевом сервере. Возникает вопрос, так действительно ли нужно выполнять команду установки для УЗ gMSA или это просто какой-то пережиток УЗ MSA?
Ответить
- itpro 16.12.2022
  Довольно странно, ведь не логично автоматически кэшировать все аккаунты gmsa на сервере.
  Не могла эта учетка быть установлена кем-то до вас ранее? И какая версия Windows Server?
  Ответить
  - Стас 26.12.2022
    А вы проверьте это сами и убедитесь в этом.
    Ответить
    - Юрий 17.01.2023
      Test-ADServiceAccount без Install-ADServiceAccount у меня на чистом компьютере возвращает False.
      Ответить
      - Hexen05 19.01.2023
        а чистый компьютер связан с gmsa? никогда не делал Install-ADServiceAccount
      - Юрий 19.01.2023
        Поправлю сам себя. Логика sMSA и gMSA разная. Все операции на клиенте типа Install-ADServiceAccount и им подобные работают только с sMSA, с gMSA они никак не связаны и использоваться не должны.
    - serg 06.02.2023
      Сегодня тоже заметил такое же поведение на чистом Windows Server 2022.
      На новом хосте сразу установились ВСЕ gMSA аккаунты из AD.
      Они видны в профилях пользователей и команда возвражает True для любого аккаунта:
      Test-ADServiceAccount gmsamsksql1
      Я пока не понял это баг или фича такая 🙂
      Ответить
      - serg 06.02.2023
        Прошу удалить комент 🙂 это не так.
        Я не на том хосте смотрел )
Наталья 18.01.2023
У меня после запуска службы от имени MSA аккаунта, вкладка Log On (Вход в систему) стала не активной. Как это можно исправить?
Подскажите команду как можно исправить
Ответить
- Hexen05 19.01.2023
  В какой службе? так и должно быть. Если очень надо, то
  в cmd (от администратора) sc managedaccount false. Включить обратно через true.
  или другой способ, через реестр
  Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
  Value: ServiceAccountManaged
  Datatype: REG_BINARY
  01 00 00 00 (включено)
  00 00 00 00 (выключено)
  Ответить
Hexen05 19.01.2023
порезалось…
sc managedaccount [servise_name] false
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[servise_name]
Ответить
Юрий 19.01.2023
Я понимаю, что тема sMSA/gMSA сложная, но статья требует кардинальной переработки, так как в ней много ошибок и нарушена логика управления MSA.
Проделав массу тестов и погрузившись с головой могу сказать, что правильно так.
Логика sMSA:
1. Создание sMSA в AD: New-ADServiceAccount —RestrictToSingleComputer
2. Привязка Computer к sMSA: Add-ADComputerServiceAccount. Привязка идёт за счёт атрибута msDS-HostServiceAccount в УЗ Computer.
3. Установка sMSA на Computer: Install-ADServiceAccount
Логика gMSA:
1. Создание gMSA в AD: New-ADServiceAccount —PrincipalsAllowedToRetrieveManagedPassword
. Точка, больше ничего. Привязка идёт через атрибут msDS-GroupMSAMembership в УЗ gMSA.
Вот тут важный момент. RestrictToSingleComputer и PrincipalsAllowedToRetrieveManagedPassword взаимоисключаемые, либо одно, либо другое.
В sMSA механизм такой: sMSA установленная на Computer лезет в УЗ своего компьютера в атрибут msDS-HostServiceAccount, получает с него DN AD объекта sMSA и уже обращается к нему.
В gMSA механизм другой: в УЗ gMSA а атрибуте msDS-GroupMSAMembership перечисляется список Computer имеющих права Allow/Deny на извлечение пароля от gMSA.
Рекомендация. В PrincipalsAllowedToRetrieveManagedPassword лучше указывать не Computer List, а Security Group, и управлять уже составом группы. И удобно и надежно.
В этом месте серьёзная ошибка: «Аргумент “ -LogonType Password ” означает, что пароль для этой gMSA учетной записи будет получен с контроллера домена.» LogonType Password означает, что пароль должен быть получен и представлен на момент регистрации TaskScheduler. Этот тип имеют все задания с указанным именем пользователя. Проверяем по первоисточнику: «TASK_LOGON_PASSWORD — Use a password for logging on the user. The password must be supplied at registration time.» А то, что пароль будет браться из вне указывает знак $ на конце УЗ. То, что искать его нужно не локально, а в AD указывает NetBiosDomainName в имени УЗ.
Ответить
Наталья 23.01.2023
Добрый день а подскажите как добавить gmsa в доменные администраторы или локальные админы на сервере? Пытаешься добавить эту УЗ но в поиске не находит её
Ответить
- Юрий 23.01.2023
  У меня находит прекрасно и добавляется как через GUI, так и PS. Если через GUI, то проверьте, чтобы поиск был в формате domain\gmsa$ (доллар на конце обязательно), а в Object Types был выбран Service Accounts.
  Ответить
Ваня 23.01.2023
Как правильно — создавать одну gMSA для всех служб всех серверов или несколько делать?
Ответить
- Юрий 23.01.2023
  По Best Practice правильно использовать ролевую модель. Например: 1) gMSA01 включена для серверов Exchange, имеет права для доступа к файлам и чистит на них логи; 2) gMSA02 включена для на File Servers и осуществляет на них обслуживание файлами (чистка, репорты, перекладчик, синхронизатор и т.п.); 3) сложные роли: скрипт получает данные с AD, по ним что-то правит в Exchange, результат кладёт на FileServer.
  Ответить
Ваня 25.01.2023
Мне кажется тут ошибка:
«Можно изменить периодичность смены пароля (по умолчанию 30 дней):
Set-ADServiceAccount gmsaMskSQL1 -ManagedPasswordIntervalInDays 60»
Нет такого параметра. Он есть только у New-ADServiceAccount. Таким образом период смены пароля не изменить у созданной gMSA.
Ответить
- Юрий 25.01.2023
  Да, тут ошибка, тут вообще очень много ошибок. Статья представляет больше компиляцию из других источников нежели личный опыт. Параметр ManagedPasswordIntervalInDays в PS 12/16/19/22 присутствует только в командлете New-ADServiceAccount и задаётся только на стадии создания. Я не знаю зачем нужно менять стандартный период, практической ценности в этом нет. Из офф документации:
  «Specifies the number of days for the password change interval. If set to 0 then the default is used. This can only be set on object creation. After that the setting is read only. This value returns the msDS-ManagedPasswordInterval of the group managed service account object.»
  Ответить
  - Владимир 02.02.2023
    Подскажите, какая версия домена (леса) всё таки нужна для sMSA/gMSA ? У меня сейчас и домен и лес 2003 (контроллеры 2003-2012r2), но присутствует и CN Managed Service Accounts и атрибут msDS-HostServiceAccount у учёток компов. Также Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId выдаёт True.
    Будет ли работать эта фича или не пытаться даже?
    Ответить
    - Юрий 03.02.2023
      Вообще, насколько я понял, для sMSA уровень леса/домена не играет роли. Но должно быть выполнено пару требований:
      1. Обрабатывать sMSA будут DC только с Windows 2008R2 и выше.
      2. Лес/Домен должны быть подготовлены через «adprep /forestprep» и «adprep /domainprep» c ОС максимальной версии, в твоём случае это Win2012R2.
      3. Минимальная ревизия домена должна быть не меньше 11.
      Проверь текущую ревизию так:
      $DomainDN = (Get-ADDomain).DistinguishedName
      $AdUpdDN = «CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,$DomainDN»
      Get-ADObject -Identity $AdUpdDN -Properties Revision | select Name, Revision
      Если всё так, то стоит пытаться. Я бы попытался хотя бы ради опыта.
      Ответить
Сергей 15.03.2023
Добрый день. каким способом можно предоставить Сервисной УЗ MSA\gMSA предоставить доступ к общему п\я для отправки от имени?
Ответить
- itpro 15.03.2023
  Насколько я помню, для gMSA учетки нельзя создать ящик, соотвественно не поучится дать доступ на sendas.
  Ответить
  - Юрий 15.03.2023
    Всё верно. У gMSA не существует AD атрибутов mail и mailNickname, как и любых других типа msExch, поэтому Exchange их в качестве Recipient рассматривать не может..
    Ответить
Сергей 06.07.2024
Если вкладка не активна то сделать sc managedaccount «1C:Enterprise 8.3 Server Agent (x86-64)» false
учетки MSA добавить в группу и на файловом сервере дать разрешения на группу, Будет работать ?
Ответить
- itpro 11.07.2024
  Да, можно дать NTFS права на шару для MSA аккаунта.
  Ответить
Dzmitry 18.07.2024
Есть возможность с помощью powershell предоставить права Log on as a batch job не лазая руками по оснасткам? Предстоит настроить несколько серверов, хочу автоматизировать рутину.
Ответить
- itpro 19.07.2024
  Можно дать права Log on as a batch job через утилиту ntrights.exe (ранее была в составе Resource Kit для Win 2003). Сейчас можно скачать здесь из веб архива (__https://web.archive.org/web/20200202033627/https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=17657)
  ntrights.exe +r SeBatchLogonRight -u Username
  Ну или через GPO…
  Ответить
Max 10.10.2024
Здравствуйте!
Подскажите пожалуйста в примере:
New-ADServiceAccount -name gmsaMskSQL1 -DNSHostName gmsaMskSQL1.winitpro.ru
DNSHostName — нужно указать DNS сервер ?
Не могу понять для чего данный параметр
Ответить
- itpro 13.10.2024
  Это DNS имя, которое вы хотите задать для вашего аккаунта. Оно нужно для регистрации SPN, и соотвественно для работы Kerberos,
  Ответить
Александр 18.11.2024
Здравствуйте!
все делали по инструкции, но нечего не запускается,
Register-ScheduledTask : Имя файла или его расширение имеет слишком большую длину.
строка:1 знак:1
+ Register-ScheduledTask konsultant -Action $Action и.т.д
Ответить

Оставить комментарий