Учетные записи службы

Учетные записи действия

В System Center Operations Manager на всех серверах управления, серверах шлюзов и агентах выполняется процесс MonitoringHost.exe. Процесс MonitoringHost.exe выполняет действия мониторинга, например запуск монитора или задачи. Кроме того, процесс MonitoringHost.exe может выполнять такие действия:

наблюдение и сбор данных журнала событий Windows;
наблюдение и сбор данных счетчика производительности Windows;
наблюдение и сбор данных инструментария управления Windows (WMI);
выполнение таких действий как сценарии или пакеты.

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

Если действие не связано с профилем запуска от имени, то для выполнения этого действия используются учетные данные по умолчанию, заданные для учетной записи действия. Дополнительные сведения об учетных записях и профилях запуска от имени см. в разделе Учетные записи запуска от имени. При запуске агентом действия от имени учетной записи действия по умолчанию и (или) учетных записей запуска от имени для каждой учетной записи создается новый экземпляр процесса MonitoringHost.exe.

При установке Operations Manager вы можете выбрать учетную запись домена или использовать учетную запись LocalSystem. Более безопасный подход — указать учетную запись домена, которая позволяет выбрать пользователя с минимальными необходимыми привилегиями для вашей среды.

Вы можете использовать учетную запись с низким уровнем привилегий в качестве учетной записи действия агента. На компьютерах с операционной системой Windows Server 2008 R2 или более поздней версии у такой учетной записи должны быть следующие минимальные привилегии:

быть членом локальной группы «Пользователи»;
быть членом локальной группы «Пользователи системного монитора»;
разрешение «Локальный вход в систему» (SetInteractiveLogonRight) (неприменимо для Operations Manager 2019 и более поздней версии).

Примечание

Минимальные привилегии, описанные выше — это самый низкий уровень привилегий, поддерживаемых Operations Manager для учетной записи действия. У других учетных записей запуска от имени могут быть привилегии более низкого уровня. Фактические привилегии, необходимые для учетной записи действия и учетных записей запуска от имени, зависят от того, какие пакеты управления запущены на компьютеры и как они настроены. Дополнительные сведения о требуемых привилегиях см. в руководстве соответствующего пакета управления.

Учетной записи домена, указанной для учетной записи действия, можно предоставить разрешение «Вход в качестве службы» (SeServiceLogonRight) или «Вход в качестве пакетной службы» (SeBatchLogonRight), если политика безопасности не разрешает создавать для учетной записи службы сеансы интерактивного входа в систему, при которых требуется, например, проверка подлинности с помощью смарт-карты. Измените значение реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service:

Учетная запись домена, указанная для учетной записи действия, предоставляется с помощью разрешения «Вход в качестве службы» (SeServiceLogonRight). Для изменения типа входа для службы работоспособности измените значение реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service:

Имя: Worker Process Logon Type
Тип: REG_DWORD

Этим значением можно управлять с помощью групповой политики. Для этого скопируйте с сервера управления или из управляемой агентом системы ADMX-файл , находящийся в папке , и настройте параметр Тип входа учетной записи действия мониторинга в папке . Дополнительные сведения см. в статье об управлении ADMX-файлами групповой политики.

Сертификаты в проверка подлинности Windows

Инфраструктура открытых ключей (PKI) — это сочетание программного обеспечения, технологий шифрования, процессов и служб, которые позволяют организации защищать связь и бизнес-транзакции. Возможность PKI для защиты обмена данными и бизнес-транзакций основана на обмене цифровыми сертификатами между прошедшими проверку подлинности пользователями и доверенными ресурсами.

Цифровой сертификат — это электронный документ, содержащий сведения о сущности, к которой он принадлежит, сущность, которой она была выдана, уникальный серийный номер или другие уникальные даты идентификации, выдачи и окончания срока действия, а также цифровой отпечатк.

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

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

Аналогичным образом удаленный узел или локальный компьютер должны определить, является ли сертификат, представленный пользователем или приложением, аутентичным. Сертификат, представленный пользователем через LSA и SSPI, оценивается для проверки подлинности на локальном компьютере для локального входа в систему, в сети или в домене через хранилища сертификатов в Active Directory.

