Проверка подлинности и шифрование данных в Operations Manager
System Center Operations Manager состоит из таких функций, как сервер управления, сервер шлюза, сервер отчетов, операционная база данных, хранилище данных отчетов, агент, веб-консоль и консоль управления. В этой статье объясняется, как выполняется проверка подлинности и определяет каналы подключения, в которых шифруются данные.
Проверка подлинности на основе сертификатов
Если агент Operations Manager и сервер управления разделены ненадежным лесом или границей рабочей группы, необходимо реализовать проверку подлинности на основе сертификатов. В разделах ниже приводятся сведения об таких ситуациях и процедурах получения и установки сертификатов от центров сертификации Windows.
Настройка связи между агентами и серверами управления в пределах одной границы доверия
Агент и сервер управления используют проверку подлинности Windows для взаимной проверки подлинности перед тем, как сервер принимает данные от агента. По умолчанию для проверки подлинности используется протокол Kerberos версии 5. Чтобы взаимная проверка подлинности на базе Kerberos работала, агенты и сервер управления должны быть установлены в домене Active Directory. Если агент и сервер управления находятся в разных доменах, между ними должны существовать отношения полного доверия. В этом сценарии после взаимной проверки подлинности выполняется шифрование канала связи между агентом и сервером управления. Для активации проверки подлинности и шифрования вмешательство пользователя не требуется.
Настройка взаимодействия между агентами и серверами управления через границы доверия
Агент (или агенты) могут быть развернуты в домене (домене Б), отличном от домена сервера управления (домен A), и между этими доменами может не быть двусторонних отношений доверия. Так как между двумя доменами нет доверия, агенты в одном домене не могут пройти проверку подлинности с помощью сервера управления в другом домене с помощью протокола Kerberos. Взаимная проверка подлинности между функциями Operations Manager в каждом домене по-прежнему возникает.
Решением может стать установка сервера шлюза в одном домене с агентами и установка сертификатов на сервер шлюза и сервер управления для взаимной проверки подлинности и шифрования данных. При использовании сервера шлюза необходим только один сертификат в домене Б и один порт брандмауэра, как показано на иллюстрации ниже.
Настройка связи между доменом — граница рабочей группы
В рабочей группе внутри межсетевого экрана может быть развернут один или два агента. Агент в рабочей группе не может пройти проверку подлинности с помощью сервера управления в домене с помощью протокола Kerberos. Решением будет установка сертификатов на компьютере с агентом и сервере управления, к которому подключается агент. См. иллюстрацию ниже.
Примечание.
В этом сценарии агент должен быть установлен вручную.
Выполните следующие действия на компьютере с агентом и сервере управления, используя один и тот же ЦС.
- Запросите сертификат в ЦС.
- Утвердите запросы сертификатов в ЦС.
- Установите утвержденные сертификаты в хранилищах сертификатов компьютера.
- Используйте средство MOMCertImport для настройки Operations Manager.
Примечание.
Сертификаты с ключами KEYPEC, отличные от 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, поскольку сервер шлюза и агент находятся в одном домене. Предупреждение шифруется сервером шлюза и расшифровывается с помощью сертификатов на сервере управления. Сервер шлюза отправляет зашифрованное сообщение на сервер управления, где предупреждение расшифровывается. Некоторые операции обмена данными между сервером управления могут включать учетные данные, например данные конфигурации и задачи. Канал передачи данных между агентами и сервером управления добавляет дополнительный уровень шифрования к обычному шифрованию канала. Вмешательство пользователя не требуется.
Сервер управления и консоль управления, сервер веб-консоли и сервер отчетов
Проверка подлинности и шифрование данных между сервером управления и консолью управления, сервером веб-консоли или сервером отчетов осуществляется с помощью технологии Windows Communication Foundation (WCF). Первая попытка проверки подлинности предпринимается с использованием учетных данных пользователя. Сначала система пытается применить протокол Kerberos. Если протокол Kerberos не работает, еще одна попытка выполняется с помощью NTLM. Если проверка подлинности снова не удается, система просит пользователя ввести учетные данные. После проверки подлинности поток данных шифруется как функция протокола Kerberos или SSL, если используется NTLM.
В случае сервера отчетов и сервера управления после проверки подлинности подключение к данным устанавливается между сервером управления и SQL Server Reporting 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
Профиль запуска от имени: Учетная запись хранилища данных
- Учетная запись запуска от имени: действие хранилища данных
- Учетные данные учетной записи: учетная запись записи данных (указанная во время установки)
Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для хранилища данных
- Учетная запись запуска от имени: проверка подлинности SQL Server хранилища данных
- Учетные данные учетной записи: специальная учетная запись, созданная Operations Manager (не изменяйте)
Необязательно: Проверка подлинности SQL Server
- Профиль запуска от имени: учетная запись проверки подлинности SQL Server хранилища данных
- Учетная запись запуска от имени: учетная запись запуска от имени, указанная во время установки.
- Учетные данные учетной записи: учетная запись, указанная во время настройки.
Служба доступа к данным System Center и хранилище данных отчетов
По умолчанию служба доступа к данным System Center, которая отвечает за чтение данных из хранилища данных отчетов и ее доступность в области параметров отчета, обеспечивает встроенную проверку подлинности Windows путем запуска в качестве учетной записи службы доступа к данным и службы конфигурации, определенной во время установки Operations Manager.
Если хранилище данных отчетов и сервер управления разделены границой доверия (например, каждый находится в разных доменах без доверия), то встроенная проверка подлинности Windows не будет работать. Чтобы обойти эту проблему, служба доступа к данным System Center подключается к хранилищу данных отчетов, используя проверку подлинности SQL Server. Для этого следует создать новую учетную запись запуска от имени (обычную) с учетными данными учетной записи SQL и сделать ее участником профиля запуска от имени, который называется учетной записью проверки подлинности SQL Server для отчетов службы SDK, указав сервер управления в качестве целевого компьютера.
Внимание
По умолчанию профилю запуска от имени "Учетная запись проверки подлинности SQL Server для отчетов службы SDK" назначается особая учетная запись с помощью учетной записи запуска от имени с таким же именем. Никогда не вносить изменения в учетную запись, связанную с профилем запуска от имени, учетной записью проверки подлинности SQL Server sql Server. Вместо этого при настройке проверки подлинности SQL Server следует создать новую учетную запись и учетную запись запуска от имени и сделайте учетную запись запуска от имени участником профиля "Учетная запись проверки подлинности SQL Server для отчетов службы SDK".
В следующем разделе описываются взаимоотношения между различными учетными данными, учетными записями запуска от имени и профилями запуска от имени для встроенной проверки подлинности Windows и проверки подлинности SQL Server.
По умолчанию: Встроенная проверка подлинности Windows
Учетная запись службы доступа к данным и службы настройки (задается при установке Operations Manager)
- Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для отчетов службы SDK
- Учетная запись запуска от имени: Учетная запись проверки подлинности SQL Server для отчетов службы SDK
- Учетные данные учетной записи: специальная учетная запись, созданная Operations Manager (не изменяйте)
Необязательно: Проверка подлинности SQL Server
- Профиль запуска от имени: Учетная запись проверки подлинности SQL Server для хранилища данных
- Учетная запись запуска от имени: учетная запись запуска от имени, указанная во время установки.
- Учетные данные учетной записи: учетная запись, указанная во время настройки.
Консоль управления и сервер отчетов
Консоль управления подключается к серверу отчетов по протоколу HTTP через порт 80. Проверка подлинности выполняется с помощью проверки подлинности Windows. Данные можно зашифровать с помощь канала SSL.
Сервер отчетов и хранилище данных отчетов
Для проверки подлинности между сервером отчетов и хранилищем данных отчетов используется проверка подлинности Windows. Учетная запись, указанная в качестве учетной записи для чтения данных при установке модуля создания отчетов, становится учетной записью выполнения сервера отчетов. Если пароль учетной записи должен измениться, необходимо изменить тот же пароль с помощью диспетчера конфигурации служб Reporting Services в SQL Server. Данные между сервером отчетов и хранилищем данных отчетов не шифруются.