Autentisering och datakryptering i Operations Manager

Viktigt

Den här versionen av Operations Manager har nått slutet av supporten. Vi rekommenderar att du uppgraderar till Operations Manager 2022.

System Center Operations Manager består av funktioner som hanteringsserver, gatewayserver, rapporteringsserver, driftdatabas, informationslager för rapportering, agent, webbkonsol och driftkonsol. Den här artikeln beskriver hur autentisering utförs och identifierar anslutningskanaler där data krypteras.

Certifikatbaserad autentisering

Om en agent och en hanteringsserver i Operations Manager är åtskilda av en obetrodd skog eller en arbetsgruppsgräns måste certifikatbaserad autentisering implementeras. I följande avsnitt finns information om sådana situationer och vilka procedurer som krävs för att hämta och installera certifikat från Windows-baserade certifikatutfärdare.

Installera kommunikation mellan agenter och hanteringsservrar inom samma förtroendegräns

En agent och hanteringsservern använder Windows-autentisering för ömsesidig autentisering innan hanteringsservern accepterar data från agenten. Standardmetoden för autentisering är Kerberos version 5-protokollet. För att Kerberos-baserad ömsesidig autentisering ska fungera krävs att agenterna och hanteringsservern är installerade i en Active Directory-domän. Om en agent och en hanteringsserver finns i separata domäner måste det finnas fullt förtroende mellan domänerna. Om detta scenario uppstår efter ömsesidig autentisering, är datakanalen mellan agenten och hanteringsservern krypterad. Ingen åtgärd från användaren krävs för att autentisering och kryptering ska äga rum.

Installera kommunikation mellan agenter och hanteringsservrar över förtroendegränser

En agent (eller flera agenter) kan distribueras till en annan domän (domän B) än där hanteringsservern finns (domän A), utan att domänerna är betrodda i båda riktningarna. Eftersom det inte finns något förtroende mellan de två domänerna kan agenterna i en domän inte autentisera med hanteringsservern i den andra domänen med hjälp av Kerberos-protokollet. Ömsesidig autentisering mellan Operations Manager-funktionerna inom varje domän sker fortfarande.

En lösning i den här situationen är att installera en gateway-server i samma domän som agenterna, och därefter installera certifikaten på gateway-servern och hanteringsservern så att det går att utföra ömsesidig autentisering och datakryptering. Om du använder en gateway-server behöver du bara ha ett certifikat i domän B och endast en port genom brandväggen, som visas i följande bild.

Installera kommunikation över en domän – arbetsgruppsgräns

I en miljö kan det finnas en eller två agenter som distribuerats till en arbetsgrupp innanför brandväggen. Agenten i arbetsgruppen kan inte autentisera med hanteringsservern i domänen med hjälp av Kerberos-protokollet. En lösning i den här situationen är att installera certifikat både på datorn som fungerar som värd för agenten och på hanteringsservern som agenten ansluter till, enligt följande bild.

Anteckning

I det här scenariot måste agenten installeras manuellt.

Utför följande steg både på datorn som fungerar som värd för agenten och på hanteringsservern med samma certifikatutfärdare (CA) för var och en:

1. Begär certifikat från certifikatutfärdaren.
2. Godkänn certifikatbegärandena på certifikatutfärdaren.
3. Installera de godkända certifikaten i datorns certifikatlager.
4. Använd verktyget MOMCertImport för att konfigurera Operations Manager.

Anteckning

Certifikat med andra KEYSPEC än 1 stöds inte.

Det här är samma steg för att installera certifikat på en gateway-server, förutom att du inte installerar eller kör verktyget för gatewaygodkännande

Bekräfta certifikatsinstallationen

Om du har installerat certifikatet korrekt skrivs följande händelse i Operations Manager-händelseloggen.

Typ	Källa	Händelse-ID	Allmänt
Information	OpsMgr Connector	20053	Det angivna autentiseringscertifikatet har lästs in av OpsMgr Connector.

När du installerar ett certifikat kör du verktyget MOMCertImport. När verktyget MOMCertImport har slutförts, finns serienumret för det importerade certifikatet i registret i följande undernyckel.

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

Varning

En felaktig ändring av registret kan orsaka allvarliga skador i systemet. Säkerhetskopiera viktig information på datorn innan du ändrar registret.

Autentisering och datakryptering mellan hanteringsserver, gateway-server och agenter

Kommunikation mellan de här Operations Manager-funktionerna startar med ömsesidig autentisering. Om certifikaten finns i bägge ändar av kommunikationskanalen kommer de att användas för ömsesidig autentisering. I annat fall används Kerberos version 5-protokollet. Om två funktioner separeras över en ej betrodd domän, måste ömsesidig autentisering utföras med hjälp av certifikat. Normala kommunikationer, till exempel händelser, varningar och aviseringar, och distribution av ett hanteringspaket, görs via den här kanalen. I föregående bild visas ett exempel på en avisering som genererats på en av de agenter som dirigeras till hanteringsservern. Hela vägen från agent till gateway-server används Kerberos säkerhetspaket för kryptering av informationen, eftersom gateway-servern och agenten befinner sig i samma domän. Aviseringen dekrypteras av gateway-servern och omkrypteras med hjälp av certifikaten för hanteringsservern. Gatewayservern skickar det krypterade meddelandet till hanteringsservern där hanteringsservern dekrypterar aviseringen. Viss kommunikation mellan hanteringsservern och agenten kan innehålla autentiseringsinformation, till exempel konfigurationsdata och uppgifter. Datakanalen mellan agenten och hanteringsservern lägger till ytterligare ett lager med kryptering utanpå den normala kanalkrypteringen. Ingen åtgärd från användaren krävs.

Hanteringsserver och driftkonsol, webbkonsolserver och rapportserver

Autentiseringen och datakrypteringen mellan hanteringsservern och driftkonsolen, webbkonsolservern eller rapportservern utförs med hjälp av WCF-teknik (Windows Communication Foundation). Det inledande försöket att autentisera görs med användarens inloggningsuppgifter. Kerberos-protokollet prövas först. Om Kerberos-protokollet inte fungerar görs ett nytt försök med NTLM. Om autentiseringen fortfarande misslyckas ombeds användaren att ange inloggningsuppgifterna. När autentiseringen har ägt rum krypteras dataströmmen som en funktion av antingen Kerberos-protokollet eller SSL om NTLM används.

För en rapportserver och en hanteringsserver upprättas en dataanslutning mellan hanteringsservern och SQL Server Reporting Server efter autentiseringen. Det görs enbart genom Kerberos-protokollet, vilket innebär att hanteringsservern och rapportservern måste befinna sig i betrodda domäner. Mer information om WCF finns i MSDN-artikeln What Is Windows Communication Foundation (Vad är Windows Communication Foundation?).

Hanteringsserver och rapportinformationslager

Det finns två kommunikationskanaler mellan en hanteringsserver och rapportinformationslagret:

• Den övervakande värdprocessen som skapas av hälsotjänsten (hanteringstjänsten för System Center) i en hanteringsserver
• System Center-tjänsten för dataåtkomst i hanteringsservern

Övervakande värdprocess och rapportinformationslager

Den övervakande värdprocessen startas av hälsotjänsten, som ser till att registrering av insamlade händelser och prestandaräknare skrivs till informationslagret. Windows-integrerad autentisering uppnås genom att processen körs som det dataskrivarkonto som angavs vid installationen av Rapportering. Inloggningsuppgifterna till kontot lagras på ett säkert sätt i ett Kör som-konto med namnet Åtgärdskonto för informationslager. Detta Kör som-konto är medlem i en Kör som-profil med namnet Åtgärdskonto för informationslager (som är knutet till de faktiska insamlingsreglerna).

Om informationslagret för rapportering och hanteringsservern avgränsas med en förtroendegräns (till exempel finns var och en i olika domäner utan förtroende) fungerar inte Windows-integrerad autentisering. Den här situationen kan kringgås genom att den övervakande värdprocessen kan ansluta till rapportinformationslagret med SQL Server-autentisering. Det gör du genom att skapa ett Kör som-konto (av typen enkelt konto) med SQL-kontoautentisering och göra det till medlem i Kör som-profilen med namnet Konto för SQL Server-autentisering för informationslager, och låta hanteringsservern vara måldator.

Viktigt

Som standard tilldelas Kör som-profil, Konto för SQL Server-autentisering för informationslager, till ett särskilt konto genom att använda Kör som-kontot med samma namn. Ändra aldrig det konto som är associerat med Kör som-profil, Konto för SQL Server-autentisering för informationslager. Skapa istället ett eget konto och kör ditt eget Kör som-konto och låt Kör som-kontot bli medlem i Kör som-profil, Konto för SQL Server-autentisering för informationslager.

Nedan ges en översikt över relationen mellan de olika kontouppgifterna, Kör som-kontona och Kör som-profilerna för såväl Windows-integrerad autentisering som SQL Server-autentisering.

Standard: Integrerad Windows-autentisering

1. Kör som-profil: Informationslagerkonto

   • Kör som-konto: Informationsdatalageråtgärd
   • Autentiseringsuppgifter för konto: Dataskrivarkonto (anges under installationen)

2. Kör som-profil: Konto för SQL Server-autentisering för informationslager

   • Kör som-konto: SQL Server-autentisering för informationslager
   • Kontoautentiseringsuppgifter: Specialkonto som skapats av Operations Manager (ändra inte)

Valfritt: SQL Server-autentisering

1. Kör som-profil: Konto för SQL Server-autentisering för informationslager
   • Kör som-konto: Ett Kör som-konto som du angav under installationen.
   • Autentiseringsuppgifter för konto: Ett konto som du angav under installationen.

System Center-tjänsten för dataåtkomst och rapportinformationslager

Som standard utför System Center-tjänsten för dataåtkomst, som ansvarar för att läsa data från rapportinformationslagret och göra dem tillgängliga i området Rapportparametrar, Windows-integrerad autentisering genom att köra som kontot för dataåtkomsttjänsten och konfigurationstjänsten som definierades när Operations Manager installerades.

Om informationslagret för rapportering och hanteringsservern avgränsas med en förtroendegräns (till exempel finns var och en i olika domäner utan förtroende) fungerar inte Windows-integrerad autentisering. Den här situationen kan kringgås genom att System Center-tjänsten för dataåtkomst kan ansluta till rapportinformationslagret med SQL Server-autentisering. Det gör du genom att skapa ett Kör som-konto (av typen enkelt konto) med SQL-kontoautentisering och göra det till medlem i Kör som-profilen med namnet Konto för SQL Server-autentisering för Reporting SDK, och ange hanteringsservern som måldator.

Viktigt

Som standard tilldelas Kör som-profil, Konto för SQL Server-autentisering för Reporting SDK, till ett särskilt konto genom att använda Kör som-kontot med samma namn. Gör aldrig några ändringar i kontot som är associerat med Kör som-profilen, Reporting SDK SQL Server-autentiseringskontot. Skapa istället ett eget konto och ett eget Kör som-konto, och låt Kör som-kontot bli medlem i Kör som-profil, Konto för SQL Server-autentisering för Reporting SDK.

Nedan ges en översikt över relationen mellan de olika kontouppgifterna, Kör som-kontona och Kör som-profilerna för såväl Windows-integrerad autentisering som SQL Server-autentisering.

Standard: Integrerad Windows-autentisering

1. Tjänsten för dataåtkomst och konto för konfigurationstjänst (definieras under installationen av Operations Manager)

   • Kör som-profil: Konto för SQL Server-autentisering för Reporting SDK
   • Kör som-konto: Konto för SQL Server-autentisering för Reporting SDK
   • Kontoautentiseringsuppgifter: Specialkonto som skapats av Operations Manager (ändra inte)

2. Valfritt: SQL Server-autentisering

   • Kör som-profil: Konto för SQL Server-autentisering för informationslager
   • Kör som-konto: Ett Kör som-konto som du angav under installationen.
   • Autentiseringsuppgifter för konto: Ett konto som du angav under installationen.

Driftkonsol och rapportserver

Driftkonsolen ansluter till rapportservern på port 80 via HTTP. Autentisering utförs med Windows-autentisering. Data kan krypteras med hjälp av SSL-kanalen.

Rapportserver och rapportinformationslager

Autentisering mellan rapportservern och rapportinformationslagret görs med hjälp av Windows-autentisering. Kontot som angavs som dataläsarkonto under installationen av Rapportering används som körningskonto på rapportservern. Om lösenordet för kontot ska ändras måste du göra samma lösenordsändring med hjälp av Reporting Services-Configuration Manager i SQL Server. Data mellan rapporteringsservern och informationslagret för rapportering krypteras inte.