Autentiseringsprocesser i Windows-autentisering

Det här referensavsnittet för IT-proffs beskriver hur Windows-autentisering bearbetar autentiseringsuppgifter.

Hantering av Windows-autentiseringsuppgifter är den process genom vilken operativsystemet tar emot autentiseringsuppgifterna från tjänsten eller användaren och skyddar informationen för framtida presentation till autentiseringsmålet. När det gäller en domänansluten dator är autentiseringsmålet domänkontrollanten. Autentiseringsuppgifterna som används i autentiseringen är digitala dokument som associerar användarens identitet med någon form av äkthetsbevis, till exempel ett certifikat, ett lösenord eller en PIN-kod.

Som standard verifieras Windows-autentiseringsuppgifter mot SAM-databasen (Security Accounts Manager) på den lokala datorn eller mot Active Directory på en domänansluten dator via Winlogon-tjänsten. Autentiseringsuppgifter samlas in via användarens inmatning i inloggningsgränssnittet eller programmatiskt via applikationsprogrammeringsgränssnittet (API) för att presenteras för autentiseringsmålet.

Lokal säkerhetsinformation lagras i registret under HKEY_LOCAL_MACHINE\SECURITY. Lagrad information innehåller principinställningar, standardsäkerhetsvärden och kontoinformation, till exempel cachelagrade inloggningsuppgifter. En kopia av SAM-databasen lagras också här, även om den är skrivskyddad.

Följande diagram visar de komponenter som krävs och de sökvägar som autentiseringsuppgifterna tar genom systemet för att autentisera användaren eller bearbeta för en lyckad inloggning.

I följande tabell beskrivs varje komponent som hanterar autentiseringsuppgifter i autentiseringsprocessen vid inloggningspunkten.

Autentiseringskomponenter för alla system

Komponent	Beskrivning
Användarinloggning	Winlogon.exe är den körbara fil som ansvarar för att hantera säkra användarinteraktioner. Winlogon-tjänsten initierar inloggningsprocessen för Windows-operativsystem genom att skicka de autentiseringsuppgifter som samlas in av användaråtgärden på det säkra skrivbordet (inloggningsgränssnittet) till den lokala säkerhetsmyndigheten (LSA) via Secur32.dll.
Applikationsinloggning	Program- eller tjänstinloggning som inte kräver interaktiv inloggning. De flesta processer som initieras av användaren körs i användarläge med hjälp av Secur32.dll medan processer som initieras vid start, till exempel tjänster, körs i kernelläge med hjälp av Ksecdd.sys. Mer information om användarläge och kernelläge finns i Program och användarläge eller Tjänster och Kernelläge i det här avsnittet.
Secur32.dll	De flera autentiseringsprovidrar som utgör grunden för autentiseringsprocessen.
Lsasrv.dll	LSA Server-tjänsten, som både tillämpar säkerhetsprinciper och fungerar som säkerhetspakethanterare för LSA. LSA innehåller funktionen Negotiate, som väljer antingen NTLM- eller Kerberos-protokollet efter att ha fastställt vilket protokoll som ska lyckas.
Leverantörer av säkerhetssupport	En uppsättning leverantörer som individuellt kan anropa ett eller flera autentiseringsprotokoll. Standarduppsättningen med providers kan ändras med varje version av Windows-operativsystemet och anpassade leverantörer kan skrivas.
Netlogon.dll	De tjänster som tjänsten Net Logon utför är följande: – Underhåller datorns säkra kanal (ska inte förväxlas med Schannel) till en domänkontrollant. – Skickar användarens autentiseringsuppgifter via en säker kanal till domänkontrollanten och returnerar domänsäkerhetsidentifierare (SID) och användarrättigheter för användaren. – Publicerar tjänstresursposter i DNS (Domain Name System) och använder DNS för att matcha namn till IP-adresserna (Internet Protocol) för domänkontrollanter. – Implementerar replikeringsprotokollet baserat på RPC (Remote Procedure Call) för synkronisering av primära domänkontrollanter (PDC) och säkerhetskopiering av domänkontrollanter (BDC).
Samsrv.dll	Security Accounts Manager (SAM), som lagrar lokala säkerhetskonton, tillämpar lokalt lagrade principer och stöder API:er.
Registeringssystem	Registret innehåller en kopia av SAM-databasen, lokala säkerhetsprincipinställningar, standardsäkerhetsvärden och kontoinformation som endast är tillgänglig för systemet.

Det här avsnittet innehåller följande avsnitt:

• Inmatning av inloggningsuppgifter

• Indata för autentiseringsuppgifter för program- och tjänstinloggning

• Lokal säkerhetsmyndighet

• Cachelagrade autentiseringsuppgifter och validering

• Lagring och validering av autentiseringsuppgifter

