Share via


Authentifizierung und Datenverschlüsselung in Operations Manager

Wichtig

Diese Version von Operations Manager hat das Ende des Supports erreicht. Es wird empfohlen, ein Upgrade auf Operations Manager 2022 durchzuführen.

System Center Operations Manager enthält Funktionen wie Verwaltungsserver, Gatewayserver, Berichtsserver, Betriebsdatenbank, Reporting-Data Warehouse, Agent, Webkonsole und Betriebskonsole. In diesem Artikel wird erläutert, wie die Authentifizierung durchgeführt wird, und es werden Verbindungskanäle identifiziert, in denen die Daten verschlüsselt werden.

Zertifikatbasierte Authentifizierung

Wenn ein Operations Manager-Agent und ein Verwaltungsserver durch eine nicht vertrauenswürdige Gesamtstruktur oder eine Arbeitsgruppengrenze getrennt sind, muss eine zertifikatbasierte Authentifizierung implementiert werden. In den folgenden Abschnitten finden Sie Informationen zu diesen Situationen sowie Verfahren zum Abrufen und Installieren von Zertifikaten von Windows-basierten Zertifizierungsstellen.

Einrichten der Kommunikation zwischen Agents und Verwaltungsservern innerhalb derselben Vertrauensgrenze

Ein Agent und der Verwaltungsserver verwenden die Windows-Authentifizierung, um sich gegenseitig zu authentifizieren, bevor der Verwaltungsserver Daten vom Agent akzeptiert. Das Kerberos-Protokoll (Version 5) ist die Standardmethode für die Authentifizierung. Damit eine Kerberos-basierte gegenseitige Authentifizierung möglich ist, müssen die Agents und der Verwaltungsserver in einer Active Directory-Domäne installiert sein. Befinden sich Agent und Verwaltungsserver in unterschiedlichen Domänen, muss volle Vertrauenswürdigkeit zwischen den Domänen bestehen. In diesem Szenario wird, sobald eine gegenseitige Authentifizierung erfolgt ist, der Datenkanal zwischen dem Agent und dem Verwaltungsserver verschlüsselt. Für die Authentifizierung und Verschlüsselung ist kein Benutzereingriff erforderlich.

Einrichten der Kommunikation zwischen Agents und Verwaltungsservern über Vertrauensgrenzen hinweg

Ein oder mehrere Agents werden möglicherweise in einer Domäne (Domäne B) bereitgestellt, die vom Verwaltungsserver (Domäne A) getrennt ist, und zwischen den beiden Domänen besteht möglicherweise keine bidirektionale Vertrauensstellung. Da zwischen den beiden Domänen keine Vertrauensstellung besteht, können sich die Agents in einer Domäne nicht mithilfe des Kerberos-Protokolls beim Verwaltungsserver in der anderen Domäne authentifizieren. Eine gegenseitige Authentifizierung zwischen den Operations Manager-Funktionen innerhalb jeder Domäne findet weiterhin statt.

Eine Lösung für dieses Problem besteht darin, einen Gatewayserver in der gleichen Domäne zu installieren, in der sich die Agents befinden, und dann Zertifikate auf dem Gatewayserver und dem Verwaltungsserver zu installieren, um eine gegenseitige Authentifizierung sowie eine Datenverschlüsselung zu erzielen. Bei Verwendung des Gatewayservers benötigen Sie nur ein Zertifikat in Domäne B und nur einen Port durch die Firewall hindurch (siehe folgende Abbildung).

Abbildung des Nicht vertrauenswürdigen Agents mit Gateway überwachen.

Einrichten der Kommunikation über Domänen- und Arbeitsgruppengrenzen hinweg

In Ihrer Umgebung gibt es möglicherweise Agents, die für eine Arbeitsgruppe innerhalb Ihrer Firewall bereitgestellt wurden. Der Agent in der Arbeitsgruppe kann sich nicht mithilfe des Kerberos-Protokolls beim Verwaltungsserver in der Domäne authentifizieren. Eine Lösung für dieses Problem besteht darin, Zertifikate sowohl auf dem Hostcomputer des Agents, als auch auf dem Verwaltungsserver, zu dem der Agent eine Verbindung herstellt, zu installieren (siehe nachfolgende Abbildung).

Hinweis

In diesem Szenario muss der Agent manuell installiert werden.

Abbildung des Nicht vertrauenswürdigen Agents überwachen in Workgroup.

