Msa что это windows

Обновлено: 05.07.2024

Управляемые учетные записи служб (MSA) — это тип субъекта безопасности, доступный в текущих поддерживаемых версиях служб домена Active Directory. Они имеют общие характеристики субъектов безопасности и компьютера, и пользователя. Они могут добавляться в группы безопасности, могут выполнять проверку подлинности и доступ к ресурсам в сети. Они предназначены для использования службами, пулами приложений IIS и запланированными задачами.

Преимущества управляемых учетных записей служб

Управляемые учетные записи служб позволяют решить конкретные вопросы, связанные с использованием учетных записей пользователей для выполнения служб, запланированных задач и пулов приложений IIS.

Автоматическое управление паролями
Упрощенное управление именем субъекта службы (SPN)
Не может использоваться для интерактивного входа в Windows
Простой контроль того, какие компьютеры авторизованы проверять подлинность MSA и выполнять код в их контексте

Оценки по запросу, которые могут использовать управляемые учетные записи служб

Управляемые учетные записи служб можно настроить для работы со следующими оценками по запросу

Active Directory
Безопасность Active Directory
System Center Configuration Manager
SharePoint
SQL Server
Клиент Windows
Windows Server

Управляемые учетные записи служб официально не поддерживаются службой поддержки пользователей Майкрософт для некоторых конфигураций среды. Хотя они работают в большинстве сценариев, может потребоваться использовать учетную запись домена, когда конфигурации среды препятствуют использованию управляемой учетной записи службы.

Подготовка управляемых учетных записей служб

Предварительным требованием для настройки запланированной задачи оценки для выполнения в качестве MSA является подготовка или создание MSA в службах домена Active Directory. Каждая из поддерживаемых оценок указывает требования по авторизации и доступу к учетной записи запланированной задачи, чтобы она была успешно выполнена. Чтобы узнать требования к доступу для учетной записи запланированной задачи, обратитесь к документам о начале работы с оценками и документам о предварительных требованиях.

Существует два типа управляемых учетных записей служб. Обе можно настроить для запланированной задачи поддерживаемой оценки.

Отдельные управляемые учетные записи служб (также известные как виртуальные учетные записи) могут быть авторизованы только для проверки подлинности на компьютере, подключенном к одному домену.
Групповые управляемые учетные записи служб могут быть авторизованы для проверки подлинности на компьютерах, подключенных к нескольким доменам.

Для подготовки и настройки обоих типов MSA требуется модуль Windows PowerShell Active Directory. Контроллеры домена обычно уже имеют этот модуль PowerShell, установленный во время установки роли контроллера домена.

Этот модуль, компонент инструментария администратора удаленного сервера, может быть добавлен к Windows Server SKU через диспетчер сервера. Этот модуль может быть также добавлен в Windows 10.

Сценарий 1: отдельная управляемая учетная запись служб (sMSA)

Для успешной подготовки отдельных управляемых учетных записей служб необходимо использовать схему леса служб домена Active Directory минимум на компьютере Windows Server 2008 R2. Компьютеры, выполняющие запланированные задачи под учетными записями sMSA, должны работать на Windows Server 2012 или более поздней версии.

Для подготовки sMSA к выполнению оценок по запросу необходимо сделать три шага.

Создать sMSA с использованием командлета New-ADServiceAccount PowerShell.
Авторизовать компьютер по сбору данных на получение пароля для sMSA с использованием командлета Add-ADComputerServiceAccount PowerShell.
Предоставить sMSA требуемый доступ к оцениваемой среде в соответствии с документацией о предварительных требованиях для релевантной настраиваемой оценки.

Создать отдельную управляемую учетную запись служб

Чтобы создать sMSA, выполните следующую команду в рамках сеанса PowerShell из контроллера домена или члена домена с установленным модулем Windows PowerShell Active Directory, используя учетную запись с необходимыми правами для создания учетных записей в Active Directory (по умолчанию необходимые права есть у операторов учетных записей или администраторов домена).

например: PS C:> New-ADServiceAccount -Name sMSA-SVC -RestrictToSingleComputer

Авторизовать компьютер по сбору данных для использования sMSA

Чтобы авторизовать компьютер по сбору данных на получение пароля для sMSA, выполните следующую команду в рамках сеанса PowerShell из контроллера домена или члена домена с установленным модулем Windows PowerShell Active Directory, используя учетную запись с необходимыми правами для создания учетных записей в Active Directory (по умолчанию необходимые права есть у операторов учетных записей или администраторов домена).