• Säkerhetskontohanterare-databas

• Lokala domäner och betrodda domäner

• Certifikat i Windows-autentisering

Inmatning av autentiseringsuppgifter för användarinloggning

I Windows Server 2008 och Windows Vista ersattes gina-arkitekturen (Grafisk identifiering och autentisering) med en providermodell för autentiseringsuppgifter, vilket gjorde det möjligt att räkna upp olika inloggningstyper med hjälp av inloggningspaneler. Båda modellerna beskrivs nedan.

Arkitektur för grafisk identifiering och autentisering

Gina-arkitekturen (Grafisk identifiering och autentisering) gäller för operativsystemen Windows Server 2003, Microsoft Windows 2000 Server, Windows XP och Windows 2000 Professional. I dessa system skapar varje interaktiv inloggningssession en separat instans av Winlogon-tjänsten. GINA-arkitekturen läses in i processutrymmet som används av Winlogon, tar emot och bearbetar autentiseringsuppgifterna och gör anropen till autentiseringsgränssnitten via LSALogonUser.

Instanserna av Winlogon för en interaktiv inloggning körs i session 0. Session 0 är värd för systemtjänster och andra kritiska processer, inklusive LSA-processen (Local Security Authority).

Följande diagram visar autentiseringsprocessen för Windows Server 2003, Microsoft Windows 2000 Server, Windows XP och Microsoft Windows 2000 Professional.

Arkitektur för autentiseringsuppgiftstillhandahållare

Providerarkitekturen för autentiseringsuppgifter gäller för de versioner som anges i listan Gäller för i början av det här avsnittet. I dessa system har indataarkitekturen för autentiseringsuppgifter ändrats till en utökningsbar design med hjälp av autentiseringsproviders. Dessa leverantörer representeras av de olika inloggningspanelerna på det säkra skrivbordet som tillåter valfritt antal inloggningsscenarier – olika konton för samma användare och olika autentiseringsmetoder, till exempel lösenord, smartkort och biometri.

Med arkitekturen för autentiseringsleverantören startar Winlogon alltid inloggningsgränssnittet när det har fått en säker uppmärksamhetssekvenshändelse. Inloggningsgränssnittet frågar varje autentiseringsprovider om antalet olika typer av autentiseringsuppgifter som providern är konfigurerad att räkna upp. Autentiseringsprovidrar har möjlighet att ange en av dessa paneler som standard. När alla leverantörer har räknat upp sina paneler visar användargränssnittet för inloggning dem för användaren. Användaren interagerar med en panel för att ange sina autentiseringsuppgifter. Inloggningsgränssnittet skickar dessa autentiseringsuppgifter för autentisering.

Autentiseringsprovidrar är inte tillämpningsmekanismer. De används för att samla in och serialisera autentiseringsuppgifter. De lokala säkerhetsauktoriserings- och autentiseringspaketen tillämpar säkerhet.

Autentiseringsprovidrar är registrerade på datorn och ansvarar för följande:

• Beskriver den information om autentiseringsuppgifter som krävs för autentisering.

• Hantera kommunikation och logik med externa autentiseringsmyndigheter.

• Paketera autentiseringsuppgifter för interaktiv inloggning och nätverksinloggning.

Paketering av autentiseringsuppgifter för interaktiv inloggning och nätverksinloggning omfattar serialiseringsprocessen. Genom att serialisera autentiseringsuppgifter kan flera inloggningspaneler visas i inloggningsgränssnittet. Därför kan din organisation styra inloggningsvisningen, till exempel användare, målsystem för inloggning, förinloggningsåtkomst till nätverket och principer för lås/upplåsning av arbetsstationer – med hjälp av anpassade leverantörer av autentiseringsuppgifter. Flera leverantörer av autentiseringsuppgifter kan samexistera på samma dator.

Leverantörer av enkel inloggning (SSO) kan utvecklas som en standardprovider för autentiseringsuppgifter eller som en pre-Logon-Access-provider.

Varje version av Windows innehåller en standardprovider för autentiseringsuppgifter och en standard Pre-Logon-Access Provider (PLAP), som också kallas SSO-provider. SSO-providern tillåter användare att upprätta en anslutning till ett nätverk innan de loggar in på den lokala datorn. När den här providern implementeras räknar providern inte upp paneler i användargränssnittet för inloggning.

En SSO-provider är avsedd att användas i följande scenarier:

• Nätverksautentisering och datorinloggning hanteras av olika leverantörer av autentiseringsuppgifter. Variationer i det här scenariot är:

  • En användare har möjlighet att ansluta till ett nätverk, till exempel ansluta till ett virtuellt privat nätverk (VPN), innan han eller hon loggar in på datorn, men det krävs inte för att upprätta den här anslutningen.

  • Nätverksautentisering krävs för att hämta information som används under interaktiv autentisering på den lokala datorn.

  • Flera nätverksautentiseringar följs av ett av de andra scenarierna. En användare autentiserar till exempel till en Internetleverantör (ISP), autentiserar till ett VPN och använder sedan sina autentiseringsuppgifter för användarkontot för att logga in lokalt.

  • Cachelagrade autentiseringsuppgifter är inaktiverade och en anslutning för fjärråtkomsttjänster via VPN krävs innan lokal inloggning för att autentisera användaren.

  • En domänanvändare har inget lokalt konto konfigurerat på en domänansluten dator och måste upprätta en anslutning för fjärråtkomsttjänster via VPN-anslutning innan den interaktiva inloggningen slutförs.

• Nätverksautentisering och datorinloggning hanteras av samma autentiseringsprovider. I det här scenariot måste användaren ansluta till nätverket innan han eller hon loggar in på datorn.

Uppräkning av inloggningspanel

Providern för autentiseringsuppgifter räknar upp inloggningspaneler i följande instanser:

• För de operativsystem som anges i listan Gäller för i början av det här avsnittet.

• Providern för autentiseringsuppgifter räknar upp panelerna för arbetsstationsinloggning. Providern för autentiseringsuppgifter serialiserar vanligtvis autentiseringsuppgifter för autentisering till den lokala säkerhetsmyndigheten. Den här processen visar paneler som är specifika för varje användare och som är specifika för varje användares målsystem.

• Med arkitekturen för inloggning och autentisering kan en användare använda paneler som räknas upp av autentiseringsprovidern för att låsa upp en arbetsstation. Normalt är den inloggade användaren standardpanelen, men om fler än en användare är inloggad visas flera paneler.

• Providern för autentiseringsuppgifter räknar upp paneler som svar på en användarbegäran om att ändra sitt lösenord eller annan privat information, till exempel en PIN-kod. Normalt är den inloggade användaren standardpanelen. Men om fler än en användare är inloggad visas flera paneler.

• Credential-leverantören räknar upp brickor baserat på de serialiserade uppgifterna som ska användas för autentisering på fjärrdatorer. Användargränssnittet för autentiseringsuppgifter använder inte samma instans av providern som inloggningsgränssnittet, Lås upp arbetsstation eller Ändra lösenord. Därför kan statusinformation inte upprätthållas i tjänsteleverantören mellan instanser av autentiseringsgränssnittet. Den här strukturen resulterar i en panel för varje fjärrdatorinloggning, förutsatt att autentiseringsuppgifterna har serialiserats korrekt. Det här scenariot används också i UAC (User Account Control), som kan hjälpa till att förhindra obehöriga ändringar på en dator genom att be användaren om behörighet eller ett administratörslösenord innan åtgärder som kan påverka datorns åtgärd tillåts eller som kan ändra inställningar som påverkar andra användare av datorn.

Följande diagram visar autentiseringsprocessen för de operativsystem som anges i listan Gäller för i början av det här avsnittet.

Autentiseringsuppgifter för program- och tjänstinloggning

Windows-autentisering är utformat för att hantera autentiseringsuppgifter för program eller tjänster som inte kräver användarinteraktion. Program i användarläge är begränsade när det gäller vilka systemresurser de har åtkomst till, medan tjänster kan ha obegränsad åtkomst till systemminnet och externa enheter.

Systemtjänster och program på transportnivå får åtkomst till en SSP (Security Support Provider Interface) via SSPI (Security Support Provider Interface) i Windows, som tillhandahåller funktioner för att räkna upp de säkerhetspaket som är tillgängliga i ett system, välja ett paket och använda paketet för att få en autentiserad anslutning.

När en klient-/serveranslutning autentiseras:

• Programmet på klientsidan av anslutningen skickar autentiseringsuppgifter till servern med hjälp av SSPI-funktionen InitializeSecurityContext (General).

• Programmet på serversidan av anslutningen svarar med SSPI-funktionen AcceptSecurityContext (General).

• SSPI-funktionerna InitializeSecurityContext (General) och AcceptSecurityContext (General) upprepas tills alla nödvändiga autentiseringsmeddelanden har utväxlades för att antingen lyckas eller misslyckas med autentisering.

• När anslutningen har autentiserats använder LSA på servern information från klienten för att skapa säkerhetskontexten, som innehåller en åtkomsttoken.

• Servern kan sedan anropa SSPI-funktionen ImpersonateSecurityContext för att koppla åtkomsttoken till en personifieringstråd för tjänsten.

Program och användarläge

