Verificatie en gegevensversleuteling in Operations Manager

Belangrijk

Deze versie van Operations Manager heeft het einde van de ondersteuning bereikt. U wordt aangeraden een upgrade uit te voeren naar Operations Manager 2022.

System Center Operations Manager bestaat uit functies zoals de beheerserver, gatewayserver, rapportageserver, operationele database, rapportagedatawarehouse, agent, webconsole en Operations-console. In dit artikel wordt uitgelegd hoe verificatie wordt uitgevoerd en worden verbindingskanalen geïdentificeerd waar de gegevens worden versleuteld.

Verificatie op basis van een certificaat

Wanneer een Operations Manager-agent en -beheerserver door een niet-vertrouwde of werkgroepgrens worden gescheiden, moet verificatie op basis van een certificaat worden geïmplementeerd. De volgende secties bevatten informatie over deze situaties en specifieke procedures voor het verkrijgen en installeren van certificaten van op Windows gebaseerde certificeringsinstanties.

Communicatie definiëren tussen agents en beheerservers binnen dezelfde grens van een vertrouwensrelatie

Een agent en de beheerserver gebruiken Windows-verificatie om elkaar te verifiëren alvorens de beheerserver gegevens van de agent accepteert. Het protocol Kerberos versie 5 is de standaardmethode voor verificatie. De agents en beheerserver moeten in een Active Directory-domein zijn geïnstalleerd anders werkt de wederzijdse verificatie op basis van Kerberos niet. Als een agent en een beheerserver zich in afzonderlijke domeinen bevinden, moet er volledig vertrouwen tussen de domeinen zijn. In dit scenario wordt het gegevenskanaal tussen de agent en de beheerserver versleuteld nadat wederzijdse verificatie heeft plaatsgevonden. Voor de verificatie en versleuteling is geen tussenkomst van de gebruiker vereist.

Communicatie definiëren tussen agents en beheerservers over grenzen van vertrouwensrelaties

Een of meer agents kunnen in een ander domein (domein B) dan het domein van de beheerserver (domein A) zijn geïmplementeerd en tussen deze domeinen bestaat mogelijk geen tweerichtingsrelatie. Omdat er geen vertrouwensrelatie is tussen de twee domeinen, kunnen de agents in het ene domein niet worden geverifieerd bij de beheerserver in het andere domein met behulp van het Kerberos-protocol. Wederzijdse verificatie tussen de Operations Manager-functies binnen de afzonderlijke domeinen vindt wel plaats.

U kunt deze situatie oplossen door in het domein van de agents een gatewayserver te installeren en vervolgens certificaten op de gatawayserver en de beheerserver te installeren om wederzijdse verificatie en gegevensversleuteling mogelijk te maken. Het gebruik van de gatewayserver betekent dat u slechts één certificaat in domein B en slechts één poort in de firewall nodig hebt, zoals weergegeven in de volgende afbeelding.

Communicatie definiëren over een domein–werkgroepgrens

In uw omgeving hebt u mogelijk een of twee agents die in een werkgroep binnen de firewall zijn geïmplementeerd. De agent in de werkgroep kan zich niet verifiëren bij de beheerserver in het domein met behulp van het Kerberos-protocol. U lost dit probleem op door certificaten te installeren op zowel de hostcomputer van de agent als de beheerserver waarmee de agent een verbinding maakt, zoals weergegeven in de volgende afbeelding.

Notitie

In dit scenario moet de agent handmatig worden geïnstalleerd.

Voer de volgende stappen op de hostcomputer van de agent en de beheerserver uit met dezelfde certificeringsinstantie (CA) voor hostcomputer en beheerserver:

1. Vraag certificaten aan bij de CA.
2. Keur de certificaataanvragen op de CA goed.
3. Installeer de goedgekeurde certificaten in de certificaatarchieven van de computers.
4. Gebruik het hulpprogramma MOMCertImport om Operations Manager te configureren.

Notitie

Certificaten met een andere KEYSPEC dan 1 worden niet ondersteund.

Dit zijn dezelfde stappen voor het installeren van certificaten op een gatewayserver, behalve dat u het hulpprogramma voor gatewaygoedkeuring niet installeert of uitvoert

Installatie van het certificaat bevestigen

Als u het certificaat correct hebt geïnstalleerd, wordt de volgende gebeurtenis in het Operations Manager-gebeurtenislogboek geschreven.

Type	Bron	Gebeurtenis-id	Algemeen
Informatie	OpsMgr-connector	20053	De OpsMgr-connector heeft het opgegeven verificatiecertificaat geladen.

Tijdens de installatie van een certificaat, voert u het hulpprogramma MOMCertImport uit. Wanneer het hulpprogramma MOMCertImport is voltooid, wordt het serienummer van het certificaat dat u hebt geïmporteerd naar het register geschreven bij de volgende subsleutel.

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

Waarschuwing