например: Add-ADComputerServiceAccount -Identity "OMS-AD-Tools$" -ServiceAccount "sMSA-SVC$"

Установка sMSA на компьютер для сбора данных

Предварительное кэширование sMSA на компьютере для сбора данных — важный шаг для подтверждения того, что учетная запись подготовлена правильно и компьютер для сбора данных сможет успешно получить пароль sMSA и использовать эту учетную запись. На компьютере для сбора данных с установленным модулем Active Directory Powershell выполните следующее.

например: Install-ADServiceAccount -Identity "sMSA-SVC$"

Если в ответ возвращается ошибка "командлет не найден", установите модуль Active Directory Powershell так, как объяснено в разделе Подготовка управляемых учетных записей служб выше.

Для других ошибок просмотрите канал журнала событий Microsoft-Windows-Security-Netlogon/Operational для событий категории MSA.

Сценарий 2: групповая управляемая учетная запись служб (sMSA)

Для успешной подготовки групповых управляемых учетных записей служб необходимо использовать схему леса служб домена Active Directory минимум на компьютере Windows Server 2012. Компьютеры, выполняющие запланированные задачи под учетными записями gMSA, должны работать на Windows Server 2012 или более поздней версии.

Для подготовки gMSA к выполнению оценок по запросу необходимо сделать три шага.

Создать корневой ключ служб распространения ключей KDS в Active Directory, используя команду Add-KDSRootKey
Создать gMSA и авторизовать компьютер по сбору данных на получение пароля для gMSA с использованием командлета New-ADServiceAccount PowerShell.
Предоставить gMSA требуемый доступ к оцениваемой среде в соответствии с документацией о предварительных требованиях для релевантной настраиваемой оценки.

Подготовка корневого ключа KDS

Если корневой ключ KDS еще никогда не создавался в лесу Active Directory, его нужно создать. Чтобы определить, создан ли уже корневой ключ KDS, выполните следующую команду из сеанса PowerShell.

Если эта команда не вернула никакого результата, значит корневого ключа в лесу Active Directory нет.

Чтобы создать корневой ключ KDS, выполните следующую команду в рамках сеанса PowerShell из контроллера домена или члена домена с установленным модулем Windows PowerShell Active Directory, используя учетную запись с необходимыми правами для создания учетных записей в Active Directory (по умолчанию необходимые права есть у администраторов предприятия и администраторов домена в корневом домене леса).

Команда Add-KdsRootKey -EffectiveImmediately позволяет создать gMSAs через 10 часов, чтобы гарантировать, что репликация была передана на все контроллеры домена.

Команда Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) позволяет создать gMSAs немедленно.
При таком подходе возникает риск неудачи при создании или использовании gMSA, так как репликация AD по всему лесу при нормальных условиях работы занимает несколько часов.

Создать групповую управляемую учетную запись служб

Чтобы создать gMSA, выполните следующую команду в рамках сеанса PowerShell из контроллера домена или члена домена с установленным модулем Windows PowerShell Active Directory, используя учетную запись с необходимыми правами для создания учетных записей в Active Directory (по умолчанию необходимые права есть у операторов учетных записей или администраторов домена).

Например: PS C:> New-ADServiceAccount -Name gMSA-SVC -DNSHostName gMSA-SVC.contoso.local -PrincipalsAllowedToRetrieveManagedPassword "oms-ad-tools$"

Установка gMSA на компьютер для сбора данных

Предварительное кэширование gMSA на компьютере для сбора данных — важный шаг для подтверждения того, что учетная запись подготовлена правильно и компьютер для сбора данных сможет успешно получить пароль gMSA и использовать эту учетную запись. На компьютере для сбора данных с установленным модулем Active Directory Powershell выполните следующее.

Например: Install-ADServiceAccount -Identity "gMSA-SVC$"

Для других ошибок просмотрите канал журнала событий Microsoft-Windows-Security-Netlogon/Operational для событий категории MSA.

Это краткое описание содержит пошаговые инструкции и общие сведения о включении и использовании групповых управляемых учетных записей служб в Windows Server 2012.

Содержание документа

В этом разделе приводятся примеры командлетов Windows PowerShell, которые можно использовать для автоматизации некоторых описанных процедур. Дополнительные сведения см. в разделе Использование командлетов.