Användarläget i Windows består av två system som kan skicka I/O-begäranden till lämpliga drivrutiner i kernelläge: miljösystemet, som kör program skrivna för många olika typer av operativsystem, och det integrerade systemet, som driver systemspecifika funktioner för miljösystemets räkning.

Det integrerade systemet hanterar operativsystemets specifika funktioner för miljösystemets räkning och består av en säkerhetssystemprocess (LSA), en arbetsstationstjänst och en servertjänst. Säkerhetssystemprocessen hanterar säkerhetstoken, beviljar eller nekar behörighet att komma åt användarkonton baserat på resursbehörigheter, hanterar inloggningsbegäranden och initierar inloggningsautentisering och avgör vilka systemresurser som operativsystemet behöver granska.

Program kan köras i användarläge där programmet kan köras som vilket huvudnamn som helst, även i säkerhetskontexten för det lokala systemet (SYSTEM). Program kan också köras i kernelläge där programmet kan köras i säkerhetskontexten för lokalt system (SYSTEM).

SSPI är tillgängligt via modulen Secur32.dll, som är ett API som används för att hämta integrerade säkerhetstjänster för autentisering, meddelandeintegritet och meddelandesekretess. Det ger ett abstraktionslager mellan protokoll på programnivå och säkerhetsprotokoll. Eftersom olika program kräver olika sätt att identifiera eller autentisera användare och olika sätt att kryptera data när de färdas i ett nätverk, ger SSPI ett sätt att komma åt dynamiska länkbibliotek (DLL:er) som innehåller olika autentiserings- och kryptografiska funktioner. Dessa DLL:er kallas SSP:er (Security Support Providers).

Hanterade tjänstkonton och virtuella konton introducerades i Windows Server 2008 R2 och Windows 7 för att tillhandahålla viktiga program, till exempel Microsoft SQL Server och Internet Information Services (IIS), med isolering av sina egna domänkonton, samtidigt som administratören inte behöver administrera tjänstens huvudnamn (SPN) manuellt och autentiseringsuppgifter för dessa konton. Mer information om dessa funktioner och deras roll i autentisering finns i Dokumentation om hanterade tjänstkonton för Windows 7 och Windows Server 2008 R2 och Översikt över grupphanterade tjänstkonton.

Tjänster och kärnläge

Även om de flesta Windows-program körs i säkerhetskontexten för den användare som startar dem gäller detta inte för tjänster. Många Windows-tjänster, till exempel nätverk och utskriftstjänster, startas av tjänstkontrollanten när användaren startar datorn. Dessa tjänster kan köras som lokal tjänst eller lokalt system och kan fortsätta att köras efter att den senaste mänskliga användaren har loggat ut.

Anmärkning

Tjänster körs normalt i säkerhetskontexter som kallas lokalt system (SYSTEM), nätverkstjänst eller lokal tjänst. Windows Server 2008 R2 introducerade tjänster som körs under ett hanterat tjänstkonto, som är domänobjekt.

Innan du startar en tjänst loggar tjänstkontrollanten in med det konto som är avsett för tjänsten och visar sedan tjänstens autentiseringsuppgifter för autentisering av LSA. Windows-tjänsten implementerar ett programmatiskt gränssnitt som tjänststyrenhetshanteraren kan använda för att styra tjänsten. En Windows-tjänst kan startas automatiskt när systemet startas eller manuellt med ett tjänstkontrollprogram. När en Windows-klientdator till exempel ansluter till en domän ansluter messenger-tjänsten på datorn till en domänkontrollant och öppnar en säker kanal till den. För att få en autentiserad anslutning måste tjänsten ha autentiseringsuppgifter som fjärrdatorns lokala säkerhetsmyndighet (LSA) litar på. Vid kommunikation med andra datorer i nätverket använder LSA autentiseringsuppgifterna för den lokala datorns domänkonto, liksom alla andra tjänster som körs i säkerhetskontexten för det lokala systemet och nätverkstjänsten. Tjänster på den lokala datorn körs som SYSTEM så att autentiseringsuppgifterna inte behöver visas för LSA.

Filen Ksecdd.sys hanterar och krypterar dessa autentiseringsuppgifter och använder ett lokalt proceduranrop till LSA. Filtypen är DRV (drivrutin) och kallas för SSP (Kernel-Mode Security Support Provider) och är FIPS 140-2 Level 1-kompatibel i de versioner som anges i listan Gäller för i början av det här avsnittet.

Kernel-läget har fullständig åtkomst till datorns maskinvaru- och systemresurser. Kernelläget hindrar tjänster och program i användarläge från att komma åt kritiska delar av operativsystemet som de inte ska ha åtkomst till.

Lokal säkerhetsmyndighet