Het onjuist bewerken van het register kan uw systeem ernstig beschadigen. Voordat u wijzigingen aanbrengt in het register, moet u een back-up maken van alle belangrijke gegevens op de computer.

Verificatie en gegevensversleuteling tussen beheerserver, gatewayserver en agents

Communicatie tussen deze Operations Manager-functies begint met wederzijdse verificatie. Als certificaten aan beide uiteinden van het communicatiekanaal aanwezig zijn, worden certificaten voor wederzijdse verificatie gebruikt. Anders wordt het protocol Kerberos versie 5 gebruikt. Als twee functies gescheiden zijn in een niet-vertrouwd domein, moet de wederzijdse verificatie met behulp van certificaten worden uitgevoerd. Normale communicatie, zoals gebeurtenissen, waarschuwingen en de implementatie van een management pack, gebeurt via het al genoemde communicatiekanaal. In de vorige afbeelding is een voorbeeld te zien van een waarschuwing die op een van de agents wordt gegenereerd en die naar de beheerserver wordt doorgestuurd. Van de agent naar de gatewayserver wordt het Kerberos-beveiligingspakket gebruikt om de gegevens te versleutelen omdat de gatewayserver en de agent zich in hetzelfde domein bevinden. De waarschuwing wordt door de gatewayserver versleuteld en opnieuw versleuteld met certificaten, ditmaal voor de beheerserver. De gatewayserver verzendt het versleutelde bericht naar de beheerserver waar de beheerserver de waarschuwing ontsleutelt. Een deel van de communicatie tussen de beheerserver en de agent kan bestaan uit referentiegegevens, bijvoorbeeld configuratiegegevens en -taken. Het gegevenskanaal tussen de agent en de beheerserver voegt nog een extra versleutelingslaag naast de normale kanaalversleuteling toe. Er is geen tussenkomst van de gebruiker is vereist.

Beheerserver en Operations-console, webconsoleserver en rapportserver

Verificatie en gegevensversleuteling tussen de beheerserver en de Operations-console, webconsoleserver of rapportserver wordt gerealiseerd met behulp van WCF-technologie (Windows Communication Foundation). De eerste poging tot verificatie wordt gedaan met behulp van de gebruikersreferenties. Het Kerberos-protocol wordt eerst geprobeerd. Als het Kerberos-protocol niet werkt, wordt een andere poging gedaan met behulp van NTLM. Als verificatie nog steeds niet lukt, wordt de gebruiker gevraagd referenties op te geven. Nadat de verificatie heeft plaatsgevonden, wordt de gegevensstroom versleuteld als een functie van het Kerberos-protocol of SSL als NTLM wordt gebruikt.

In geval van een rapportserver en een beheerserver, wordt een gegevensverbinding tussen de beheerserver en SQL Reporting Server gemaakt nadat verificatie heeft plaatsgevonden. Deze verbinding wordt gerealiseerd door uitsluitend het Kerberos-protocol te gebruiken. Daarom moeten de beheerserver en rapportserver zich in hetzelfde vertrouwde domein bevinden. Zie het MSDN-artikel What Is Windows Communication Foundation (Wat is Windows Communication Foundation) voor meer informatie.

Beheerserver en rapportagedatawarehouse

Er bestaan twee communicatiekanalen tussen een beheerserver en het rapportagedatawarehouse:

• Het bewakingshostproces dat is gestart door de Health-service (System Center Management-service) op een beheerserver
• De System Center Data Access-services op de beheerserver

Bewakingshostproces en rapportagedatawarehouse

Het bewakingshostproces dat door de Health-service is gestart en dat verantwoordelijk is voor het naar het datawarehouse schrijven van verzamelde gebeurtenissen en prestatiemeteritems, realiseert Geïntegreerde Windows-verificatie standaard doordat dit uitgevoerd wordt als het Gegevensschrijver-account dat tijdens de installatie van de rapportage is opgegeven. De accountreferenties zijn veilig opgeslagen in een Run As-account met de naam Actie-account van datawarehouse. Dit Run As-account is lid van een Run As-profiel met de naam Datawarehouse-account (dat aan de daadwerkelijke verzamelingsregels is gekoppeld).

Als het rapportagedatawarehouse en de beheerserver zijn gescheiden door een vertrouwensgrens (bijvoorbeeld, elk bevindt zich in verschillende domeinen zonder vertrouwen), werkt geïntegreerde Windows-verificatie niet. Om deze situatie te omzeilen, kan het bewakingshostproces met behulp van SQL Server-verificatie een verbinding met het rapportagedatawarehouse maken. Hiervoor maakt u een nieuw Run As-account (van het type eenvoudig account) met de referenties van het SQL-account en maakt u dit account lid van het Run As-profiel met de naam Account voor SQL Server-verificatie voor datawarehouse, met de beheerserver als doelcomputer.

Belangrijk

Standaard is aan het Run As-profiel Account voor SQL Server-verificatie voor datawarehouse een speciaal account toegewezen door het gebruik van het Run As-account met dezelfde naam. Breng nooit wijzigingen in het account aan dat aan het Run As-profiel Account voor SQL Server-verificatie voor datawarehouse is gekoppeld. Maak in plaats hiervan uw eigen account en uw eigen Run As-account. Maak het Run As-account lid van het Run As-profiel Account voor SQL Server-verificatie voor datawarehouse wanneer u SQL Server-verificatie configureert.

Hieronder wordt de relatie van de verschillende accountreferenties, Run As-accounts en Run As-profielen voor zowel Geïntegreerde Windows-verificatie als SQL Server-verificatie toegelicht.

Standaard: Geïntegreerde Windows-verificatie

1. Run As-profiel: datawarehouse-account

   • Uitvoeren als-account: datawarehouse-actie
   • Accountreferenties: gegevensschrijver-account (opgegeven tijdens de installatie)

2. Run As-profiel: account voor SQL Server-verificatie voor datawarehouse

   • Uitvoeren als-account: account voor SQL Server-verificatie voor datawarehouse
   • Accountreferenties: speciaal account gemaakt door Operations Manager (niet wijzigen)

Optioneel: SQL Server-verificatie

1. Run As-profiel: account voor SQL Server-verificatie voor datawarehouse
   • Uitvoeren als-account: een Uitvoeren als-account dat u tijdens de installatie hebt opgegeven.
   • Accountreferenties: een account dat u tijdens de installatie hebt opgegeven.

De System Center Data Access-service en het rapportagedatawarehouse

De System Center Data Access-service, die verantwoordelijk is voor het lezen van gegevens van het rapportagedatawarehouse en het beschikbaar maken van deze gegevens in het gebied met rapportparameters, realiseert standaard Geïntegreerde Windows-verificatie doordat deze service wordt uitgevoerd als het account voor de Data Access-service en Config-service dat tijdens de installatie van Operations Manager is gedefinieerd.

Als het rapportagedatawarehouse en de beheerserver worden gescheiden door een vertrouwensgrens (bijvoorbeeld, elk bevindt zich in verschillende domeinen zonder vertrouwensrelatie), zou geïntegreerde Windows-verificatie niet werken. Om deze situatie te omzeilen, kan de System Center Data Access-service met behulp van SQL Server-verificatie een verbinding met het rapportagedatawarehouse maken. Hiervoor maakt u een nieuw Run As-account (van het type eenvoudig account) met de referenties van het SQL-account en maakt u dit account lid van het Run As-profiel met de naam Rapportage-account voor SDK SQL Server-verificatie, met de beheerserver als doelcomputer.

Belangrijk

Standaard is aan het Run As-profiel Rapportage-account voor SDK SQL Server-verificatie een speciaal account toegewezen door het gebruik van het Run As-account met dezelfde naam. Breng nooit wijzigingen aan in het account dat is gekoppeld aan het Run As-profiel, rapportage-SDK SQL Server verificatieaccount. Maak in plaats hiervan uw eigen account en uw eigen Run As-account. Maak het Run As-account lid van het Run As-profiel Rapportageaccount voor SDK SQL Server-verificatie wanneer u SQL Server-verificatie configureert.

Hieronder wordt de relatie van de verschillende accountreferenties, Run As-accounts en Run As-profielen voor zowel Geïntegreerde Windows-verificatie als SQL Server-verificatie toegelicht.

Standaard: Geïntegreerde Windows-verificatie

1. Account voor Data Access-service en Config-service (gedefinieerd tijdens de installatie van Operations Manager)

   • Run As-profiel: account voor SQL Server-verificatie voor rapportage-SDK
   • Uitvoeren als-account: account voor SQL Server-verificatie voor rapportage-SDK
   • Accountreferenties: speciaal account gemaakt door Operations Manager (niet wijzigen)

2. Optioneel: SQL Server-verificatie

   • Run As-profiel: account voor SQL Server-verificatie voor datawarehouse
   • Uitvoeren als-account: een Uitvoeren als-account dat u tijdens de installatie hebt opgegeven.
   • Accountreferenties: een account dat u tijdens de installatie hebt opgegeven.

Operations-console en rapportserver

De Operations-console maakt op poort 80 via HTTP een verbinding met de rapportserver. Verificatie wordt uitgevoerd met behulp van Windows-verificatie. Gegevens kunnen met behulp van het SSL-kanaal worden versleuteld.

Rapportserver en rapportagedatawarehouse

Verificatie tussen een rapportserver en het rapportagedatawarehouse wordt met behulp van Windows-verificatie gerealiseerd. Het account dat als Gegevenslezer-account tijdens de configuratie van de rapportage is opgegeven, wordt het uitvoeringsaccount op de rapportserver. Als het wachtwoord voor het account moet worden gewijzigd, moet u dezelfde wachtwoordwijziging aanbrengen met behulp van de Reporting Services-Configuration Manager in SQL Server. De gegevens tussen de rapportageserver en het rapportagedatawarehouse zijn niet versleuteld.