Предварительные требования

Введение

Когда клиентский компьютер подключается к службе, размещенной на ферме серверов с использованием балансировки сетевой нагрузки (NLB) или какого-либо другого метода, при котором клиенту, проходящему проверку подлинности, все службы кажутся одной, протоколы проверки подлинности, поддерживающие взаимную проверку подлинности (такие как Kerberos), можно использовать, только если на всех экземплярах служб используется один и тот же субъект. Это означает, что удостоверение каждой службы должно подтверждаться одинаковым паролем или ключом.

Отказоустойчивые кластеры не поддерживают групповые управляемые учетные записи служб. При этом групповую или автономную учетную запись службы могут использовать службы, работающие поверх службы кластеров и представляющие собой службу Windows, пул приложений или назначенную задачу либо поддерживающие такие учетные записи изначально.

Службы могут выбирать следующие разрешенные субъекты, каждый из которых обладает определенными свойствами:

Субъекты	Область	Поддерживаемые службы	Управление паролями
Учетная запись компьютера в системе Windows	Домен	Ограничена одним сервером в домене	Управляется компьютером
Учетная запись компьютера без системы Windows	Домен	Любой сервер в домене	Нет
Виртуальная учетная запись	Локальная	Ограничена одним сервером	Управляется компьютером
Автономная управляемая учетная запись Windows 7	Домен	Ограничена одним сервером в домене	Управляется компьютером
Учетная запись пользователя	Домен	Любой сервер в домене	Нет
Групповая управляемая учетная запись службы	Домен	любой Windows Server 2012 сервер, присоединенный к домену	Управляется контроллером домена и извлекается узлом

Учетные записи компьютеров Windows, автономные управляемые учетные записи Windows 7 и виртуальные учетные записи могут использоваться только в одной системе. Если вы настраиваете учетную запись, которая будет использоваться различными службами на фермах серверов, выберите учетную запись пользователя или учетную запись не в системе Windows. Такие учетные записи не имеют функции централизованного управления паролями, а значит, каждой организации придется создавать дорогое решение для обновления ключей для служб в каталоге Active Directory и их передачи во все экземпляры этих служб.

с помощью Windows Server 2012 службам или администраторам службы не требуется управлять синхронизацией паролей между экземплярами службы при использовании групповых управляемых учетных записей служб (gMSA). Вы создаете групповую управляемую учетную запись службы в Active Directory и настраиваете службу, поддерживающую управляемые учетные записи. Для подготовки групповой управляемой учетной записи службы можно использовать командлеты *-ADServiceAccount, входящие в модуль Active Directory. Конфигурацию удостоверения службы на узле поддерживают:

те же API, что и для автономных управляемых учетных записей служб, поэтому продукты, которые поддерживают автономные управляемые учетные записи служб, поддерживают и групповые;

службы, которые настраивают удостоверения для входа с помощью диспетчера управления службами;

службы, которые используют для настройки удостоверения диспетчер IIS для пулов приложений;

задачи, использующие планировщик заданий.

Требования для групповых управляемых учетных записей служб

В приведенной ниже таблице указаны требования к операционной системе, которые должны выполняться для работы проверки подлинности Kerberos со службами, использующими групповые управляемые учетные записи служб. Требования Active Directory перечислены под таблицей.

Для выполнения команд Windows PowerShell, которые используются для администрирования групповых управляемых учетных записей служб, необходима 64-разрядная архитектура.

Требования к операционной системе

Элемент	Требование	Операционная система
Узел клиентского приложения	RFC-совместимый клиент Kerberos	Не ниже Windows XP
Доменные контроллеры домена учетной записи пользователя	RFC-совместимый KDC	Не ниже Windows Server 2003
Узлы, входящие в службу общего доступа	Windows Server 2012
Доменные контроллеры домена узла участника	RFC-совместимый KDC	Не ниже Windows Server 2003
Доменные контроллеры домена учетной записи gMSA	Windows Server 2012 Контроллеры домена, доступные для получения пароля узлом	домен с Windows Server 2012, в котором могут находиться более ранние версии системы, чем Windows Server 2012
Узел внутренней службы	RFC-совместимый сервер приложений Kerberos	Не ниже Windows Server 2003
Доменные контроллеры домена учетной записи внутренней службы	RFC-совместимый KDC	Не ниже Windows Server 2003
Windows PowerShell для Active Directory	Windows PowerShell для Active Directory, установленный на компьютере с поддержкой 64-разрядной архитектуры или на компьютере удаленного управления (например, с помощью средств удаленного администрирования сервера).	Windows Server 2012