Führen Sie sowohl auf dem Hostcomputer des Agents als auch auf dem Verwaltungsserver, der dieselbe Zertifizierungsstelle verwendet, die folgenden Schritte aus:

  1. Fordern Sie die erforderlichen Zertifikate von der Zertifizierungsstelle an.
  2. Genehmigen Sie die Zertifikatanforderungen bei der Zertifizierungsstelle.
  3. Installieren Sie die genehmigten Zertifikate in den Zertifikatspeichern der Computer.
  4. Verwenden Sie das MOMCertImport-Tool, um Operations Manager zu konfigurieren.

Hinweis

Zertifikate mit anderen KEYSPEC als 1 werden nicht unterstützt.

Dies sind die gleichen Schritte zum Installieren von Zertifikaten auf einem Gatewayserver, mit der Ausnahme, dass Sie das Gatewaygenehmigungstool nicht installieren oder ausführen.

Bestätigen der Zertifikatinstallation

Wenn Sie das Zertifikat ordnungsgemäß installiert haben, wird das folgende Ereignis in das Operations Manager-Ereignisprotokoll geschrieben.

type `Source` Ereignis-ID Allgemein
Information OpsMgr Connector 20053 Der OpsMgr Connector hat das angegebene Authentifizierungszertifikat erfolgreich geladen.

Bei der Einrichtung eines Zertifikats führen Sie das MOMCertImport-Tool aus. Wenn das MOMCertImport-Tool seine Arbeit beendet hat, wird die Seriennummer des importierten Zertifikats in den nachfolgenden Unterschlüssel der Registrierung geschrieben.

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

Achtung

Ein fehlerhaftes Bearbeiten der Registrierung kann eine schwerwiegende Beschädigung des Systems zur Folge haben. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie alle wichtigen Computerdaten sichern.

Authentifizierung und Datenverschlüsselung zwischen Verwaltungsserver, Gatewayserver und Agents

Zu Beginn der Kommunikation zwischen diesen Operations Manager-Funktionen erfolgt die gegenseitige Authentifizierung. Falls Zertifikate auf beiden Seiten des Kommunikationskanals vorliegen, werden diese Zertifikate für die gegenseitige Authentifizierung verwendet; andernfalls wird das Kerberos-Protokoll (Version 5) verwendet. Sind zwei der vorhandenen Funktionen über eine nicht vertrauenswürdige Domäne hinweg getrennt, muss eine gegenseitige Authentifizierung mithilfe von Zertifikaten erfolgen. Gängige Kommunikationsaktivitäten wie Ereignisse, Warnungen sowie die Bereitstellung eines Management Packs erfolgen über diesen Kanal. In der vorangehenden Abbildung finden Sie ein Beispiel für eine Warnung, die auf einem der Agents generiert und an den Verwaltungsserver weitergeleitet wird. Vom Agent zum Gatewayserver wird das Kerberos-Sicherheitspaket verwendet, um die Daten zu verschlüsseln, da sich der Gatewayserver und der Agent in der gleichen Domäne befinden. Die Warnung wird vom Gatewayserver entschlüsselt und mithilfe von Zertifikaten für den Verwaltungsserver erneut verschlüsselt. Der Gatewayserver sendet die verschlüsselte Nachricht an den Verwaltungsserver, der die Warnung entschlüsselt. Einige Kommunikationsaktivitäten zwischen dem Verwaltungsserver und dem Agent umfassen möglicherweise Anmeldeinformationen, beispielsweise Konfigurationsdaten und -tasks. Durch den Datenkanal zwischen dem Agent und dem Verwaltungsserver wird der normalen Kanalverschlüsselung eine weitere Verschlüsselungsschicht hinzugefügt. Es ist kein Benutzereingriff erforderlich.

Verwaltungsserver und Betriebskonsole, Webkonsolenserver sowie Berichtsserver

Die Authentifizierung und Datenverschlüsselung zwischen dem Verwaltungsserver und der Betriebskonsole, dem Webkonsolenserver oder dem Berichtsserver erfolgt mithilfe der WCF-Technologie (Windows Communication Foundation). Zunächst erfolgt ein Authentifizierungsversuch mithilfe der Anmeldeinformationen des Benutzers. Dieser wird zuerst mit dem Kerberos-Protokoll versucht. Wenn das Kerberos-Protokoll nicht funktioniert, wird ein weiterer Versuch mithilfe von NTLM unternommen. Schlägt die Authentifizierung weiterhin fehl, wird der Benutzer aufgefordert, die erforderlichen Anmeldeinformationen bereitzustellen. Nachdem die Authentifizierung erfolgt ist, wird der Datenstrom entweder als Funktion des Kerberos-Protokolls oder ssl verschlüsselt, wenn NTLM verwendet wird.

