Autentisering och datakryptering för Windows-datorer

 

Gäller för: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

System Center 2012 – Operations Manager består av funktioner som hanteringsserver, gateway-server, rapportserver, använd databas, rapportinformationslager, 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 separeras av antingen en ej betrodd 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.

Information
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.

• Konfigurera Operations Manager med hjälp av verktyget MOMCertImport.

De här stegen är identiska med de du använder när du installerar certifikat på en gateway-server, med undantag av att godkännandeverktyget för gateway-servern inte behöver installeras eller köras.

Bekräfta certifikatsinstallationen

När du har installerat certifikatet korrekt finns följande händelse registrerad i händelseloggen för Operations Manager.

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.

Varning
Om du redigerar registret på ett felaktigt sätt kan det allvarligt skada systemet. Innan du ändrar något i registret bör du säkerhetskopiera alla viktiga data som finns på datorn.

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

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. Efter att hanteringsservern har tagit emot aviseringen dekrypterar hanteringsservern meddelandet, krypterar om det med Kerberos-protokollet och skickar det till hanteringsservern där det dekrypteras.

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

Autentisering och datakryptering mellan hanteringsservern och driftkonsolen, webbkonsolservern eller rapportservern åstadkoms med hjälp av WCF-tekniken (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.

Om det gäller en rapportserver och en hanteringsserver, etableras en dataanslutning mellan hanteringsservern och SQL Server Reporting Server efter att autentiseringen har utförts. 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: Windows-integrerad autentisering

Kör som-profil: Informationslagerkonto

Kör som-konto: Åtgärdskonto för informationslager

          Uppgifter: Dataskrivarkonto (anges under installation)

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

Kör som-konto: Konto för SQL Server-autentisering för informationslager

          Uppgifter: 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 skapar.

          Uppgifter: Ett konto som du skapar.

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

Som standard är det System Center-tjänsten för dataåtkomst, som ser till att data läses in från rapportinformationslagret och gör dem tillgängliga i området Rapportparametrar, som också utför Windows-integrerad autentisering genom att köra tjänsten för dataåtkomst och kontot för konfigurationstjänsten som definierades vid installationen av Operations Manager.

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: Windows-integrerad 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

          Uppgifter: 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 skapar.

          Uppgifter: Ett konto som du skapar.

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. Mer information om hur du använder SSL mellan driftkonsolen och rapportservern finns i Så här konfigurerar du Operations-konsolen för att kunna använda SSL vid anslutning till en rapporteringsserver.

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. Mer information om hur du återställer lösenordet finns i Så här ändrar du Reporting Server körning kontolösenord. Data mellan rapportservern och rapportinformationslagret krypteras inte.