Требования доменных служб Active Directory

схему Active Directory в лесу домена gMSA необходимо обновить для Windows Server 2012 создания gMSA.

схему можно обновить, установив контроллер домена, работающий под управлением Windows Server 2012 или выполнив версию adprep.exe с компьютера, на котором выполняется Windows Server 2012. Значение атрибута для версии объекта CN=Schema,CN=Configuration,DC=Contoso,DC=Com должно быть равным 52.

Новая групповая управляемая учетная запись.

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

Новая или существующая группа безопасности, если вы даете группе управление доступом к управляемой группе.

Если первый основной корневой ключ для Active Directory не развернут в домене или не создан, его необходимо создать. Результат создания ключа можно проверить в журнале рабочих событий KdsSvc, идентификатор события — 4004.

Инструкции по созданию ключа см. в разделе Создание корневого ключа KDS служб распространения ключей. Корневым ключом для Active Directory является ключ службы распространения ключей (Майкрософт) — kdssvc.dll.

Жизненный цикл

Жизненный цикл фермы серверов с использованием функции групповых управляемых учетных записей служб включает следующие задачи:

Развертывание фермы серверов федерации

Добавление узлов в существующую ферму серверов

Списание узлов из существующей фермы серверов

Списание существующей фермы серверов

Удаление скомпрометированного узла из фермы серверов при необходимости

Развертывание фермы серверов федерации

При развертывании новой фермы серверов администратору службы необходимо определить:

поддерживает ли служба использование групповых управляемых учетных записей служб;

требует ли служба проверки подлинности входящих или исходящих подключений;

имена учетных записей компьютеров для входящих в службу узлов с использованием групповых управляемых учетных записей служб;

имя DNS-узла службы;

имена субъектов-служб (SPN) для службы;

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

Шаг 1. Создание групповых управляемых учетных записей служб

создать gMSA можно только в том случае, если схема леса была обновлена до Windows Server 2012, корневой ключ главного Active Directory развернут, а в домене, в котором будет создан gMSA, есть по крайней мере один Windows Server 2012 контроллер домена.

Членство в группах "Администраторы домена" или возможность создания объектов MsDS-граупманажедсервицеаккаунт является минимальным требованием для выполнения следующих процедур.

Значение параметра-Name всегда является обязательным (если вы указали-Name или NOT), где-DNSHostName,-Рестрикттосинглекомпутер и-Рестрикттуутбаундаусентикатион являются вторичными требованиями для трех сценариев развертывания.

Для создания групповой управляемой учетной записи службы используйте командлет New-ADServiceAccount.

на Windows Server 2012 контроллере домена запустите Windows PowerShell на панели задач.

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД (модуль Active Directory загрузится автоматически):

New-Адсервицеаккаунт [-name] строка > -dNSHostName < строка > [-керберосенкриптионтипе < адкерберосенкриптионтипе > ] [-манажедпассвординтервалиндайс < Nullable [Int32] > ] [-PrincipalsAllowedToRetrieveManagedPassword < ADPrincipal [] > ] [-SamAccountName < строка > ] [-ServicePrincipalNames < строка [] > ]

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

Пример

Введите команды в одну строку, даже если кажется, что из-за ограничений форматирования они переносятся по словам на другую строку.

Минимальным требованием для выполнения этих процедур является членство в группе Администраторы домена либо Операторы учета или наличие права на создание объектов msDS-GroupManagedServiceAccount. Дополнительные сведения об использовании подходящих учетных записей и участия в группах см. в разделе Локальные группы и группы домена по умолчанию.

Чтобы создать групповую управляемую учетную запись службы для исходящей проверки подлинности, используйте командлет New-ADServiceAccount.

на Windows Server 2012 контроллере домена запустите Windows PowerShell на панели задач.

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

New-Адсервицеаккаунт [-name] строка > -рестрикттуутбаундаусентикатиононли [-манажедпассвординтервалиндайс < Nullable [Int32] > ] [-PrincipalsAllowedToRetrieveManagedPassword < ADPrincipal [] > ]