Чтобы создать сертификат, данные проверки подлинности передаются через хэш-алгоритмы, такие как безопасный хэш-алгоритм 1 (SHA1), для создания дайджеста сообщения. Затем дайджест сообщения подписывается цифровой подписью с помощью закрытого ключа отправителя, чтобы доказать, что дайджест сообщения был создан отправителем.

Примечание

SHA1 — это значение по умолчанию в Windows 7 и Windows Vista, но в Windows 8 было изменено на SHA2.

Аутентификация по смарт-карте

Технология смарт-карт является примером проверки подлинности на основе сертификатов. Вход в сеть с помощью смарт-карты обеспечивает надежную форму проверки подлинности, так как она использует идентификацию на основе шифрования и подтверждение владения при проверке подлинности пользователя в домене. Службы сертификатов Active Directory (AD CS) предоставляют криптографическую идентификацию с помощью выдачи сертификата входа для каждой смарт-карты.

Сведения о проверке подлинности смарт-карт см. в техническом справочнике по Windows смарт-картам.

Технология виртуальной смарт-карты появилась в Windows 8. Он сохраняет сертификат смарт-карты на компьютере, а затем защищает его с помощью микросхемы безопасности доверенного платформенного модуля (TPM) устройства. Таким образом, компьютер фактически становится смарт-картой, которая должна получать ПИН-код пользователя для проверки подлинности.

Удаленная и беспроводная проверка подлинности

Удаленная и беспроводная проверка подлинности сети — это другая технология, которая использует сертификаты для проверки подлинности. Служба проверки подлинности Интернета (IAS) и серверы виртуальной частной сети используют расширяемую проверку подлинности Protocol-Transport уровня безопасности (EAP-TLS), защищенный расширяемый протокол проверки подлинности (PEAP) или протокол IPsec для проверки подлинности на основе сертификатов для многих типов сетевого доступа, включая виртуальную частную сеть (VPN) и беспроводные подключения.

Сведения о проверке подлинности на основе сертификатов в сети см. в разделе «Проверка подлинности и сертификаты сетевого доступа».

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

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

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

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

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

Порядок использования данного метода см. в статье Удаление учетной записи компьютера с помощью интерфейса Windows и Управление различными доменами в центре администрирования Active Directory.
Метод 2: drsm

Порядок использования данного метода см. в статье Удаление учетной записи компьютера с помощью командной строки.
Метод 3: командлет Remove-ADPrincipalGroupMembership в Windows PowerShell Active Directory

Подробные сведения о том, как это сделать, см. в разделе Remove-ADPrincipalGroupMembership в библиотеке TechNet или путем ввода командной строки Get-Help Remove-ADPrincipalGroupMembership в модуле Active Directory для Windows PowerShell командной строки и нажатия клавиши ВВОД.

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

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

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

На контроллере домена Windows Server 2012 запустите Windows PowerShell на панели задач.
Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Строка> Get-ADServiceAccount <-Properties PrincipalsAllowedToRetrieveManagedPassword
Введите следующие команды в командной строке Windows PowerShell и нажмите клавишу ВВОД:

Строка> Set-ADServiceAccount <-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>

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

Пример

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

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

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

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

Зачем нужны MSA

Изначально в Windows NT такого понятия, как “специальный вид учётной записи для приложения-сервиса” не существовало. Была системная учётка , которая олицетворяла собой Одина, Будду, Ктулху и прочих интересных личностей в одном флаконе. Эта учётная запись была неявно включена в и обладала всеми правами на системе, которые могут быть – ну а если чем-то не обладала, так от её лица можно было сделать на любом объекте, имеющем ACL, и в результате всё ж обладать всеми правами. От этой учётки работали все системные процессы, а также запускались сервисы – но подчеркну, сделана она была не именно для запуска сервисов, а чтобы олицетворять “всю систему”.

Вы могли запускать сервисы как от неё, так и от обычной учётной записи пользователя – это менялось в настройках примерно так же, как меняется сейчас:

Пример сервиса, запускающегося от учётной записи SYSTEM(кликните для увеличения до 406 px на 468 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

Вроде как всё хорошо, но на самом деле – проблемы.

Первая и очевидная состояла в небезопасности выдачи всех-всех-всех прав в системе любому приложению, которому надо было запускаться на фоне. Допустим, берём сервис DHCP Client. Что ему нужно от системы? Возможность доступа к сети, притом небольшую совсем, да возможность записи конфигурации в некоторые ветки реестра (где хранятся настройки сетевых интерфейсов). Всё, что он делает – обменивается несколькими видами ethernet-кадров, да пишет Надо ли ему доступ ко всем данным на всех дисках? К созданию пользователей и смене прав? К раздаче системных привилегий типа “shut down from remote system”? Нет конечно, зачем. Но всё это выдаётся, если работаешь от .

Вторая состояла в том, что даже если заводишь специальную учётную запись пользователя, от имени которой запускаешь этот сервис, то возникает новая пачка проблем, в том числе:

Надо старательно выдать этой учётной записи только минимально нужные для этой операции права и запретить изначально разрешаемые ей, но не нужные в данном сценарии использования (например, запретить сетевой вход);
Надо периодически менять у этой учётной записи пароль, а также сделать его стойким;
Пароль к этой учётной записи будет храниться в системе в виде открытого текста (надо ж при запуске сервиса сымитировать log on as a service, поэтому надо предоставить связку логин-пароль в исходном варианте);
Пароль может использоваться в нескольких местах (например, когда данная служба на нескольких серверах работает), и доступ к нему возможен на любом из этих серверов от любой учётной записи с правами локального администратора;

Всё это неудобно, небезопасно, заставляет тратить лишнее время, и зачастую сводится к “разово сделаем пароль, поставим галочку, чтобы мозг не конопатил, выдадим права локального админа этой учётке и забудем”.

Managed Service Accounts – MSA (я буду говорить уже именно про новые, gMSA, появившиеся в Windows Server 2012, новая буква g – это Group) – позволяют решить все эти проблемы.

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

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

Откройте консоль
Откройте свойства запрашиваемой услуги и перейдите во вкладку Login;
Выберите параметр «Эта учетная запись» и введите имя учетной записи MSA. В конце имени должен быть указан символ $ (пароль указывать не обязательно);
Учетной записи службы MSA автоматически будут предоставлены права доступа в качестве службы;
После сохранения изменений необходимо перезапустить службу.

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

Получение информации

1. Список всех групп

Без фильтра:

Get-AdGroup -filter *

С фильтром:

Get-AdGroup -filter * | Where {$_.name -like «*free*»} | fl name

* будут выбраны все группы, в названии которых встречается free.

2. Подробная информация о группе

Get-ADGroup «Domain Users» -Properties *

* где ключ -Properties * покажет информацию о всех атрибутах группы.

Показать только SID и GUID группы:

Get-ADGroup «Domain Admins» | ft ObjectGUID, SID

3. Посмотреть членов группы

Перечень членов групп с базовой информацией о каждом пользователе:

Get-ADGroupMember -Identity Administrators

Вывести на экран только имена пользователей:

Get-ADGroupMember -Identity Administrators | ft name

Рекурсивный запрос:

Get-ADGroupMember -Identity Administrators -Recursive | ft name

* в данном примере используется ключ Recursive — это позволяет вывести на экран не только членов группы Administrators, но и членов групп, которые входят в эту группу.

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

Get-ADGroupMember -Identity «Users» | foreach { Get-ADUser $_ -Properties * }

Расчет выполняется методом Count:

(Get-ADGroupMember -Identity Administrators).Count

5. В каких группах состоит пользователь

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

Get-ADUser Administrator -Properties Memberof | Select -ExpandProperty memberOf

6. Список пустых групп

Имеются ввиду группы, в которых нет ни одного пользователя:

Get-ADGroup -filter * | where {-Not ($_ | Get-ADGroupMember)} | Select Name

7. Cписок пользователей, которые не входят в конкретную группу

Get-ADuser -Filter * -Properties MemberOf | where { -Not ($_.MemberOf -match «Managers») } | Select Name

* в данном примере мы увидем список пользователей, которые не входят в группу Managers.

Сценарий 2. Настройка ограниченного делегирования в учетной записи NetworkService

В этом разделе описывается реализация ограниченного делегирования S4U2Proxy или Kerberos только при использовании учетной записи NetworkService для страниц прокси-сервера регистрации в Интернете.

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

Вы можете назначить имя роли веб-регистрации, которую клиенты могут использовать для подключения. Эта конфигурация означает, что входящие запросы не должны знать имя компьютера интерфейсного сервера регистрации в Интернете или другие сведения о маршрутизации, такие как каноническое имя DNS (CNAME).

Например, предположим, что имя компьютера сервера веб-регистрации — WEBENROLLMAC (в домене Contoso). Вместо этого входящие подключения должны использовать имя ContosoWebEnroll. В этом случае URL-адрес подключения будет следующим:

Это не будет следующим образом:

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

В файле зоны DNS для домена создайте запись псевдонима или имя узла, которая сопоставляет новое имя подключения с IP-адресом роли веб-регистрации. Используйте средство проверки связи для проверки конфигурации маршрутизации.

В приведенном выше примере файл зоны содержит запись псевдонима, которая сопоставляет ContosoWebEnroll с IP-адресом роли веб-регистрации.
Настройте новое имя в качестве имени субъекта-службы для интерфейсного сервера веб-регистрации. Для этого выполните следующие действия:
1. В Пользователи и компьютеры Active Directory подключитесь к домену и выберите «Компьютеры».
2. Щелкните правой кнопкой мыши учетную запись компьютера интерфейсного сервера веб-регистрации и выберите пункт «Свойства».
  
  Примечание.
  
  Эта учетная запись также называется «учетной записью компьютера».
3. ВыберитеservicePrincipalName редактора атрибутов.>
4. Введите HTTP/<ConnectionName>.<DomainName.com, нажмите>кнопку «Добавить» и нажмите кнопку «ОК».
  
  Примечание.
  
  В этой строке <ConnectionName> — это новое имя, которое вы определили, < а DomainName> — имя домена.
  В этом примере строка — HTTP/ContosoWebEnroll.contoso.com.

1. Настройка делегирования

Если вы еще не подключились к домену, сделайте это сейчас в Пользователи и компьютеры Active Directory выберите «Компьютеры».
Щелкните правой кнопкой мыши учетную запись компьютера интерфейсного сервера веб-регистрации и выберите пункт «Свойства».

Примечание.

Эта учетная запись также называется «учетной записью компьютера».
Выберите «Делегирование», а затем выберите «Доверять этому компьютеру для делегирования только указанным службам».

Примечание.

Если вы можете гарантировать, что клиенты всегда будут использовать проверку подлинности Kerberos при подключении к этому серверу, выберите «Использовать только Kerberos».
Если некоторые клиенты будут использовать другие методы проверки подлинности, например NTLM или проверку подлинности на основе форм, выберите «Использовать любой протокол проверки подлинности».

2. Создание и привязка SSL-сертификата для веб-регистрации

Чтобы включить страницы веб-регистрации, создайте сертификат домена для веб-сайта, а затем привяжете его к первому сайту по умолчанию. Для этого выполните следующие действия:

Откройте диспетчер IIS.
В дереве консоли выберите HostName><, а затем выберите сертификаты сервера в области действий.

Примечание.

<Узла> — это имя интерфейсного веб-сервера.
В меню «Действия » выберите «Создать сертификат домена».
После создания сертификата выберите веб-сайт по умолчанию, а затем выберите «Привязки».
Убедитесь, что для порта задано значение 443. Затем в разделе SSL-сертификата выберите сертификат, созданный на шаге 3. Нажмите кнопку » ОК», чтобы привязать сертификат к порту 443.

Локальная система безопасности

Локальный центр безопасности (LSA) — это защищенный системный процесс, который проверяет подлинность и регистрирует пользователей на локальном компьютере. Кроме того, LSA поддерживает сведения обо всех аспектах локальной безопасности на компьютере (эти аспекты совместно называются локальной политикой безопасности), а также предоставляет различные службы для перевода имен и идентификаторов безопасности (SID). Процесс системы безопасности, служба сервера локального центра безопасности (LSASS), отслеживает политики безопасности и учетные записи, которые применяются в компьютерной системе.

LSA проверяет удостоверение пользователя на основе того, какие из следующих двух сущностей выдали учетную запись пользователя:

Местный центр безопасности. LSA может проверить сведения о пользователе, проверив базу данных диспетчера учетных записей безопасности (SAM), расположенную на том же компьютере. Любые рабочие станции или члены сервера могут хранить локальные учетные записи пользователей и сведения о локальных группах. Однако эти учетные записи можно использовать для доступа только к этой рабочей станции или компьютеру.
Центр безопасности для локального домена или доверенного домена. LSA обращается к сущности, выдавшей учетную запись, и запрашивает проверку того, что учетная запись действительна и что запрос поступил от владельца учетной записи.

Служба LSASS сохраняет в памяти учетные данные пользователей с активными сеансами Windows. Сохраненные учетные данные позволяют пользователям легко получать доступ к сетевым ресурсам, таким как общие папки, Exchange Server почтовые ящики и SharePoint сайты, не вводя учетные данные для каждой удаленной службы.

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

Зашифрованный обычный текст с возможностью дешифровки
Билеты Kerberos (билеты на предоставление билетов (TGT), билеты на обслуживание)
NT-хэш
Хэш диспетчера локальной сети (LM)

Если пользователь входит в Windows с помощью смарт-карты, LSASS не сохраняет пароль открытого текста, но сохраняет соответствующее значение хэша NT для учетной записи и ПИН-код открытого текста для смарт-карты. Если для смарт-карты, необходимой для интерактивного входа, включается атрибут учетной записи, то для соответствующего профиля происходит автоматическая генерация произвольного NT-хэша, который используется вместо изначального хэша пароля. Хэш пароля, автоматически сгенерированный при установке атрибута, не изменяется.

Если пользователь входит на компьютер на основе Windows с паролем, совместимым с хэшами LAN Manager (LM), этот средство проверки подлинности присутствует в памяти.

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

Сохраненные учетные данные напрямую связаны с сеансами входа в систему службы подсистемы локального центра безопасности (LSASS), которые были запущены после последнего перезапуска и не были закрыты. Например, сеансы с сохраненными учетными данными LSA создаются, когда пользователь выполняет одно из следующих действий.

Вход в локальный сеанс или сеанс протокола удаленного рабочего стола (RDP) на компьютере
Запускает задание с помощью команды RunAs
Запускает на компьютере активную службу Windows
Запускает назначенное или пакетное задание
Запускает на локальном компьютере задание с помощью средства удаленного администрирования.

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

Пароль учетной записи для учетной записи доменные службы Active Directory компьютера (AD DS)
Пароли учетных записей служб Windows, настроенных на компьютере
Пароли учетных записей настроенных назначенных заданий
Пароли учетных записей для пулов приложений IIS и веб-сайтов.
Пароли для учетных записей Майкрософт

Представленная в Windows 8.1, клиентская операционная система обеспечивает дополнительную защиту для LSA, чтобы предотвратить чтение памяти и внедрения кода незащищенными процессами. Эта защита повышает безопасность учетных данных, которые LSA хранит и управляет ими.

Дополнительные сведения об этих дополнительных защитах см. в разделе «Настройка дополнительной защиты LSA».

Создание других учетных записей и групп MIM (при необходимости)

Если вы настраиваете SSPR для MIM, то, следуя вышеприведенным указаниям для службы синхронизации MIM и службы MIM, вы можете создать другие учетные записи gMSA для следующих компонентов:

пул приложений веб-сайта для сброса паролей MIM;
пул приложений веб-сайта для регистрации паролей MIM.

Если вы настраиваете PAM для MIM, то, следуя вышеприведенным указаниям для службы синхронизации MIM и службы MIM, вы можете создать другие учетные записи gMSA для следующих компонентов:

пул приложений веб-сайта REST API PAM для MIM;
служба компонентов PAM для MIM;
служба мониторинга PAM для MIM.

Единоразовая подготовка Active Directory

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

Чтобы проверить, был ли создан корневой ключ KDS, выполните следующий командлет PowerShell от имени администратора домена на контроллере домена или компьютере, который включен в домен, с помощью установленных средств PowerShell AD:

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

Важно!

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

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

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

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

Важно!

Не используйте этот способ в рабочей среде.

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

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

По умолчанию MSA и gMSA создаются в основном контейнере CN = Managed Service Account, но вы можете изменить OU с помощью параметра Path.

Свяжите свою учетную запись службы MSA с целевым компьютером:

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

Откройте консоль

(ADUC, пользователи и компьютеры Active Directory) и убедитесь, что новая учетная запись типа msDS-ManagedServiceAccount отображается в контейнере управляемых учетных записей служб (OU.

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

Информацию об учетной записи MSA можно получить с помощью команды:

Запуск службы от имени локального пользователя

Можно создать локального пользователя и использовать его для защиты службы в приложении. Если в разделе Principals манифеста приложения указан тип учетной записи LocalUser , платформа Service Fabric создает учетные записи локальных пользователей на компьютерах с развернутым приложением. По умолчанию эти учетные записи не соответствуют именам, указанным в манифесте приложения (например, Customer3 в следующем примере манифеста приложения). Вместо этого они создаются динамически и имеют случайные пароли.

В разделе RunAsPolicy для ServiceManifestImport укажите учетную запись из раздела Principals, с использованием которой нужно запустить пакет кода службы. В следующем примере показано, как создать локального пользователя и применить политику запуска от имени к главной точке входа.

Практическое применение

GMSA предоставляют единое решение для удостоверений для служб, работающих на ферме серверов, или в системах за сетевыми Load Balancer. Предоставляя решение gMSA, службы можно настроить для нового субъекта gMSA, а управление паролями осуществляется Windows.

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

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

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

Прежде чем вы начнете создавать учетную запись MSA / gMSA, вам необходимо выполнить одноразовую операцию по созданию корневого ключа KDS. Для этого на контроллере домена с правами администратора выполните команду (должны быть установлены и включены Microsoft Key Distribution Services):

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

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

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

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

Изменение учетных данных для учетной записи SQL Server Analysis Services, используемой Service Manager

Если учетная запись, используемая для изменения учетной записи SQL Server Analysis Services в Service Manager, необходимо также изменить учетные данные для учетной записи. Чтобы изменить учетные данные для учетной записи SQL Server Analysis Services, используйте следующую процедуру.

Изменение учетных данных для учетной записи SQL Server Analysis Services

На компьютере, на котором размещен сервер SQL Server Analysis Server (SSAS), откройте SQL Server Management Studio.
В диалоговом окне «Подключение к серверу » выполните следующие действия.
1. В списке «Тип сервера» щелкните «Службы Analysis Services».
2. В списке Имя сервера выберите имя сервера Service Manager или сервера баз данных хранилища данных.
3. В списке Проверка подлинности выберите пункт Проверка подлинности Windowsи нажмите кнопку Подключить.
В Microsoft SQL Server Management Studios в области обозреватель объектов разверните узел «Базы данных», разверните DWASDataBase, разверните источники данных и дважды щелкните DWDataMart.
В разделе «Свойства источника данных — DWDataMart» в разделе » Параметры безопасности» нажмите кнопку с многоточием (…) рядом с олицетворениямиAccount.
В окне «Сведения олицетворения» выберите «Использовать имя пользователя и пароль Windows», введите учетные данные для новой учетной записи и нажмите кнопку «ОК».
Нажмите кнопку «ОК», чтобы закрыть свойства источника данных — DWDataMart, а затем закройте Microsoft SQL Server Management Studio.