Diese Dokumentation wurde archiviert und wird nicht länger gepflegt.

Authentifizierung und Datenverschlüsselung für Windows-Computer in Operations Manager 2007

Letzte Aktualisierung: Mai 2009

Betrifft: Operations Manager 2007 R2, Operations Manager 2007 SP1

Operations Manager 2007 besteht unter anderem aus den folgenden Komponenten: Stammverwaltungsserver, Verwaltungsserver, Gatewayserver, Berichtsserver, Operations Manager-Datenbank, Berichterstattungs-Data Warehouse, Agent, Webkonsole und Betriebskonsole. In diesem Abschnitt wird erläutert, wie die Authentifizierung erfolgt; außerdem werden hier Verbindungskanäle für die Datenverschlüsselung aufgezeigt.

Zertifikatbasierte Authentifizierung

Wenn ein Operations Manager-Agent und Verwaltungsserver durch eine nicht vertrauenswürdige Gesamtstruktur oder eine Arbeitsgruppengrenze getrennt sind, muss eine zertifikatbasierte Authentifizierung implementiert werden. Die nachfolgenden Abschnitte enthalten 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 diesen beiden Domänen besteht möglicherweise keine bidirektionale Vertrauensstellung. Da keine Vertrauensstellung zwischen den beiden Domänen besteht, können sich die Agents der einen Domäne nicht mit dem Kerberos-Protokoll beim Verwaltungsserver in der anderen Domäne authentifizieren. Es erfolgt jedoch nach wie vor eine gegenseitige Authentifizierung zwischen den Operations Manager 2007-Komponenten innerhalb jeder Domäne.

Eine Lösung für dieses Problem besteht darin, einen Gatewayserver in derselben 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. Der Einsatz des Gatewayservers bedeutet, dass Sie nur ein Zertifikat in Domäne B und nur einen Port durch die Firewall hindurch benötigen (siehe nachfolgende Abbildung).

5ef3ea73-c60a-4875-bcf4-88b54c936e46

Weitere Informationen finden Sie unter den folgenden Themen in diesem Sicherheitshandbuch:

Abrufen eines Zertifikats mithilfe einer Windows Server 2003-Unternehmenszertifizierungsstelle in Operations Manager 2007

Abrufen eines Zertifikats mithilfe einer eigenständigen Windows Server 2003-Zertifizierungsstelle in Operations Manager 2007

Abrufen eines Zertifikats mithilfe einer Windows Server 2008-Unternehmenszertifizierungsstelle in Operations Manager 2007

Abrufen eines Zertifikats mithilfe einer eigenständigen Windows Server 2008-Zertifizierungsstelle in Operations Manager 2007

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. Die Agents dieser Arbeitsgruppe können sich beim Verwaltungsserver in der Domäne nicht mit dem Kerberos-Protokoll 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).

noteHinweis
In diesem Szenario muss der Agent manuell installiert werden.

9257b1a5-adf0-4d1e-be9c-afca94b0cd95

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

  • Fordern Sie die erforderlichen Zertifikate von der Zertifizierungsstelle an.

  • Genehmigen Sie die Zertifikatanforderungen bei der Zertifizierungsstelle.

  • Installieren Sie die genehmigten Zertifikate in den Zertifikatspeichern der Computer.

  • Verwenden Sie das MOMCertImport-Tool, um Operations Manager 2007 zu konfigurieren.

Dies sind dieselben Schritte wie beim Installieren von Zertifikaten auf einem Gatewayserver, mit dem Unterschied, dass Sie das Gatewaygenehmigungstool weder installieren noch ausführen. Weitere Informationen finden Sie unter den folgenden Themen in diesem Sicherheitshandbuch:

Abrufen eines Zertifikats mithilfe einer Windows Server 2003-Unternehmenszertifizierungsstelle in Operations Manager 2007

Abrufen eines Zertifikats mithilfe einer eigenständigen Windows Server 2003-Zertifizierungsstelle in Operations Manager 2007

Abrufen eines Zertifikats mithilfe einer Windows Server 2008-Unternehmenszertifizierungsstelle in Operations Manager 2007