Параметр	Строка	Пример
Имя	Имя учетной записи	ITFarm1
ManagedPasswordIntervalInDays	Периодичность смены пароля в днях (если не указано, используется значение по умолчанию 30)	75
PrincipalsAllowedToRetrieveManagedPassword	Имена учетных записей компьютеров для входящих в службу узлов или групп безопасности, в которые входят эти узлы	ITFarmHosts

Пример

Шаг 2. Настройка службы для приложения удостоверения служб

сведения о настройке служб в Windows Server 2012 см. в следующей документации по функциям:

Пул приложений IIS

Дополнительные сведения см. в разделе Службы.

Дополнительные сведения см. в статье Обзор планировщика задач.

Групповые управляемые учетные записи могут поддерживать и другие службы. Информацию о настройки таких служб см. в документации к соответствующим продуктам.

Добавление узлов в существующую ферму серверов

Если для управления узлами-членами используются группы безопасности, добавьте учетную запись компьютера для нового узла члена в группу безопасности (членом которой являются узлы gMSA), используя один из следующих методов.

Минимальным требованием для выполнения этих процедур является членство в группе Администраторы домена или наличие права на добавление объектов в группу безопасности.

Метод 1: Active Directory — пользователи и компьютеры

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

Метод 3: командлет Add-ADPrincipalGroupMembership в Windows PowerShell Active Directory

Порядок использования данного метода см. в статье Add-ADPrincipalGroupMembership.

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

Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы домена либо Операторы учета или наличие права на управление объектами msDS-GroupManagedServiceAccount. Дополнительные сведения об использовании подходящих учетных записей и членства в группах см. в разделе "Локальные группы и группы домена по умолчанию".

Добавление входящих в службу узлов с помощью командлета Set-ADServiceAccount

на Windows Server 2012 контроллере домена запустите Windows PowerShell на панели задач.

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Get-Адсервицеаккаунт [-Identity] строка > — Свойства принЦипалсалловедторетриевеманажедпассворд

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Set-Адсервицеаккаунт [-Identity] строка > -принЦипалсалловедторетриевеманажедпассворд < адпринЦипал []>

Пример

Например, чтобы добавить входящие в службу узлы, введите следующие команды и нажмите клавишу ВВОД:

Обновление свойств групповой учетной записи службы

Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы домена либо Операторы учета или наличие права на запись в объекты msDS-GroupManagedServiceAccount.

Откройте модуль Active Directory для Windows PowerShell и настройте желаемые свойства с помощью командлета Set-ADServiceAccount.

Подробную информацию об установке этих свойств см. в статье Set-ADServiceAccount в библиотеке TechNet или введите Get-Help Set-ADServiceAccount в командной строке модуля Active Directory для Windows PowerShell и нажмите клавишу ВВОД.

Списание узлов из существующей фермы серверов

Минимальным требованием для выполнения этих процедур является членство в группе Администраторы домена или наличие права на удаление объектов из группы безопасности.

Шаг 1. Удаление узла из групповой управляемой учетной записи службы

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

Метод 1: Active Directory — пользователи и компьютеры

Порядок использования данного метода см. в статье Удаление учетной записи компьютера с помощью командной строки.

Метод 3: командлет Remove-ADPrincipalGroupMembership в Windows PowerShell Active Directory

дополнительные сведения см. в разделе remove-адпринЦипалграупмембершип в библиотеке TechNet или с помощью команды Get-Help remove-адпринЦипалграупмембершип в модуле Active Directory для Windows PowerShell командной строки и нажатия клавиши ввод.

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

Удаление входящих в службу узлов с помощью командлета Set-ADServiceAccount

на Windows Server 2012 контроллере домена запустите Windows PowerShell на панели задач.

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Get-Адсервицеаккаунт [-Identity] строка > — Свойства принЦипалсалловедторетриевеманажедпассворд

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Set-Адсервицеаккаунт [-Identity] строка > -принЦипалсалловедторетриевеманажедпассворд < адпринЦипал []>

Пример

Например, чтобы удалить входящие в службу узлы, введите следующую команду и нажмите клавишу ВВОД:

Шаг 2. Удаление групповой управляемой учетной записи службы из системы

Удалите кэшированные учетные данные групповой управляемой учетной записи службы с входящего в службу узла с помощью API Uninstall-ADServiceAccount или NetRemoveServiceAccount API в системе соответствующего узла.

Минимальным требованием для выполнения этих процедур является членство в группе Администраторы или наличие эквивалентных прав.

Удаление групповой управляемой учетной записи службы с помощью командлета Uninstall-ADServiceAccount