LSA (Local Security Authority) är en skyddad systemprocess som autentiserar och loggar in användare på den lokala datorn. Dessutom underhåller LSA information om alla aspekter av lokal säkerhet på en dator (dessa aspekter kallas gemensamt för den lokala säkerhetsprincipen) och tillhandahåller olika tjänster för översättning mellan namn och säkerhetsidentifierare (SID). Säkerhetssystemprocessen, Local Security Authority Server Service (LSASS), håller reda på säkerhetsprinciperna och de konton som gäller för ett datorsystem.

LSA verifierar en användares identitet baserat på vilken av följande två entiteter som utfärdade användarens konto:

• Lokal säkerhetsmyndighet. LSA kan verifiera användarinformation genom att kontrollera sam-databasen (Security Accounts Manager) på samma dator. Alla arbetsstationer eller medlemsservrar kan lagra lokala användarkonton och information om lokala grupper. Dessa konton kan dock endast användas för åtkomst till den arbetsstationen eller datorn.

• Säkerhetsutfärdare för den lokala domänen eller för en betrodd domän. LSA kontaktar den enhet som utfärdade kontot och begär verifiering av att kontot är giltigt och att begäran kommer från kontoinnehavaren.

LSASS (Local Security Authority Subsystem Service) lagrar autentiseringsuppgifter i minnet för användare med aktiva Windows-sessioner. Med lagrade autentiseringsuppgifter kan användarna sömlöst komma åt nätverksresurser, till exempel filresurser, Exchange Server-postlådor och SharePoint-webbplatser, utan att ange sina autentiseringsuppgifter för varje fjärrtjänst igen.

LSASS kan lagra autentiseringsuppgifter i flera formulär, inklusive:

• Reversibelt krypterad klartext

• Kerberos-biljetter (biljettbeviljande biljetter (TGT), servicebiljetter)

• NT-hash

• LAN Manager-hash (LM)

Om användaren loggar in på Windows med ett smartkort lagrar LSASS inte ett lösenord i klartext, men det lagrar motsvarande NT-hashvärde för kontot och pin-koden i klartext för smartkortet. Om kontoattributet är aktiverat för ett smartkort som krävs för interaktiv inloggning genereras automatiskt ett slumpmässigt NT-hashvärde för kontot i stället för den ursprungliga lösenordshashen. Den lösenordshash som genereras automatiskt när attributet anges ändras inte.

Om en användare loggar in på en Windows-baserad dator med ett lösenord som är kompatibelt med LAN Manager-hashar (LM), finns autentiseringstoken i minnet.

Lagring av autentiseringsuppgifter i klartext i minnet kan inte inaktiveras, även om de autentiseringsproviders som kräver dem är inaktiverade.

De lagrade autentiseringsuppgifterna är direkt kopplade till LSASS-inloggningssessionerna (Local Security Authority Subsystem Service) som har startats efter den senaste omstarten och som inte har stängts. Till exempel skapas LSA-sessioner med lagrade LSA-autentiseringsuppgifter när en användare gör något av följande:

• Loggar in på en lokal session eller RDP-session (Remote Desktop Protocol) på datorn

• Kör en uppgift med hjälp av alternativet RunAs

• Kör en aktiv Windows-tjänst på datorn

• Kör en schemalagd aktivitet eller ett batchjobb

• Kör en uppgift på den lokala datorn med hjälp av ett fjärradministrationsverktyg

I vissa fall lagras LSA-hemligheterna, som är hemliga data som endast är tillgängliga för SYSTEM-kontoprocesser, på hårddisken. Vissa av dessa hemligheter är autentiseringsuppgifter som måste bevaras efter omstarten och de lagras i krypterad form på hårddisken. Autentiseringsuppgifter som lagras som LSA-hemligheter kan vara:

• Kontolösenord för datorns AD DS-konto (Active Directory Domain Services)

• Kontolösenord för Windows-tjänster som har konfigurerats på datorn

• Kontolösenord för konfigurerade schemalagda aktiviteter

• Kontolösenord för IIS-programpooler och webbplatser

• Lösenord för Microsoft-konton

Klientoperativsystemet introducerades i Windows 8.1 och ger ytterligare skydd för LSA för att förhindra läsning av minne och kodinmatning genom icke-skyddade processer. Det här skyddet ökar säkerheten för de autentiseringsuppgifter som LSA lagrar och hanterar.

Mer information om dessa ytterligare skydd finns i Konfigurera ytterligare LSA-skydd.

Cachelagrade autentiseringsuppgifter och validering

Valideringsmekanismer förlitar sig på presentationen av autentiseringsuppgifter vid tidpunkten för inloggningen. Men när datorn är frånkopplad från en domänkontrollant och användaren presenterar domänautentiseringsuppgifter använder Windows processen med cachelagrade autentiseringsuppgifter i valideringsmekanismen.