Bei einem Berichtsserver und einem Verwaltungsserver wird nach erfolgter Authentifizierung eine Datenverbindung zwischen dem Verwaltungsserver und dem SQL Server-Berichtsserver hergestellt. Hierbei wird ausschließlich das Kerberos-Protokoll verwendet; der Verwaltungsserver und der Berichtsserver müssen sich daher in vertrauenswürdigen Domänen befinden. Weitere Informationen zur WCF finden Sie im MSDN-Artikel Was ist die Windows Communication Foundation?

Verwaltungsserver und Reporting-Data Warehouse

Es gibt zwei Kommunikationskanäle zwischen einem Verwaltungsserver und dem Reporting-Data Warehouse:

  • Der vom Integritätsdienst (System Center-Verwaltungsdienst) auf einem Verwaltungsserver erzeugte überwachende Hostprozess
  • Die System Center Data Access-Dienste des Verwaltungsservers

Überwachender Hostprozess und Reporting-Data Warehouse

Standardmäßig erzielt der vom Integritätsdienst erzeugte überwachende Hostprozess, der für das Schreiben der gesammelten Ereignisse und Leistungsindikatoren in das Data Warehouse zuständig ist, die integrierte Windows-Authentifizierung, indem er als das beim Berichterstattungssetup angegebene Datenschreibkonto ausgeführt wird. Die Anmeldeinformationen für das Konto sind in einem ausführenden Konto mit dem Namen Data Warehouse-Aktionskonto sicher gespeichert. Dieses ausführende Konto gehört einem ausführenden Profil mit dem Namen Data Warehouse-Konto an (das mit den tatsächlichen Sammlungsregeln verknüpft ist).

Wenn das Reporting Data Warehouse und der Verwaltungsserver durch eine Vertrauensgrenze getrennt sind (z. B. befinden sich alle in unterschiedlichen Domänen ohne Vertrauenswürdigkeit), funktioniert die integrierte Windows-Authentifizierung nicht. Um diese Situation zu vermeiden, kann der überwachende Hostprozess die Verbindung zum Reporting-Data Warehouse mithilfe der SQL Server-Authentifizierung herstellen. Erstellen Sie dazu ein neues ausführendes Konto (des Typs "Einfach") mit den Anmeldeinformationen des SQL-Kontos, machen Sie dieses Konto zu einem Mitglied des ausführenden Profils mit dem Namen "Data Warehouse-SQL Server-Authentifizierungskonto", und legen Sie den Verwaltungsserver als Zielcomputer fest.

Wichtig

Standardmäßig war das ausführende Profil Konto für SQL Server-Authentifizierung bei Data Warehouse über das ausführende Konto mit demselben Namen einem speziellen Konto zugewiesen. Nehmen Sie niemals Änderungen an dem Konto vor, das mit dem ausführenden Profil Konto für SQL Server-Authentifizierung bei Data Warehouse verknüpft ist. Erstellen Sie stattdessen Ihr eigenes Konto und Ihr eigenes ausführendes Konto, und machen Sie das ausführende Konto zu einem Mitglied des ausführenden Profils Konto für SQL Server-Authentifizierung bei Data Warehouse, wenn Sie die SQL Server-Authentifizierung konfigurieren.

Nachfolgend wird die Beziehung zwischen den verschiedenen Kontoanmeldeinformationen, den ausführenden Konten und den ausführenden Profilen für die integrierte Windows-Authentifizierung sowie die SQL Server-Authentifizierung beschrieben.

Standard: Integrierte Windows-Authentifizierung

  1. Ausführendes Profil: Data Warehouse-Konto

    • Ausführendes Konto: Data Warehouse-Aktionskonto
    • Kontoanmeldeinformationen: Datenschreibkonto (beim Setup angegeben)
  2. Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto

    • Ausführendes Konto: Data Warehouse-SQL Server-Authentifizierungskonto
    • Kontoanmeldeinformationen: Spezielles Konto, das von Operations Manager erstellt wurde (nicht geändert)

Optional: SQL Server-Authentifizierung

  1. Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto
    • Ausführendes Konto: ein von Ihnen beim Setup angegebenes ausführendes Konto
    • Kontoanmeldeinformationen: ein von Ihnen beim Setup angegebenes Konto

System Center-Datenzugriffsdienst und Reporting-Data Warehouse

Standardmäßig ermöglicht der System Center-Datenzugriffsdienst, der Daten aus dem Reporting-Data Warehouse liest und im Bereich der Berichtsparameter zur Verfügung stellt, die integrierte Windows-Authentifizierung. Dazu wird der Dienst als das Datenzugriffsdienst- und Konfigurationsdienstkonto ausgeführt, das beim Setup von Operations Manager definiert wurde.

Wenn das Reporting Data Warehouse und der Verwaltungsserver durch eine Vertrauensgrenze getrennt sind (z. B. befindet sich jede in unterschiedlichen Domänen ohne Vertrauenswürdigkeit), würde die integrierte Windows-Authentifizierung nicht funktionieren. Die Verbindung zum Reporting-Data Warehouse kann vom System Center-Datenzugriffsdienst mithilfe der SQL Server-Authentifizierung hergestellt werden, um diese Situation zu vermeiden. Erstellen Sie dazu ein neues ausführendes Konto des Typs „Einfach“ mit den Anmeldeinformationen des SQL-Kontos, machen Sie dieses Konto zu einem Mitglied des ausführenden Profils Konto für SDK SQL Server-Authentifizierung bei Berichterstattung, und legen Sie den Verwaltungsserver als Zielcomputer fest.

Wichtig

Standardmäßig war das ausführende Profil Konto für SDK SQL Server-Authentifizierung bei Berichterstattung über das ausführende Konto mit dem gleichen Namen einem speziellen Konto zugewiesen. Nehmen Sie niemals Änderungen an dem Konto vor, das dem ausführenden Profil, dem Reporting SDK SQL Server dem Authentifizierungskonto zugeordnet ist. Erstellen Sie stattdessen Ihr eigenes Konto und Ihr eigenes ausführendes Konto, und machen Sie das ausführende Konto zu einem Mitglied des ausführenden Profils Konto für SDK SQL Server-Authentifizierung bei Berichterstattung, wenn Sie die SQL Server-Authentifizierung konfigurieren.

Nachfolgend wird die Beziehung zwischen den verschiedenen Kontoanmeldeinformationen, den ausführenden Konten und den ausführenden Profilen für die integrierte Windows-Authentifizierung sowie die SQL Server-Authentifizierung beschrieben.

Standard: Integrierte Windows-Authentifizierung

  1. Datenzugriffsdienst- und Konfigurationsdienstkonto (beim Setup von Operations Manager definiert)

    • Ausführendes Profil: Konto für SDK SQL Server-Authentifizierung bei Berichterstattung
    • Ausführendes Konto: Konto für SDK SQL Server-Authentifizierung bei Berichterstattung
    • Kontoanmeldeinformationen: Spezielles Konto, das von Operations Manager erstellt wurde (nicht geändert)
  2. Optional: SQL Server-Authentifizierung

    • Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto
    • Ausführendes Konto: ein von Ihnen beim Setup angegebenes ausführendes Konto
    • Kontoanmeldeinformationen: ein von Ihnen beim Setup angegebenes Konto

Betriebskonsole und Berichtsserver

Von der Betriebskonsole wird an Port 80 über HTTP eine Verbindung zum Berichtsserver hergestellt. Die Authentifizierung erfolgt mithilfe der Windows-Authentifizierung. Daten können unter Verwendung des SSL-Kanals verschlüsselt werden.

Berichtsserver und Reporting-Data Warehouse

Die Authentifizierung zwischen dem Berichtsserver und dem Reporting-Data Warehouse erfolgt mithilfe der Windows-Authentifizierung. Das Konto, das beim Setup für die Berichterstattung als Datenlesekonto angegeben wurde, wird zum Ausführungskonto auf dem Berichtsserver. Wenn sich das Kennwort für das Konto ändern soll, müssen Sie die gleiche Kennwortänderung mithilfe der Reporting Services Configuration Manager in SQL Server vornehmen. Die Daten zwischen dem Berichtsserver und dem Reporting Data Warehouse sind nicht verschlüsselt.