Verificatie en gegevensversleuteling voor Windows-computers
Van toepassing op: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager
System Center 2012 – Operations Manager bestaat uit functies zoals de beheerserver, de gatewayserver, de rapportserver, de operationele database, het rapportagedatawarehouse, de agent, de webconsole en de Operations-console. Deze sectie legt uit hoe verificatie wordt uitgevoerd en identificeert verbindingskanalen waarin 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 tussen de twee domeinen is, kan vanuit de agents in het ene domein geen verificatie met het Kerberos-protocol worden uitgevoerd op de beheerserver in het andere domein. 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. Vanuit de agent in de werkgroep is geen verificatie met de beheerserver in het domein mogelijk 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:
Vraag certificaten aan bij de CA.
Keur de certificaataanvragen op de CA goed.
Installeer de goedgekeurde certificaten in de certificaatarchieven van de computers.
Gebruik het hulpprogramma MOMCertImport om Operations Manager te configureren.
Dit zijn dezelfde stappen als waarmee u certificaten op een gatewayserver installeert, alleen installeert u het hulpprogramma voor goedkeuring van de gateway niet en voert u dit ook niet uit.
Installatie van het certificaat bevestigen
Als u het certificaat correct hebt geïnstalleerd, wordt de volgende gebeurtenis naar 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.
Let op |
---|
Het onjuist bewerken van het register kan uw systeem ernstig beschadigen. Maak een back-up van waardevolle gegevens op de computer voordat u wijzigingen in het register aanbrengt. |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings
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. Nadat de beheerserver de waarschuwing heeft ontvangen, ontsleutelt de beheerserver het bericht, versleutelt dit opnieuw met het Kerberos-protocol en verzendt dit 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, Web Console-server en rapportserver
Verificatie en gegevensversleuteling tussen de beheerserver en de Operations-console, Web Console-server 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 nog een poging gedaan met NTLM. Als verificatie nog steeds niet lukt, wordt de gebruiker gevraagd referenties op te geven. Nadat 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 door een grens van een vertrouwensrelatie worden gescheiden (het rapportagedatawarehouse en de beheerserver bevinden zich in verschillende domeinen zonder vertrouwensrelatie), dan 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
Run As-profiel: Datawarehouse-account
Run As-account: Actie-account van datawarehouse
Referenties: Gegevensschrijver-account (opgegeven tijdens de installatie)
Run As-profiel: Account voor SQL Server-verififcatie voor datawarehouse
Run As-account: Account voor SQL Server-verififcatie voor datawarehouse
Referenties: Speciaal account gemaakt door Operations Manager (niet wijzigen)
Optioneel: SQL Server-verificatie
Run As-profiel: Account voor SQL Server-verififcatie voor datawarehouse
Run As-account: Een Run As-account dat u maakt.
Referenties: Een account dat u maakt.
De System Center Data Access-service en 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 Geïntegreerde Windows-verificatie standaard 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 door een grens van een vertrouwensrelatie worden gescheiden (het rapportagedatawarehouse en de beheerserver bevinden zich in verschillende domeinen zonder vertrouwensrelatie), dan werkt Geïntegreerde Windows-verificatie niet. 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 in het account aan dat aan het Run As-profiel Rapportage-account voor SDK SQL Server-verificatie 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 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
Account voor Data Access-service en Config-service (gedefinieerd tijdens de installatie van Operations Manager)
Run As-profiel: Account voor SQL Server-verififcatie voor rapportage-SDK
Run As-account: Account voor SQL Server-verififcatie voor rapportage-SDK
Referenties: Speciaal account gemaakt door Operations Manager (niet wijzigen)
Optioneel: SQL Server-verificatie
Run As-profiel: Account voor SQL Server-verififcatie voor datawarehouse
Run As-account: Een Run As-account dat u maakt.
Referenties: Een account dat u maakt.
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. Zie Het configureren van de Operations-Console SSL gebruiken om verbinding met een Reporting Server voor meer informatie over het gebruik van SSL tussen de Operations-console en een rapportserver.
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 verandert, moet u dezelfde wachtwoordwijziging met Reporting Services Configuration Manager aanbrengen in SQL Server. Zie Hoe de Reporting Server worden uitgevoerd wachtwoord te wijzigen voor meer informatie over het opnieuw instellen van dit wachtwoord. De gegevens tussen de rapportserver en het rapportagedatawarehouse worden niet versleuteld.