Authentifizierung und Datenverschlüsselung in Operations Manager
System Center Operations Manager besteht aus Features wie Verwaltungsserver, Gatewayserver, Berichtsserver, Betriebsdatenbank, Reporting-Data Warehouse, Agent, Webkonsole und Betriebskonsole. In diesem Artikel wird erläutert, wie die Authentifizierung ausgeführt wird, und es werden Verbindungskanäle identifiziert, in denen die Daten verschlüsselt sind.
Zertifikatbasierte Authentifizierung
Wenn ein Operations Manager-Agent und ein Verwaltungsserver durch eine nicht vertrauenswürdige Gesamtstruktur oder Arbeitsgruppengrenze getrennt sind, muss eine zertifikatbasierte Authentifizierung implementiert werden. Die folgenden Abschnitte enthalten Informationen zu diesen Situationen und spezifische Verfahren zum Erhalt und zur Installation 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 Version 5-Protokoll ist die Standardmethode für die Bereitstellung der Authentifizierung. Damit die Kerberos-basierte gegenseitige Authentifizierung funktioniert, müssen die Agents und der Verwaltungsserver in einer Active Directory-Domäne installiert sein. Wenn sich ein Agent und ein Verwaltungsserver in separaten Domänen befinden, muss volles Vertrauen zwischen den Domänen vorhanden sein. In diesem Szenario wird der Datenkanal zwischen dem Agent und dem Verwaltungsserver verschlüsselt, nachdem die gegenseitige Authentifizierung stattgefunden hat. Für die Authentifizierung und Verschlüsselung ist kein Eingriff von Benutzenden erforderlich.
Einrichten der Kommunikation zwischen Agents und Verwaltungsservern über Vertrauenswürdige Grenzen hinweg
Ein Agent (oder Agents) kann/können in einer Domäne (Domäne B) getrennt vom Verwaltungsserver (Domäne A) bereitgestellt werden, und es kann keine bidirektionale Vertrauensstellung zwischen den Domänen geben. Da zwischen den beiden Domänen keine Vertrauensstellung besteht, können sich die Agents in einer Domäne nicht mit dem Verwaltungsserver in der anderen Domäne mithilfe des Kerberos-Protokolls authentifizieren. Die gegenseitige Authentifizierung zwischen den Operations Manager-Features innerhalb jeder Domäne erfolgt weiterhin.
Eine Lösung für diese Situation 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 und Datenverschlüsselung zu erreichen. Durch die Verwendung des Gatewayservers benötigen Sie nur ein Zertifikat in Domäne B und nur einen Port durch die Firewall, wie in der folgenden Abbildung dargestellt.
Einrichten der Kommunikation über eine Domäne – Arbeitsgruppengrenze
In Ihrer Umgebung haben Sie möglicherweise einen oder zwei Agents in einer Arbeitsgruppe innerhalb Ihrer Firewall bereitgestellt. Der Agent in der Arbeitsgruppe kann sich nicht mit dem Verwaltungsserver in der Domäne mithilfe des Kerberos-Protokolls authentifizieren. Eine Lösung für dieses Problem besteht darin, Zertifikate sowohl auf dem Computer zu installieren, auf dem der Agent gehostet wird, als auch auf dem Verwaltungsserver, mit dem der Agent eine Verbindung herstellt, wie in der folgenden Abbildung dargestellt.
Hinweis
In diesem Szenario muss der Agent manuell installiert werden.
Führen Sie die folgenden Schritte sowohl auf dem Computer aus, auf dem der Agent gehostet wird, als auch auf dem Verwaltungsserver, der die gleiche Zertifizierungsstelle (ZS) verwendet:
- Fordern Sie Zertifikate von der ZS an.
- Genehmigen Sie die Zertifikatanfragen von der ZS.
- Installieren Sie die genehmigten Zertifikate in den Zertifikatspeichern des Computers.
- Verwenden Sie das MOMCertImport-Tool, um Operations Manager zu konfigurieren.
Hinweis
Zertifikate mit der KEYSPEC außer 1 werden nicht unterstützt.
Dies sind die gleichen Schritte für die Installation von Zertifikaten auf einem Gatewayserver, außer dass Sie das Gatewaygenehmigungstool nicht installieren oder ausführen.
Zertifikatinstallation bestätigen
Wenn Sie das Zertifikat ordnungsgemäß installiert haben, wird das folgende Ereignis in das Ereignisprotokoll des Operations Managers geschrieben.
type | Quelle | Ereignis-ID | Allgemein |
---|---|---|---|
Informationen | OpsMgr-Konnektor | 20053 | Der OpsMgr-Konnektor hat das angegebene Authentifizierungszertifikat erfolgreich geladen. |
Während des Setups eines Zertifikats führen Sie das MOMCertImport-Tool aus. Nach Abschluss des MOMCertImport-Tools wird die Seriennummer des von Ihnen importierten Zertifikats im folgenden Unterschlüssel in die 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
Die Kommunikation zwischen diesen Operations Manager-Features beginnt mit der gegenseitigen Authentifizierung. Wenn auf beiden Seiten des Kommunikationskanals Zertifikate vorhanden sind, werden Zertifikate zur gegenseitigen Authentifizierung verwendet. Andernfalls wird das Kerberos Version 5-Protokoll verwendet. Wenn zwei Features über eine nicht vertrauenswürdige Domäne getrennt sind, muss die gegenseitige Authentifizierung mit Zertifikaten ausgeführt werden. Normale Kommunikation,wie etwa Ereignisse, Warnungen und Bereitstellung eines Management Packs, erfolgen über diesen Kanal. In der vorherigen Abbildung ist ein Beispiel für eine Warnung zu sehen, die auf einem der Agents generiert wird, die an den Verwaltungsserver weitergeleitet werden. 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 mit Zertifikaten für den Verwaltungsserver erneut verschlüsselt. Der Gatewayserver sendet die verschlüsselte Nachricht an den Verwaltungsserver, der die Warnung entschlüsselt. Einige Kommunikation zwischen dem Verwaltungsserver und dem Agent kann Anmeldeinformationen enthalten, beispielsweise Konfigurationsdaten und Aufgaben. Der Datenkanal zwischen dem Agent und dem Verwaltungsserver fügt zusätzlich zur normalen Kanalverschlüsselung eine weitere Verschlüsselungsebene hinzu. Es ist kein Benutzereingriff erforderlich.
Verwaltungsserver und Betriebskonsole, Webkonsolenserver und Berichtsserver
Die Authentifizierung und Datenverschlüsselung zwischen dem Verwaltungsserver und der Betriebskonsole, dem Webkonsolenserver oder dem Berichtsserver erfolgt mithilfe der Windows Communication Foundation (WCF)-Technologie. Der anfängliche Authentifizierungsversuch erfolgt mithilfe der Anmeldeinformationen der benutzenden Person. Das Kerberos-Protokoll wird zuerst versucht. Wenn das Kerberos-Protokoll nicht funktioniert, wird ein weiterer Versuch mithilfe von NTLM unternommen. Wenn die Authentifizierung immer noch fehlschlägt, wird die benutzende Person aufgefordert, Anmeldeinformationen anzugeben. Nachdem die Authentifizierung erfolgt ist, wird der Datenstrom entweder als Funktion des Kerberos-Protokolls oder von SSL verschlüsselt, wenn NTLM verwendet wird.
Bei einem Berichtsserver und einem Verwaltungsserver wird nach dem Auftreten der Authentifizierung eine Datenverbindung zwischen dem Verwaltungsserver und dem SQL Server-Berichtsserver hergestellt. Dies wird durch strikte Verwendung des Kerberos-Protokolls erreicht. Daher müssen sich der Verwaltungsserver und der Berichtsserver in vertrauenswürdigen Domänen befinden. Weitere Informationen zu WCF finden Sie im MSDN-Artikel Was ist Windows Communication Foundation?.
Verwaltungsserver und Reporting-Data Warehouse
Zwischen einem Verwaltungsserver und dem Reporting-Data Warehouse gibt es zwei Kommunikationskanäle:
- Der Überwachungshostprozess, der vom Integritätsdienst (System Center Management Service) auf einem Verwaltungsserver gespeichert wurde
- Die System Center-Datenzugriffsdienste auf dem Verwaltungsserver
Überwachungshostprozess und Reporting-Data Warehouse
Standardmäßig verwendet der vom Integritätsdienst gestartete Überwachungshostprozess, der für das Schreiben der gesammelten Ereignisse und Leistungsindikatoren in das Data Warehouse verantwortlich ist, die integrierte Windows-Authentifizierung, indem er als Datenschreiber-Konto ausgeführt wird, das während der Einrichtung der Berichterstellung angegeben wurde. Die Kontoanmeldeinformationen werden sicher in einem ausführenden Konto namens „Data Warehouse Action Account“ gespeichert. Dieses ausführende Konto ist ein Mitglied eines ausführenden Profils namens „Data Warehouse Account“ (das den tatsächlichen Sammlungsregeln zugeordnet ist).
Wenn das Reporting-Data Warehouse und der Verwaltungsserver durch eine Vertrauensgrenze getrennt sind (beispielsweise wenn sich beide in verschiedenen Domänen ohne Vertrauensstellung befinden), funktioniert die integrierte Windows-Authentifizierung nicht. Um dieses Problem zu umgehen, kann der Überwachungshostprozess über die SQL Server-Authentifizierung eine Verbindung zum Reporting-Data Warehouse herstellen. Erstellen Sie dazu ein neues ausführendes Konto (mit Kontotyp „einfach“) mit den SQL-Kontodaten und machen Sie es zu einem Mitglied des ausführenden Profils mit dem Namen „ Data Warehouse-SQL Server-Authentifizierungskonto“, wobei der Verwaltungsserver der Zielcomputer ist.
Wichtig
Standardmäßig wurde dem ausführenden Profil „Data Warehouse SQL Server Authentication Account“ ein spezielles Konto über das gleichnamige ausführende Konto zugewiesen. Nehmen Sie niemals Änderungen an dem Konto vor, das mit dem ausführenden Konto „Data Warehouse SQL Server Authentication Account“ verknüpft ist. Erstellen Sie stattdessen Ihr eigenes Konto und Ihr eigenes ausführendes Konto, und machen Sie das ausführende Konto bei der Konfiguration der SQL Server-Authentifizierung zu einem Mitglied des ausführenden Profils „Data Warehouse SQL Server Authentication Account“.
Im Folgenden wird die Beziehung zwischen den verschiedenen Kontoanmeldeinformationen, ausführenden Konten und ausführenden Profilen für die integrierte Windows-Authentifizierung und die SQL Server-Authentifizierung beschrieben.
Standard: Integrierte Windows-Authentifizierung
Ausführendes Profil: Data Warehouse-Konto
- Ausführendes Konto: Data Warehouse-Aktion
- Kontoanmeldeinformationen: Datenschreiber-Konto (während der Einrichtung angegeben)
Ausführendes Profil: Data Warehouse SQL Server-Authentifizierungskonto
- Ausführendes Konto: Data Warehouse-SQL Server-Authentifizierung
- Kontoanmeldeinformationen: Spezielles Konto, das von Operations Manager erstellt wurde (nicht ändern)
Optional: SQL Server-Authentifizierung
- Ausführendes Profil: Data Warehouse-SQL Server-Authentifizierungskonto
- Ausführendes Konto: Ein ausführendes Konto, das Sie während des Setups angegeben haben.
- Kontoanmeldeinformationen: Ein Konto, das Sie während des Setups angegeben haben.
System Center Data Access-Dienst und Reporting Data Warehouse
Standardmäßig erreicht der System Center Data Access-Dienst, der für das Lesen von Daten aus dem Reporting-Data Warehouse verantwortlich ist und sie im Berichtsparameterbereich verfügbar macht, die integrierte Windows-Authentifizierung, indem er als Datenzugriffsdienst- und Konfigurationsdienstkonto ausgeführt wird, das während des Setups von Operations Manager definiert wurde.
Wenn das Reporting Data Warehouse und der Verwaltungsserver durch eine Vertrauensgrenze getrennt sind (z. B. beide befinden sich in unterschiedlichen Domänen ohne Vertrauensstellung), funktioniert die integrierte Windows-Authentifizierung nicht. Um diese Situation zu umgehen, kann der System Center Data Access-Dienst mithilfe der SQL Server-Authentifizierung eine Verbindung mit dem Reporting Data Warehouse herstellen. Erstellen Sie dazu ein neues ausführendes Konto (vom Typ „einfach“) mit den Anmeldeinformationen des SQL-Kontos und machen Sie es zu einem Mitglied des ausführenden Profils namens „SQL Server-Authentifizierungskonto des Reporting SDK“ mit dem Verwaltungsserver als Zielcomputer.
Wichtig
Standardmäßig wurde dem ausführenden Profil „Reporting SDK SQL Server Authentication Account“ über die Verwendung des ausführenden Kontos mit dem gleichen Namens ein spezielles Konto zugewiesen. Nehmen Sie niemals Änderungen an dem Konto vor, das dem ausführenden Profil „Reporting SDK SQL Server Authentication Account“ zugeordnet ist. Erstellen Sie stattdessen Ihr eigenes Konto und Ihr eigenes ausführendes Konto, und machen Sie beim Konfigurieren der SQL Server-Authentifizierung das ausführende Konto zu einem Mitglied des ausführenden Profils „Reporting SDK SQL Server Authentication Account“.
Im Folgenden wird die Beziehung zwischen den verschiedenen Kontoanmeldeinformationen, ausführenden Konten und ausführenden Profilen für die integrierte Windows-Authentifizierung und die SQL Server-Authentifizierung beschrieben.
Standard: Integrierte Windows-Authentifizierung
Datenzugriffsdienst and Konfigurationsdienstkonto (definiert während des Setups von Operations Manager)
- Ausführendes Profil: SQL Server-Authentifizierungskonto des Reporting SDK
- Ausführendes Konto: SQL Server-Authentifizierungskonto des Reporting SDK
- Kontoanmeldeinformationen: Spezielles Konto, das von Operations Manager erstellt wurde (nicht ändern)
Optional: SQL Server-Authentifizierung
- Ausführendes Profil: Data Warehouse SQL Server-Authentifizierungskonto
- Ausführendes Konto: Ein ausführendes Konto, das Sie während des Setups angegeben haben.
- Kontoanmeldeinformationen: Ein Konto, das Sie während des Setups angegeben haben.
Betriebskonsole und Berichtsserver
Die Betriebskonsole stellt mithilfe von HTTP an Port 80 eine Verbindung mit dem Berichtsserver her. Die Authentifizierung erfolgt mithilfe der Windows-Authentifizierung. Daten können mithilfe 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 während des Reporting-Setups als Datenlesekonto angegeben wurde, wird zum Ausführungskonto auf dem Berichtsserver. Wenn das Kennwort für das Konto geändert werden soll, müssen Sie dieselbe Kennwortänderung mithilfe des Konfigurations-Managers für Reporting Services in SQL Server vornehmen. Die Daten zwischen dem Berichtsserver und dem Reporting Data Warehouse werden nicht verschlüsselt.