Abrufen eines Zertifikats mithilfe einer eigenständigen Windows Server 2008-Zertifizierungsstelle in Operations Manager 2007

Assistent für die Zertifikatgenerierung

Die erforderlichen Schritte für das Generieren, Abrufen und Installieren von Zertifikaten finden Sie in diesem Sicherheitshandbuch. Ein spezieller Assistent für die Zertifikatgenerierung erleichtert diesen Vorgang. Weitere Informationen finden Sie im Blogbeitrag. Obtaining Certificates for Non-Domain Joined Agents Made Easy With Certificate Generation Wizard (Assistent für die Zertifikatgenerierung erleichtert das Anfordern von Zertifikaten für Agents, die keiner Domäne angehören) (http://go.microsoft.com/fwlink/?LinkId=128392).

noteHinweis
Der Assistent für die Zertifikatgenerierung wird OHNE MÄNGELGEWÄHR und ohne Garantien bereitgestellt; hiermit werden keine Rechtsansprüche übertragen. Für den Einsatz dieses Dienstprogramms gelten die hier angegebenen Bedingungen: http://www.microsoft.com/info/cpyright.htm (möglicherweise in englischer Sprache)

Bestätigen der Zertifikatinstallation

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

 

Ebene Quelle Ereignis-ID Allgemein

Informationen

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.

CautionVorsicht
Durch eine fehlerhafte Bearbeitung der Registrierung können schwere Systemschäden verursacht werden. Bevor Änderungen an der Registrierung vorgenommen werden, sollten Sie eine Sicherungskopie aller wichtigen Daten auf dem Computer erstellen.

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

Authentifizierung und Datenverschlüsselung zwischen Stammverwaltungsserver, Verwaltungsserver, Gatewayserver und Agents

Die Kommunikation zwischen diesen Operations Manager-Komponenten beginnt mit der gegenseitigen 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 Komponenten ü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. Die vorangehende Abbildung zeigt ein Beispiel für eine auf einem der Agents generierte Warnung, die an den Stammverwaltungsserver 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 derselben Domäne befinden. Die Warnung wird vom Gatewayserver ent- und mithilfe von Zertifikaten für den Verwaltungsserver erneut verschlüsselt. Nachdem der Verwaltungsserver die Warnung empfangen hat, entschlüsselt der Verwaltungsserver die Nachricht, verschlüsselt sie erneut mithilfe des Kerberos-Protokolls und sendet die Nachricht an den Stammverwaltungsserver, wo die Warnung entschlüsselt wird.

Einige Kommunikationsaktivitäten zwischen dem Stammverwaltungsserver und dem Agent umfassen möglicherweise Anmeldeinformationen, beispielsweise Konfigurationsdaten und -tasks. Der Datenkanal zwischen dem Agent und dem Verwaltungsserver stellt eine weitere Verschlüsselungsschicht zusätzlich zur normalen Kanalverschlüsselung dar. Hierfür ist kein Benutzereingriff erforderlich.

Stammverwaltungsserver und Operations Manager-Datenbank

Informationen zu ausführenden Konten werden in verschlüsselter Form in der Operations Manager-Datenbank gespeichert; dies erfolgt mithilfe eines symmetrischen Schlüsselpaares, das von Operations Manager 2007 erstellt wurde. Sollte der Stammverwaltungsserver einmal ersetzt werden müssen, wäre der neue Stammverwaltungsserver nicht in der Lage, die verschlüsselten Daten aus der Datenbank auszulesen. Das in Operations Manager 2007 enthaltene SecureStorageBackup-Tool wird verwendet, um diesen Verschlüsselungsschlüssel zu sichern und wiederherzustellen.

ImportantWichtig
Führen Sie das SecureStorageBackup-Tool aus, um den Schlüssel des Stammverwaltungsservers zu Sicherungszwecken zu exportieren. Ohne Sicherung des Stammverwaltungsserver-Schlüssels müssten Sie alle ausführenden Konten neu eingeben, wenn Sie den Stammverwaltungsserver neu erstellen müssen. In größeren Umgebungen könnten von einer solchen Maßnahme Hunderte von Konten betroffen sein. Weitere Informationen zum SecureStorageBackup-Tool finden Sie unter dem Thema How to Backup and Restore Encryption Keys in Operations Manager 2007 (Sichern und Wiederherstellen von Verschlüsselungsschlüsseln in Operations Manager 2007) (http://go.microsoft.com/fwlink/?LinkId=87387, möglicherweise in englischer Sprache).

Informationen zur Wiederherstellung in Notfällen, die den Ausfall des Stammverwaltungsservers umfassen, mit oder ohne Sicherung des Verschlüsselungsschlüssels, finden Sie im Knowledge Base-Artikel mit dem Titel Nachdem Sie den Root Management Server Server in Microsoft System Center Operations Manager 2007 ersetzen oder neu installieren, ist der Root Management Server Verschlüsselungsschlüssel nicht verfügbar (http://go.microsoft.com/fwlink/?LinkId=112310).

Stammverwaltungsserver und Betriebskonsole, Webkonsolenserver und Berichtsserver

Die Authentifizierung und Datenverschlüsselung zwischen dem Stammverwaltungsserver und der Betriebskonsole, dem Webkonsolenserver oder dem Berichtsserver erfolgt mithilfe der WCF-Technologie (Windows Communication Foundation), ehemaliger Codename "Indigo". Zunächst erfolgt ein Authentifizierungsversuch mithilfe der Anmeldeinformationen des Benutzers. Das Kerberos-Protokoll wird als erstes versucht. Falls 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. Sobald die Authentifizierung erfolgt ist, wird der Datenstrom verschlüsselt; dies erfolgt über das Kerberos-Protokoll oder SSL, falls NTLM verwendet wird.

Bei einem Berichtsserver und einem Stammverwaltungsserver wird nach erfolgter Authentifizierung eine Datenverbindung zwischen dem Stammverwaltungsserver und dem SQL Server-Berichtsserver hergestellt. Hierbei wird ausschließlich das Kerberos-Protokoll verwendet; der Stammverwaltungsserver und der Berichtsserver müssen sich daher in vertrauenswürdigen Domänen befinden. Weitere Informationen zu WCF finden Sie im MSDN-Artikel Was ist die Windows Communication Foundation? (http://go.microsoft.com/fwlink/?LinkId=87429).

Verwaltungsserver und Berichterstattungs-Data Warehouse

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

  • Der vom Integritätsdienst auf einem Verwaltungsserver oder einem Stammverwaltungsserver erzeugte überwachende Hostprozess

  • Der SDK-Dienst auf dem Stammverwaltungsserver

Überwachender Hostprozess und Berichterstattungs-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 Berichterstattungs-Data Warehouse und der Verwaltungsserver durch eine Vertrauensgrenze getrennt sind (beispielsweise wenn sich beide in unterschiedlichen Domänen ohne Vertrauensstellung befinden), kann die integrierte Windows-Authentifizierung nicht verwendet werden. Um diese Situation zu vermeiden, kann der überwachende Hostprozess die Verbindung zum Berichterstattungs-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.

ImportantWichtig
Standardmäßig war das ausführende Profil "Data Warehouse-SQL Server-Authentifizierungskonto" über das ausführende Konto mit demselben Namen einem speziellen Konto zugewiesen. Nehmen Sie keine Änderungen an dem Konto vor, das mit dem ausführenden Data Warehouse-SQL Server-Authentifizierungskonto 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 "Data Warehouse-SQL Server-Authentifizierungskonto", wenn Sie die SQL Server-Authentifizierung konfigurieren.

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

Standard: Integrierte Windows-Authentifizierung

Ausführendes Profil: Data Warehouse-Konto

     Ausführendes Konto: Data Warehouse-Aktionskonto

          Anmeldeinformationen: Datenschreibkonto (beim Setup angegeben)

Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto

     Ausführendes Konto: Data Warehouse-SQL Server-Authentifizierungskonto

          Anmeldeinformationen: Von Operations Manager erstelltes Spezialkonto (nicht ändern)

Optional: SQL Server-Authentifizierung

Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto

     Ausführendes Konto: Ein von Ihnen erstelltes ausführendes Konto.

          Anmeldeinformationen: Ein von Ihnen erstelltes Konto.

Der System Center-Datenzugriffsdienst oder der SDK-Dienst und das Berichterstattungs-Data Warehouse

Der in Operations Manager 2007 SP1 enthaltene SDK-Dienst heißt in Operations Manager 2007 R2 "System Center-Datenzugriffsdienst".

Standardmäßig erzielt der System Center-Datenzugriffsdienst (SDK-Dienst), der dafür zuständig ist, Daten aus dem Berichterstattungs-Data Warehouse auszulesen und diese im Bereich "Berichtsparameter" zur Verfügung zu stellen, die integrierte Windows-Authentifizierung, indem er als das beim Setup von Operations Manager 2007 definierte SDK- und Konfigurationsdienstkonto ausgeführt wird.

Wenn das Berichterstattungs-Data Warehouse und der Verwaltungsserver durch eine Vertrauensgrenze getrennt sind (beispielsweise wenn sich beide in unterschiedlichen Domänen ohne Vertrauensstellung befinden), würde die integrierte Windows-Authentifizierung nicht funktionieren. Um diese Situation zu vermeiden, kann der System Center-Datenzugriffsdienst bzw. der SDK-Dienst die Verbindung zum Berichterstattungs-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 "Berichts-SDK-SQL Server-Authentifizierungskonto", und legen Sie den Verwaltungsserver als Zielcomputer fest.

ImportantWichtig
Standardmäßig war das ausführende Profil "Berichts-SDK-SQL Server-Authentifizierungskonto" über das ausführende Konto mit demselben Namen einem speziellen Konto zugewiesen. Nehmen Sie keine Änderungen an dem Konto vor, das mit dem ausführenden Berichts-SDK-SQL Server-Authentifizierungskonto 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 "Berichts-SDK-SQL Server-Authentifizierungskonto", wenn Sie die SQL Server-Authentifizierung konfigurieren.

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

Standard: Integrierte Windows-Authentifizierung

SDK- und Konfigurationsdienstkonto (beim Setup von Operations Manager definiert)

Ausführendes Profil: Berichts-SDK-SQL Server-Authentifizierungskonto

     Ausführendes Konto: Berichts-SDK-SQL Server-Authentifizierungskonto

          Anmeldeinformationen: Von Operations Manager erstelltes Spezialkonto (nicht ändern)

Optional: SQL Server-Authentifizierung

Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto

     Ausführendes Konto: Ein von Ihnen erstelltes ausführendes Konto.

          Anmeldeinformationen: Ein von Ihnen erstelltes Konto.

Betriebskonsole und Berichtsserver

Die Betriebskonsole stellt an Port 80 über HTTP eine Verbindung zum Berichtsserver her. Die Authentifizierung erfolgt mithilfe der Windows-Authentifizierung. Daten können unter Verwendung des SSL-Kanals verschlüsselt werden. Weitere Informationen zur Verwendung von SSL zwischen der Betriebskonsole und dem Berichtsserver finden Sie unter Konfigurieren der Betriebskonsole für den Einsatz von SSL beim Herstellen einer Verbindung zu einem Berichtsserver in Operations Manager 2007 weiter hinten im Sicherheitshandbuch.

Berichtsserver und Berichterstattungs-Data Warehouse

Die Authentifizierung zwischen dem Berichtsserver und dem Berichterstattungs-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. Falls das Kennwort für das Konto geändert wird, müssen Sie dieselbe Kennwortänderung mithilfe des Konfigurations-Managers für Reporting Services in SQL Server 2005 vornehmen. Weitere Informationen zum Zurücksetzen dieses Kennworts finden Sie unter Ändern des Kennworts des Berichtsserver-Ausführungskontos in Operations Manager 2007. Die Daten zwischen dem Berichtsserver und dem Berichterstattungs-Data Warehouse werden nicht verschlüsselt.

Siehe auch

 
Anzeigen: