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, gateway-server, rapportserver, driftdatabas, informationslager för rapportering, agent, webbkonsol och driftkonsol. Här förklaras hur autentiseringen går till och hur anslutningskanalerna där data krypteras identifieras.
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 inte agenterna i den ena domänen 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 via 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:
- Begär certifikat från certifikatutfärdaren.
- Godkänn certifikatbegärandena på certifikatutfärdaren.
- Installera de godkända certifikaten i datorns certifikatlager.
- Använd verktyget MOMCertImport för att konfigurera Operations Manager.
Anteckning
Certifikat med andra KEYSPEC än 1 stöds inte.
De här stegen är identiska med de steg du följer när du installerar certifikat på en gateway-server, bortsett från att du inte installerar eller kör verktyget för gateway-godkännande
Bekräfta certifikatsinstallationen
Om du har installerat certifikatet korrekt skrivs följande händelse till 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. Gateway-servern 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 hjälp av NTLM. Om autentiseringen fortfarande misslyckas ombeds användaren att ange inloggningsuppgifterna. Efter att autentisering har ägt rum, krypteras dataströmmen som en funktion antingen av 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 rapportinformationslagret och hanteringsservern separeras av en förtroendegräns (om de till exempel finns i olika domäner utan förtroende) kommer Windows-integrerad autentisering inte att fungera. 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
Kör som-profil: Informationslagerkonto
- Kör som-konto: Informationsdatalageråtgärd
- Autentiseringsuppgifter för konto: Dataskrivarkonto (anges under installationen)
Kör som-profil: Konto för SQL Server-autentisering för informationslager
- Kör som-konto: SQL Server-autentisering för informationslager
- Autentiseringsuppgifter för konto: Särskilt konto som skapas av Operations Manager (ändra inte)
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.
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 rapportinformationslagret och hanteringsservern skiljs åt av en förtroendegräns (det kan till exempel bero på att de finns i olika domäner mellan vilka inget förtroende har angetts) kommer Windows-integrerad autentisering inte att fungera. 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. Ändra aldrig det konto som är knutet till Kör som-profil, Konto för SQL Server-autentisering för Reporting SDK. 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
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
- Autentiseringsuppgifter för konto: Särskilt konto som skapas av Operations Manager (ändra inte)
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 måste ändras, måste du göra samma lösenordsändring med konfigurationshanteraren för Reporting Services i SQL Server. Data mellan rapportservern och rapportinformationslagret krypteras inte.