на Windows Server 2012 контроллере домена запустите Windows PowerShell на панели задач.

Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Uninstall-Адсервицеаккаунт адсервицеаккаунт>

Пример

Например, чтобы удалить кэшированные учетные данные групповой управляемой учетной записи службы ITFarm1, введите следующую команду и нажмите клавишу ВВОД:

Для получения дополнительных сведений о командлете Uninstall-ADServiceAccount введите в командной строке модуля Active Directory для Windows PowerShell команду Get-Help Uninstall-ADServiceAccountи нажмите клавишу ВВОД либо изучите статью Uninstall-ADServiceAccountна веб-сайте TechNet.

Есть способ, который позволяет узнать пароль администратора в случае, если какая-либо служба запускается от его имени.
Пароли учетных записей, от которых запускаются службы Windows, хранятся в зашифрованном виде в реестре (LSA Secrets) по пути:

HKEY_LOCAL_MACHINE/Security/Policy/Secrets

Скопировать путь реестра во временный путь, а затем расшифровать зашифрованные пароли
Использовать теневые копии
Использовать специальные утилиты для работы с процессом lsass.exe

Воспользуемся утилитой gsecdump для извлечения паролей.
Запустим PowerShell от имени администратора и выполним команду: gsecdump-v2b5.exe -l
Результат:

Автоматическая смена паролей. По умолчанию смена пароля – раз в 30 дней
Сложный пароль. Используется комплексный автоматически генерируемый пароль из 240 символов в случайном порядке (первая половина — буквы английского алфавита, вторая половина — цифры и другие символы)
Отсутствие избыточных прав
Возможность использования одного MSA на нескольких серверах (gMSA). В случае, когда требуется, чтобы все экземпляры служб использовали один и тот же субъект, например для использования в службе NLB
Управление SPN

Включение MSA в PowerShell
1) Выполнить командлет: Import-Module ActiveDirectory
2) Чтобы создать учётную запись MSA нужно выполнить командлет:
New-ADServiceAccount serviceaccount –RestrictToSingleComputer
где serviceaccount – имя учетной записи MSA
RestrictToSingleComputer – параметр означает, что MSA будет привязан только к одному серверу.
Можно зайти в Active Directory Users and Computers и убедиться, что MSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

3) Чтобы привязать MSA к серверу нужно выполнить командлет:
Add-ADComputerServiceAccount -Identity server -ServiceAccount serviceaccount
где server – имя сервера, который будет соотнесён с MSA
serviceaccount – имя учетной записи MSA
Чтобы проверить, что операция выполнена успешно, нужно зайти в оснастку Active Directory Users and Computers, перейти в свойства сервера и посмотреть атрибут msDS-HostServiceAccount

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:
Install-ADServiceAccount -Identity serviceaccount
где serviceaccount – имя учетной записи MSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:
Test-ADServiceAccount serviceaccount
где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени MSA и перезапустить службу.
В конце имени MSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Проверим с помощью утилиты gsecdump пароль для учётной записи службы

В Windows Server 2012 появились Групповые управляемые учетные записи служб (Group Managed Service Accounts).
Они позволяют привязывать управляемую учетную запись не к одному серверу, а к нескольким.
Это может потребоваться, например, для использования в службе балансировки сетевой нагрузки.

Уровень схемы – Windows Server 2012
Контроллер домена Windows Server 2012 (R2) на котором запущена служба Microsoft Key Distribution Service
Windows Server 2012, 2012 R2, 8, 8.1
Модуль администрирования Active Directory для PowerShell

Можно зайти в Active Directory Users and Computers и убедиться, что gMSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:
Install-ADServiceAccount -Identity serviceaccount
где serviceaccount – имя учетной записи gMSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:
Test-ADServiceAccount serviceaccount
где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени gMSA и перезапустить службу.
В конце имени gMSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Проверим с помощью утилиты gsecdump пароль для учётной записи службы

Удалить MSA/gMSA можно с помощью командлета Uninstall-ADServiceAccount

Задавать параметры MSA/gMSA можно с помощью командлета Set-ADServiceAccount
Задание периода смены пароля:
Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60
где serviceaccount – имя учетной записи gMSA
60 – период, через который сменится пароль
Задание криптоалгоритмов Kerberos для использования MSA
Варианты: RC4, AES128, AES256
Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256
Задание SPN
Set-ADServiceAccount serviceaccount -ServicePrincipalNames @

