Проверка подлинности и шифрование данных в Operations Manager

Важно!

Поддержка этой версии Operations Manager завершена. Рекомендуется выполнить обновление до Operations Manager 2022.

System Center Operations Manager состоит из таких компонентов, как сервер управления, сервер шлюза, сервер отчетов, рабочая база данных, хранилище данных отчетов, агент, веб-консоль и консоль управления. В этой статье объясняется, как выполняется проверка подлинности, и определены каналы подключения, в которых шифруются данные.

Проверка подлинности на основе сертификатов

Если агент и сервер управления Operations Manager разделены границей недоверенного леса или рабочей группы, необходимо реализовать проверку подлинности на основе сертификатов. В разделах ниже приводятся сведения об таких ситуациях и процедурах получения и установки сертификатов от центров сертификации Windows.

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

Агент и сервер управления используют проверку подлинности Windows для взаимной проверки подлинности перед тем, как сервер принимает данные от агента. По умолчанию для проверки подлинности используется протокол Kerberos версии 5. Чтобы взаимная проверка подлинности на базе Kerberos работала, агенты и сервер управления должны быть установлены в домене Active Directory. Если агент и сервер управления находятся в разных доменах, между ними должны существовать отношения полного доверия. В этом сценарии после взаимной проверки подлинности выполняется шифрование канала связи между агентом и сервером управления. Для активации проверки подлинности и шифрования вмешательство пользователя не требуется.

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

Агент (или агенты) могут быть развернуты в домене (домене Б), отличном от домена сервера управления (домен A), и между этими доменами может не быть двусторонних отношений доверия. Так как между двумя доменами нет доверия, агенты в одном домене не могут пройти проверку подлинности на сервере управления в другом домене по протоколу Kerberos. Взаимная проверка подлинности между компонентами Operations Manager в рамках одного домена по-прежнему происходит без изменений.

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

Иллюстрация монитора недоверенного агента со шлюзом.

Настройка обмена данными внутри домена — граница рабочей группы

В рабочей группе внутри межсетевого экрана может быть развернут один или два агента. Агент в рабочей группе не может пройти проверку подлинности на сервере управления в домене по протоколу Kerberos. Решением будет установка сертификатов на компьютере с агентом и сервере управления, к которому подключается агент. См. иллюстрацию ниже.

Примечание

В этом сценарии агент должен быть установлен вручную.

Иллюстрация монитора недоверенного агента в рабочей группе.

Выполните следующие действия на компьютере с агентом и сервере управления, используя один и тот же ЦС.

  1. Запросите сертификат в ЦС.
  2. Утвердите запросы сертификатов в ЦС.
  3. Установите утвержденные сертификаты в хранилищах сертификатов компьютера.
  4. Используйте средство MOMCertImport для настройки Operations Manager.

Примечание

Сертификаты с KEYSPEC, отличные от 1, не поддерживаются.

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

Подтверждение установки сертификата

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

Тип Источник Идентификатор события Общие сведения
Сведения Соединитель Operations Manager 20053 Соединитель Operations Manager успешно загрузил сертификат проверки подлинности.

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings

Внимание!

Неправильное изменение реестра может вызвать серьезные проблемы. Перед внесением изменений следует сделать резервную копию всех ценных данных на компьютере.

Проверка подлинности и шифрование данных между сервером управления, сервером шлюза и агентами

Обмен данными между этими компонентами Operations Manager начинается с взаимной проверки подлинности. Если сертификаты присутствуют на обеих сторонах канала связи, они будут использованы для взаимной проверки подлинности. В противном случае будет применяться протокол Kerberos версии 5. Если любые два компонента разделены границами доверия, для взаимной проверки подлинности используются сертификаты. Обычный обмен данными, например события, предупреждения и развертывание пакета управления выполняется через этот канал. На предыдущей иллюстрации приводится пример предупреждения, выданного одним из агентов, которые связаны сервером управления. Между агентом и сервером шлюза для шифрования применяется пакет безопасности Kerberos, поскольку сервер шлюза и агент находятся в одном домене. Предупреждение шифруется сервером шлюза и расшифровывается с помощью сертификатов на сервере управления. Сервер шлюза отправляет зашифрованное сообщение на сервер управления, где предупреждение расшифровывается. Некоторые операции обмена данными между сервером управления могут включать учетные данные, например данные конфигурации и задачи. Канал передачи данных между агентами и сервером управления добавляет дополнительный уровень шифрования к обычному шифрованию канала. Вмешательство пользователя не требуется.

Сервер управления и консоль управления, сервер веб-консоли и сервер отчетов

Проверка подлинности и шифрование данных между сервером управления и консолью управления, сервером веб-консоли или сервером отчетов выполняется с помощью технологии WCF. Первая попытка проверки подлинности предпринимается с использованием учетных данных пользователя. Сначала система пытается применить протокол Kerberos. Если протокол Kerberos не работает, выполняется другая попытка с помощью NTLM. Если проверка подлинности снова не удается, система просит пользователя ввести учетные данные. После проверки подлинности поток данных шифруется как функция протокола Kerberos или SSL, если используется NTLM.

В случае сервера отчетов и сервера управления после проверки подлинности устанавливается подключение для передачи данных между сервером управления и сервером отчетов SQL Server. Для этого используется только протокол Kerberos, поэтому сервер управления и сервер отчетов должны находиться в доверенных доменах. Дополнительные сведения о WCF см. в статье MSDN Что такое Windows Communication Foundation.

Сервер управления и хранилище данных отчетов

Между сервером управления и хранилищем данных отчетов существует два канала связи.

  • Процесс наблюдения за узлами, созданный службой работоспособности (служба управления System Center) на сервере управления
  • Службы доступа к данным System Center на сервере управления

Процесс наблюдения за узлами и хранилище данных отчетов

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

Если хранилище данных отчетов и сервер управления разделены границей доверия (например, каждый из них находится в разных доменах без доверия), встроенная проверка подлинности Windows не будет работать. Чтобы обойти эту проблему, процесс наблюдения за узлами может подключиться к хранилищу данных отчетов с помощью проверки подлинности SQL Server. Для этого следует создать новую учетную запись запуска от имени (обычную) с учетными данными учетной записи SQL и сделать ее участником профиля запуска от имени, который называется учетной записью проверки подлинности SQL Server для хранилища данных, указав сервер управления в качестве целевого компьютера.

Важно!

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

В следующем разделе описываются взаимоотношения между различными учетными данными, учетными записями запуска от имени и профилями запуска от имени для встроенной проверки подлинности Windows и проверки подлинности SQL Server.

По умолчанию: Встроенная проверка подлинности Windows

  1. Профиль запуска от имени: Учетная запись хранилища данных

    • Учетная запись запуска от имени: действие хранилища данных
    • Учетные данные учетной записи: учетная запись для записи данных (указывается при установке)
  2. Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для хранилища данных

    • Учетная запись запуска от имени: учетная запись проверки подлинности SQL Server для хранилища данных
    • Учетные данные учетной записи: специальная учетная запись, созданная Operations Manager (не изменяйте)

Необязательно: Проверка подлинности SQL Server

  1. Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для хранилища данных
    • Учетная запись запуска от имени: создаваемая учетная запись запуска от имени.
    • Учетные данные учетной записи: учетная запись, указанная во время установки.

Служба доступа к данным System Center и хранилище данных отчетов

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

Если хранилище данных отчетов и сервер управления разделены границей доверия (например, каждый из них находится в разных доменах без доверия), встроенная проверка подлинности Windows не будет работать. Чтобы обойти эту проблему, служба доступа к данным System Center подключается к хранилищу данных отчетов, используя проверку подлинности SQL Server. Для этого следует создать новую учетную запись запуска от имени (обычную) с учетными данными учетной записи SQL и сделать ее участником профиля запуска от имени, который называется учетной записью проверки подлинности SQL Server для отчетов службы SDK, указав сервер управления в качестве целевого компьютера.

Важно!

По умолчанию профилю запуска от имени "Учетная запись проверки подлинности SQL Server для отчетов службы SDK" назначается особая учетная запись с помощью учетной записи запуска от имени с таким же именем. Никогда не изменяйте учетную запись, связанную с профилем запуска от имени, пакетом SDK для отчетов SQL Server учетной записью проверки подлинности. Вместо этого при настройке проверки подлинности SQL Server следует создать новую учетную запись и учетную запись запуска от имени и сделайте учетную запись запуска от имени участником профиля "Учетная запись проверки подлинности SQL Server для отчетов службы SDK".

В следующем разделе описываются взаимоотношения между различными учетными данными, учетными записями запуска от имени и профилями запуска от имени для встроенной проверки подлинности Windows и проверки подлинности SQL Server.

По умолчанию: Встроенная проверка подлинности Windows

  1. Учетная запись службы доступа к данным и службы настройки (задается при установке Operations Manager)

    • Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для отчетов службы SDK
    • Учетная запись запуска от имени: Учетная запись проверки подлинности SQL Server для отчетов службы SDK
    • Учетные данные учетной записи: специальная учетная запись, созданная Operations Manager (не изменяйте)
  2. Необязательно: Проверка подлинности SQL Server

    • Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для хранилища данных
    • Учетная запись запуска от имени: создаваемая учетная запись запуска от имени.
    • Учетные данные учетной записи: учетная запись, указанная во время установки.

Консоль управления и сервер отчетов

Консоль управления подключается к серверу отчетов по протоколу HTTP через порт 80. Проверка подлинности выполняется с помощью проверки подлинности Windows. Данные можно зашифровать с помощь канала SSL.

Сервер отчетов и хранилище данных отчетов

Для проверки подлинности между сервером отчетов и хранилищем данных отчетов используется проверка подлинности Windows. Учетная запись, указанная в качестве учетной записи для чтения данных при установке модуля создания отчетов, становится учетной записью выполнения сервера отчетов. Если пароль для учетной записи должен измениться, необходимо изменить пароль с помощью Reporting Services Configuration Manager в SQL Server. Данные между сервером отчетов и хранилищем данных отчетов не шифруются.