Varje gång en användare loggar in på en domän cachelagrar Windows de angivna autentiseringsuppgifterna och lagrar dem i säkerhetsdatafilen i åtgärdssystemets register.

Med cachelagrade autentiseringsuppgifter kan användaren logga in på en domänmedlem utan att vara ansluten till en domänkontrollant i domänen.

Lagring och validering av autentiseringsuppgifter

Det är inte alltid önskvärt att använda en uppsättning autentiseringsuppgifter för åtkomst till olika resurser. En administratör kanske till exempel vill använda administrativa autentiseringsuppgifter i stället för användarautentiseringsuppgifter vid åtkomst till en fjärrserver. På samma sätt, om en användare har åtkomst till externa resurser, till exempel ett bankkonto, kan han eller hon bara använda autentiseringsuppgifter som skiljer sig från deras domänautentiseringsuppgifter. I följande avsnitt beskrivs skillnaderna i hantering av autentiseringsuppgifter mellan aktuella versioner av Windows-operativsystem och Operativsystemen Windows Vista och Windows XP.

Processerna för fjärrinloggningsuppgifter

RDP (Remote Desktop Protocol) hanterar autentiseringsuppgifterna för den användare som ansluter till en fjärrdator med hjälp av fjärrskrivbordsklienten, som introducerades i Windows 8. Autentiseringsuppgifterna i klartext skickas till målservern där servern utför autentiseringsprocessen och, om det lyckas, ansluter användaren till de tillåtna resurserna. RDP lagrar inte autentiseringsuppgifterna på klienten, men användarens domänautentiseringsuppgifter lagras i LSASS.

Det begränsade administratörsläget introducerades i Windows Server 2012 R2 och Windows 8.1 och ger ytterligare säkerhet för fjärrinloggningsscenarier. Det här läget för Fjärrskrivbord gör att klientprogrammet utför en utmaningssvar för nätverksinloggning med envägsfunktionen NT (NTOWF) eller använder en Kerberos-tjänstbiljett när den autentiserar till fjärrvärden. När administratören har autentiserats har administratören inte respektive kontoautentiseringsuppgifter i LSASS eftersom de inte har angetts till fjärrvärden. Administratören har i stället autentiseringsuppgifterna för datorkontot för sessionen. Administratörsautentiseringsuppgifter tillhandahålls inte till fjärrvärden, så åtgärder utförs som datorkonto. Resurser är också begränsade till datorkontot och administratören kan inte komma åt resurser med sitt eget konto.

Automatisk omstart av inloggningsautentiseringsprocess

När en användare loggar in på en Windows 8.1-enhet sparar LSA användarautentiseringsuppgifterna i krypterat minne som endast kan nås av LSASS.exe. När Windows Update initierar en automatisk omstart utan användarnärvaro används dessa autentiseringsuppgifter för att konfigurera automatisk inloggning för användaren.

Vid omstart loggas användaren in automatiskt via mekanismen Autologon och sedan låses datorn ytterligare för att skydda användarens session. Låsning initieras via Winlogon medan autentiseringsuppgifterna hanteras av LSA. Genom att automatiskt logga in och låsa användarens session på konsolen, startas användarens låsskärmsprogram om och blir tillgängliga.

Mer information om ARSO finns i Winlogon Automatic Restart Sign-On (ARSO).

Lagrade användarnamn och lösenord i Windows Vista och Windows XP

I Windows Server 2008, Windows Server 2003, Windows Vista och Windows XP förenklar lagrade användarnamn och lösenord på Kontrollpanelen hanteringen och användningen av flera uppsättningar inloggningsuppgifter, inklusive X.509-certifikat som används med smartkort och Windows Live-autentiseringsuppgifter (kallas nu Microsoft-konto). Autentiseringsuppgifterna – en del av användarens profil – lagras tills det behövs. Den här åtgärden kan öka säkerheten per resurs genom att säkerställa att om ett lösenord komprometteras äventyrar det inte all säkerhet.

När en användare loggar in och försöker komma åt ytterligare lösenordsskyddade resurser, till exempel en resurs på en server, och om användarens standardautentiseringsuppgifter för inloggning inte räcker för att få åtkomst, efterfrågas lagrade användarnamn och lösenord . Om alternativa autentiseringsuppgifter med rätt inloggningsinformation har sparats i Lagrade användarnamn och lösenord används dessa autentiseringsuppgifter för att få åtkomst. Annars uppmanas användaren att ange nya autentiseringsuppgifter, som sedan kan sparas för återanvändning, antingen senare i inloggningssessionen eller under en efterföljande session.

Följande begränsningar gäller:

• Om Lagrade användarnamn och lösenord innehåller ogiltiga eller felaktiga autentiseringsuppgifter för en specifik resurs nekas åtkomst till resursen och dialogrutan Lagrade användarnamn och lösenord visas inte.

• Lagrade användarnamn och lösenord lagrar endast autentiseringsuppgifter för NTLM, Kerberos-protokoll, Microsoft-konto (tidigare Windows Live ID) och SSL-autentisering (Secure Sockets Layer). Vissa versioner av Internet Explorer har en egen cache för grundläggande autentisering.

Dessa autentiseringsuppgifter blir en krypterad del av en användares lokala profil i katalogen \Documents and Settings\Username\Application Data\Microsoft\Credentials. Det innebär att dessa autentiseringsuppgifter kan följa med användaren om användarens nätverkspolicy stöder Roaming-användarprofiler. Men om användaren har kopior av lagrade användarnamn och lösenord på två olika datorer och ändrar de autentiseringsuppgifter som är associerade med resursen på en av dessa datorer, sprids inte ändringen till Lagrade användarnamn och lösenord på den andra datorn.

Windows Vault och Credential Manager

Autentiseringshanteraren introducerades i Windows Server 2008 R2 och Windows 7 som en kontrollpanelfunktion för att lagra och hantera användarnamn och lösenord. Med autentiseringshanteraren kan användare lagra autentiseringsuppgifter som är relevanta för andra system och webbplatser i det säkra Windows-valvet. Vissa versioner av Internet Explorer använder den här funktionen för autentisering till webbplatser.

Hantering av autentiseringsuppgifter med hjälp av Credential Manager styrs av användaren på den lokala datorn. Användare kan spara och lagra autentiseringsuppgifter från webbläsare och Windows-program som stöds för att göra det praktiskt när de behöver logga in på dessa resurser. Autentiseringsuppgifter sparas i särskilda krypterade mappar på datorn under användarens profil. Program som stöder den här funktionen (med hjälp av CREDENTIAL Manager-API:er), till exempel webbläsare och appar, kan presentera rätt autentiseringsuppgifter för andra datorer och webbplatser under inloggningsprocessen.

När en webbplats, ett program eller en annan dator begär autentisering via NTLM eller Kerberos-protokollet visas en dialogruta där du markerar kryssrutan Uppdatera standardautentiseringsuppgifter eller Spara lösenord . Den här dialogrutan som låter en användare spara autentiseringsuppgifter lokalt genereras av ett program som stöder API:erna för Credential Manager. Om användaren markerar kryssrutan Spara lösenord håller autentiseringshanteraren reda på användarens användarnamn, lösenord och relaterad information för den autentiseringstjänst som används.

Nästa gång tjänsten används tillhandahåller Credential Manager automatiskt de autentiseringsuppgifter som lagras i Windows-valvet. Om den inte godkänns uppmanas användaren att ange rätt åtkomstinformation. Om åtkomst beviljas med de nya autentiseringsuppgifterna skriver Credential Manager över den tidigare autentiseringsuppgiften med den nya och lagrar sedan de nya autentiseringsuppgifterna i Windows Vault.

Security Accounts Manager-databas

Security Accounts Manager (SAM) är en databas som lagrar lokala användarkonton och grupper. Den finns i alla Windows-operativsystem. Men när en dator är ansluten till en domän hanterar Active Directory domänkonton i Active Directory-domäner.

Till exempel deltar klientdatorer som kör ett Windows-operativsystem i en nätverksdomän genom att kommunicera med en domänkontrollant även när ingen mänsklig användare är inloggad. För att initiera kommunikation måste datorn ha ett aktivt konto i domänen. Innan den accepterar kommunikation från datorn autentiserar LSA på domänkontrollanten datorns identitet och skapar sedan datorns säkerhetskontext precis som för en mänsklig säkerhetshuvudman. Den här säkerhetskontexten definierar identiteten och funktionerna för en användare eller tjänst på en viss dator eller en användare, tjänst eller dator i ett nätverk. Åtkomsttokenet i säkerhetskontexten definierar till exempel de resurser (till exempel en filresurs eller skrivare) som kan nås och de åtgärder (till exempel läsa, skriva eller ändra) som kan utföras av den huvudprincipalen – en användare, dator eller tjänst på den resursen.

Säkerhetskontexten för en användare eller dator kan variera från en dator till en annan, till exempel när en användare loggar in på en server eller en annan arbetsstation än användarens egen primära arbetsstation. Det kan också variera från en session till en annan, till exempel när en administratör ändrar användarens rättigheter och behörigheter. Dessutom skiljer sig säkerhetskontexten vanligtvis när en användare eller dator fungerar fristående, i ett nätverk eller som en del av en Active Directory-domän.

Lokala domäner och betrodda domäner

När det finns ett förtroende mellan två domäner förlitar sig autentiseringsmekanismerna för varje domän på giltigheten för de autentiseringar som kommer från den andra domänen. Förtroenden hjälper till att ge kontrollerad åtkomst till delade resurser i en resursdomän (den betrodda domänen) genom att verifiera att inkommande autentiseringsbegäranden kommer från en betrodd utfärdare (den betrodda domänen). På så sätt fungerar förtroenden som bryggor som endast låter verifierade autentiseringsbegäranden resa mellan domäner.

Hur ett visst förtroende skickar autentiseringsbegäranden beror på hur det konfigureras. Förtroenderelationer kan vara enkelriktade genom att ge åtkomst från den betrodda domänen till resurser i den betrodda domänen, eller dubbelriktat, genom att ge åtkomst från varje domän till resurser i den andra domänen. Förtroenden är också antingen icke-transitiva, i vilket fall ett förtroende endast finns mellan de två betrodda partnerdomänerna, eller transitiva, i vilket fall ett förtroende automatiskt utökas till andra domäner som någon av partnerna litar på.

Information om domän- och skogsförtroenderelationer gällande autentisering finns i Delegerad autentisering och förtroenderelationer.

Certifikat i Windows-autentisering

En offentlig nyckelinfrastruktur (PKI) är kombinationen av programvara, krypteringstekniker, processer och tjänster som gör det möjligt för en organisation att skydda sin kommunikation och sina affärstransaktioner. Möjligheten för en PKI att skydda kommunikation och affärstransaktioner baseras på utbyte av digitala certifikat mellan autentiserade användare och betrodda resurser.

Ett digitalt certifikat är ett elektroniskt dokument som innehåller information om den entitet som det tillhör, entiteten som det utfärdades av, ett unikt serienummer eller någon annan unik identifiering, utfärdande- och förfallodatum samt ett digitalt fingeravtryck.

Autentisering är en process för att avgöra om en fjärrvärd kan vara betrodd. För att fastställa dess tillförlitlighet måste fjärrvärden tillhandahålla ett acceptabelt autentiseringscertifikat.

Fjärrvärdar upprättar sin tillförlitlighet genom att skaffa ett certifikat från en certifikatutfärdare (CA). Certifikatutfärdare kan i sin tur ha certifiering från en högre utfärdare, vilket skapar en förtroendekedja. För att avgöra om ett certifikat är tillförlitligt måste ett program fastställa identiteten för rotcertifikatutfärdare och sedan avgöra om det är tillförlitligt.

På samma sätt måste fjärrvärden eller den lokala datorn avgöra om certifikatet som visas av användaren eller programmet är autentiserat. Certifikatet som presenteras av användaren via LSA och SSPI utvärderas för autenticitet på den lokala datorn för lokal inloggning, i nätverket eller på domänen via certifikatarkiven i Active Directory.

För att skapa ett certifikat passerar autentiseringsdata genom hashalgoritmer, till exempel Secure Hash Algorithm 1 (SHA1), för att skapa ett meddelandeutdrag. Meddelandesammandraget signeras sedan digitalt med hjälp av avsändarens privata nyckel för att bevisa att meddelandesammandraget producerades av avsändaren.

Anmärkning

SHA1 är standard i Windows 7 och Windows Vista, men ändrades till SHA2 i Windows 8.

Smartkortautentisering

Smartkortsteknik är ett exempel på certifikatbaserad autentisering. Att logga in på ett nätverk med ett smartkort ger en stark form av autentisering eftersom det använder kryptografibaserad identifiering och bevis på innehav när en användare autentiseras till en domän. Active Directory Certificate Services (AD CS) tillhandahåller kryptografibaserad identifiering genom utfärdande av ett inloggningscertifikat för varje smartkort.

Information om smartkortsautentisering finns i Teknisk referens för Windows Smart Card.

Teknik för virtuella smartkort introducerades i Windows 8. Det lagrar smartkortets certifikat i datorn och skyddar det sedan med hjälp av enhetens manipuleringssäkra TPM-säkerhetschip (Trusted Platform Module). På så sätt blir datorn faktiskt smartkortet som måste ta emot användarens PIN-kod för att kunna autentiseras.

Fjärr- och trådlös autentisering

Fjärr- och trådlös nätverksautentisering är en annan teknik som använder certifikat för autentisering. Internet Authentication Service (IAS) och virtuella privata nätverksservrar använder Extensible Authentication Protocol-Transport Level Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP) eller Internet Protocol Security (IPsec) för att utföra certifikatbaserad autentisering för många typer av nätverksåtkomst, inklusive virtuella privata nätverk (VPN) och trådlösa anslutningar.

Information om certifikatbaserad autentisering i nätverk finns i autentisering och certifikat för nätverksåtkomst.

Se även

Windows-autentiseringsbegrepp