Задание NetBIOS имени для сервиса (SAMAccountName)
Если не задано, используется идентификатор Name
Если задано, имя отображения в AD будет из Name, а идентификатор для логина из SAMAccountName
Set-ADServiceAccount serviceaccount –SamAccountName test

Есть способ, который позволяет узнать пароль администратора в случае, если какая-либо служба запускается от его имени.
Пароли учетных записей, от которых запускаются службы Windows, хранятся в зашифрованном виде в реестре (LSA Secrets) по пути:

HKEY_LOCAL_MACHINE/Security/Policy/Secrets

Скопировать путь реестра во временный путь, а затем расшифровать зашифрованные пароли

Использовать теневые копии

Использовать специальные утилиты для работы с процессом lsass.exe

Воспользуемся утилитой gsecdump для извлечения паролей.
Запустим PowerShell от имени администратора и выполним команду: gsecdump-v2b5.exe -l
Результат:

Автоматическая смена паролей. По умолчанию смена пароля – раз в 30 дней

Сложный пароль. Используется комплексный автоматически генерируемый пароль из 240 символов в случайном порядке (первая половина — буквы английского алфавита, вторая половина — цифры и другие символы)

Отсутствие избыточных прав

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

Управление SPN

Включение MSA в PowerShell
1) Выполнить командлет: Import-Module ActiveDirectory
2) Чтобы создать учётную запись MSA нужно выполнить командлет:
New-ADServiceAccount serviceaccount –RestrictToSingleComputer
где serviceaccount – имя учетной записи MSA
RestrictToSingleComputer – параметр означает, что MSA будет привязан только к одному серверу.
Можно зайти в Active Directory Users and Computers и убедиться, что MSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

3) Чтобы привязать MSA к серверу нужно выполнить командлет:
Add-ADComputerServiceAccount -Identity server -ServiceAccount serviceaccount
где server – имя сервера, который будет соотнесён с MSA
serviceaccount – имя учетной записи MSA
Чтобы проверить, что операция выполнена успешно, нужно зайти в оснастку Active Directory Users and Computers, перейти в свойства сервера и посмотреть атрибут msDS-HostServiceAccount

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:
Install-ADServiceAccount -Identity serviceaccount
где serviceaccount – имя учетной записи MSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:
Test-ADServiceAccount serviceaccount
где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени MSA и перезапустить службу.
В конце имени MSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Проверим с помощью утилиты gsecdump пароль для учётной записи службы

В Windows Server 2012 появились Групповые управляемые учетные записи служб (Group Managed Service Accounts).
Они позволяют привязывать управляемую учетную запись не к одному серверу, а к нескольким.
Это может потребоваться, например, для использования в службе балансировки сетевой нагрузки.

Уровень схемы – Windows Server 2012

Контроллер домена Windows Server 2012 (R2) на котором запущена служба Microsoft Key Distribution Service

Windows Server 2012, 2012 R2, 8, 8.1

Модуль администрирования Active Directory для PowerShell

Можно зайти в Active Directory Users and Computers и убедиться, что gMSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:
Install-ADServiceAccount -Identity serviceaccount
где serviceaccount – имя учетной записи gMSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:
Test-ADServiceAccount serviceaccount
где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени gMSA и перезапустить службу.
В конце имени gMSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Проверим с помощью утилиты gsecdump пароль для учётной записи службы

Удалить MSA/gMSA можно с помощью командлета Uninstall-ADServiceAccount

Задавать параметры MSA/gMSA можно с помощью командлета Set-ADServiceAccount
Задание периода смены пароля:
Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60
где serviceaccount – имя учетной записи gMSA
60 – период, через который сменится пароль
Задание криптоалгоритмов Kerberos для использования MSA
Варианты: RC4, AES128, AES256
Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256
Задание SPN
Set-ADServiceAccount serviceaccount -ServicePrincipalNames @

Задание NetBIOS имени для сервиса (SAMAccountName)
Если не задано, используется идентификатор Name
Если задано, имя отображения в AD будет из Name, а идентификатор для логина из SAMAccountName
Set-ADServiceAccount serviceaccount –SamAccountName test

Читайте также:


Как установить виндовс 7 без драйверов

Как отключить анимацию mac os

Rsync примеры синхронизации windows

Как добавить на рабочий стол мой компьютер на windows 10

Windows 95 сколько дискет