Dela via

Gränssnittsarkitektur för säkerhetssupportleverantör

Det här referensavsnittet för IT-proffs beskriver De Windows-autentiseringsprotokoll som används i SSPI-arkitekturen (Security Support Provider Interface).

Microsoft Security Support Provider Interface (SSPI) är grunden för Windows-autentisering. Program och infrastrukturtjänster som kräver autentisering använder SSPI för att tillhandahålla den.

SSPI är implementeringen av GSSAPI (Generic Security Service API) i Windows Server-operativsystem. Mer information om GSSAPI finns i RFC 2743 och RFC 2744 i IETF RFC Database.

Standardleverantörer för säkerhetssupport (SSP: er) som anropar specifika autentiseringsprotokoll i Windows införlivas i SSPI som DLL:er. Dessa standard-SSP:er beskrivs i följande avsnitt. Ytterligare SSP:er kan införlivas om de kan användas med SSPI: et.

Som visas i följande bild tillhandahåller SSPI i Windows en mekanism som bär autentiseringstoken över den befintliga kommunikationskanalen mellan klientdatorn och servern. När två datorer eller enheter måste autentiseras så att de kan kommunicera på ett säkert sätt dirigeras begäranden om autentisering till SSPI, som slutför autentiseringsprocessen, oavsett vilket nätverksprotokoll som används för närvarande. SSPI returnerar transparenta binära stora objekt. Dessa skickas mellan programmen, då de kan skickas till SSPI-lagret. SSPI gör det därför möjligt för ett program att använda olika säkerhetsmodeller som är tillgängliga på en dator eller ett nätverk utan att ändra gränssnittet till säkerhetssystemet.

Diagram som visar gränssnittsarkitekturen för säkerhetssupportprovidern

I följande avsnitt beskrivs standard-SSP:er som interagerar med SSPI. SSP:erna används på olika sätt i Windows-operativsystem för att främja säker kommunikation i en osäker nätverksmiljö.

Ingår även i det här avsnittet:

Val av säkerhetssupportleverantör

Kerberos-säkerhetsstödleverantör

Denna SSP använder endast Kerberos version 5-protokollet som implementerats av Microsoft. Det här protokollet baseras på nätverksarbetsgruppens RFC 4120 och utkast till revisioner. Det är ett branschstandardprotokoll som används med ett lösenord eller ett smartkort för en interaktiv inloggning. Det är också den föredragna autentiseringsmetoden för tjänster i Windows.

Eftersom Kerberos-protokollet har varit standardautentiseringsprotokollet sedan Windows 2000 stöder alla domäntjänster Kerberos SSP. Dessa tjänster omfattar:

  • Active Directory-frågor som använder Lightweight Directory Access Protocol (LDAP)

  • Fjärrserver- eller arbetsstationshantering som använder fjärrproceduranropstjänsten

  • Utskriftstjänster

  • Klientserverautentisering

  • Fjärrfilåtkomst som använder SMB-protokollet (Server Message Block) (även kallat Common Internet File System eller CIFS)

  • Hantering och hänvisning av distribuerade filsystem

  • Intranätautentisering till Internet Information Services (IIS)

  • Säkerhetsutfärdarautentisering för Internet Protocol Security (IPsec)

  • Certifikatbegäranden till Active Directory Certificate Services för domänanvändare och datorer

Plats: %Windir%\System32\kerberos.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, plus Windows Server 2003 och Windows XP.

Ytterligare resurser för Kerberos-protokollet och Kerberos SSP

NTLM-säkerhetssupportleverantör

NTLM Security Support Provider (NTLM SSP) är ett binärt meddelandeprotokoll som används av SSPI (Security Support Provider Interface) för att tillåta NTLM-autentisering med utmaningssvar och förhandla om integritets- och konfidentialitetsalternativ. NTLM används där SSPI-autentisering används, inklusive för Server Message Block eller CIFS-autentisering, HTTP Negotiate-autentisering (till exempel Internet-webbautentisering) och fjärrproceduranropstjänsten. NTLM SSP innehåller NTLM- och NTLM version 2-autentiseringsprotokoll (NTLMv2).

De Windows-operativsystem som stöds kan använda NTLM SSP för följande:

  • Klient-/serverautentisering

  • Utskriftstjänster

  • Filåtkomst med hjälp av CIFS (SMB)

  • Säker fjärranropstjänst eller DCOM-tjänst

Plats: %Windir%\System32\msv1_0.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, plus Windows Server 2003 och Windows XP.

Ytterligare resurser för NTLM-protokollet och NTLM SSP

Leverantör av Digest-säkerhetstjänster

Sammanfattad autentisering är en branschstandard som används för Lightweight Directory Access Protocol (LDAP) och webbautentisering. Sammanfattad autentisering överför autentiseringsuppgifter över nätverket som en MD5-hash eller meddelandesammandrag.

Digest SSP (Wdigest.dll) används för följande:

  • Internet Explorer och IIS-åtkomst (Internet Information Services)

  • LDAP-frågor

Plats: %Windir%\System32\Wdigest.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, plus Windows Server 2003 och Windows XP.

Ytterligare resurser för Digest-protokollet och Digest SSP

Schannel Security Support-leverantör

Säker kanal (Schannel) används för webbaserad serverautentisering, till exempel när en användare försöker komma åt en säker webbserver.

TLS-protokollet, SSL-protokollet, PCT-protokollet (Private Communications Technology) och DTLS-protokollet (Datagram Transport Layer) baseras på kryptering med offentliga nycklar. Schannel tillhandahåller alla dessa protokoll. Alla Schannel-protokoll använder en klient-/servermodell. Schannel SSP använder offentliga nyckelcertifikat för att autentisera parter. När du autentiserar parter väljer Schannel SSP ett protokoll i följande prioritetsordning:

  • TLS (Transport Layer Security) version 1.0

  • TLS (Transport Layer Security) version 1.1

  • TLS (Transport Layer Security) version 1.2

  • SSL-version 2.0 (Secure Socket Layer)

  • Secure Socket Layer (SSL) version 3.0

  • Privat kommunikationsteknik (PCT)

    Not PCT är inaktiverat som standard.

Det protokoll som har valts är det föredragna autentiseringsprotokollet som klienten och servern kan stödja. Om en server till exempel stöder alla Schannel-protokoll och klienten endast stöder SSL 3.0 och SSL 2.0 använder autentiseringsprocessen SSL 3.0.

DTLS används när det uttryckligen anropas av programmet. Mer information om DTLS och andra protokoll som används av Schannel-providern finns i Teknisk referens för Schannel Security Support Provider.

Plats: %Windir%\System32\Schannel.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, plus Windows Server 2003 och Windows XP.

Note

TLS 1.2 introducerades i den här providern i Windows Server 2008 R2 och Windows 7. DTLS introducerades i den här providern i Windows Server 2012 och Windows 8.

Ytterligare resurser för TLS- och SSL-protokollen och Schannel SSP

Förhandla om säkerhetssupportprovider

SpNEGO (Simple and Protected GSS-API Negotiation Mechanism) utgör grunden för Negotiate SSP, som kan användas för att förhandla fram ett specifikt autentiseringsprotokoll. När ett program anropar SSPI för att logga in på ett nätverk kan det ange en SSP för att bearbeta begäran. Om programmet anger Negotiate SSP analyserar det begäran och väljer lämplig provider för att hantera begäran, baserat på kundkonfigurerade säkerhetsprinciper.

SPNEGO anges i RFC 2478.

I versioner av Windows-operativsystem som stöds väljer säkerhetsstödleverantören Negotiate mellan Kerberos-protokollet och NTLM. Negotiate väljer Kerberos-protokollet som standard om inte protokollet inte kan användas av något av de system som ingår i autentiseringen, eller om det anropande programmet inte gav tillräcklig information för att använda Kerberos-protokollet.

Plats: %Windir%\System32\lsasrv.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, plus Windows Server 2003 och Windows XP.

Ytterligare resurser för Negotiate SSP

Leverantör av säkerhetssupport för autentiseringsuppgifter

CredSSP tillhandahåller en enkel inloggningslösning (Single sign-on, SSO) för användarupplevelse när nya Terminaltjänster och Fjärrskrivbordstjänster startas. CredSSP gör det möjligt för program att delegera användarnas autentiseringsuppgifter från klientdatorn (med hjälp av SSP på klientsidan) till målservern (via SSP på serversidan), baserat på klientens principer. CredSSP-principer konfigureras med grupprincip och delegeringen av autentiseringsuppgifter inaktiveras som standard.

Plats: %Windir%\System32\credssp.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet.

Ytterligare resurser för SSP för autentiseringsuppgifter

Förhandla om tilläggssäkerhetssupportleverantör

Negotiate Extensions (NegoExts) är ett autentiseringspaket som förhandlar om användning av SSP:er, förutom NTLM eller Kerberos-protokollet, för program och scenarier som implementeras av Microsoft och andra programvaruföretag.

Det här tillägget till Negotiate-paketet tillåter följande scenarier:

  • Omfattande klienttillgänglighet i ett federerat system. Dokument kan nås på SharePoint-webbplatser och de kan redigeras med hjälp av ett fullständigt Microsoft Office-program.

  • Omfattande klientstöd för Microsoft Office-tjänster. Användare kan logga in på Microsoft Office-tjänster och använda ett komplett Microsoft Office-program.

  • Värdbaserad Microsoft Exchange Server och Outlook. Inget domänförtroende har upprättats eftersom Exchange Server finns på webben. Outlook använder Windows Live-tjänsten för att autentisera användare.

  • Omfattande klienttillgänglighet mellan klientdatorer och servrar. Operativsystemets nätverks- och autentiseringskomponenter används.

Windows Negotiate-paketet behandlar NegoExts SSP på samma sätt som för Kerberos och NTLM. NegoExts.dll laddas in i Local System Authority (LSA) vid start. När en autentiseringsbegäran tas emot, baserat på begärans källa, förhandlar NegoExts mellan de SSP:er som stöds. Den samlar in autentiseringsuppgifter och principer, krypterar dem och skickar informationen till lämplig SSP, där säkerhetstoken skapas.

SSP:er som stöds av NegoExts är inte fristående SSP:er som Kerberos och NTLM. Därför visas eller loggas ett meddelande om autentiseringsfel i NegoExts SSP när autentiseringsmetoden av någon anledning misslyckas. Det är inte möjligt att omförhandla eller använda alternativa autentiseringsmetoder.

Plats: %Windir%\System32\negoexts.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, exklusive Windows Server 2008 och Windows Vista.

PKU2U-leverantör av säkerhetsstöd

PKU2U-protokollet introducerades och implementerades som en SSP i Windows 7 och Windows Server 2008 R2 . Denna SSP möjliggör peer-to-peer-autentisering, särskilt via medie- och fildelningsfunktionen HomeGroup, som introducerades i Windows 7 . Funktionen tillåter delning mellan datorer som inte är medlemmar i en domän.

Plats: %Windir%\System32\pku2u.dll

Den här providern ingår som standard i versioner som anges i listan Gäller för i början av det här avsnittet, exklusive Windows Server 2008 och Windows Vista.

Ytterligare resurser för PKU2U-protokollet och PKU2U SSP

Val av säkerhetssupportleverantör

Windows SSPI kan använda något av de protokoll som stöds via de installerade säkerhetssupportleverantörerna. Men eftersom inte alla operativsystem stöder samma SSP-paket som alla datorer som kör Windows Server, måste klienter och servrar förhandla om att använda ett protokoll som båda stöder. Windows Server föredrar att klientdatorer och program använder Kerberos-protokollet, ett starkt standardbaserat protokoll, när det är möjligt, men operativsystemet fortsätter att tillåta klientdatorer och klientprogram som inte stöder Kerberos-protokollet att autentiseras.

Innan autentiseringen kan äga rum måste de två kommunicerande datorerna komma överens om ett protokoll som båda kan stödja. För att alla protokoll ska kunna användas via SSPI måste varje dator ha rätt SSP. För att en klientdator och server ska kunna använda Kerberos-autentiseringsprotokollet måste båda ha stöd för Kerberos v5. Windows Server använder funktionen EnumerateSecurityPackages för att identifiera vilka SSP:er som stöds på en dator och vilka funktioner dessa SSP:er har.

Valet av ett autentiseringsprotokoll kan hanteras på något av följande två sätt:

  1. Protokoll för enkel autentisering

  2. Alternativet Förhandla

Protokoll för enkel autentisering

När ett enda godtagbart protokoll anges på servern måste klientdatorn ha stöd för det angivna protokollet eller så misslyckas kommunikationen. När ett enda godtagbart protokoll anges sker autentiseringsutbytet på följande sätt:

  1. Klientdatorn begär åtkomst till en tjänst.

  2. Servern svarar på begäran och anger vilket protokoll som ska användas.

  3. Klientdatorn undersöker innehållet i svaret och kontrollerar om det stöder det angivna protokollet. Om klientdatorn stöder det angivna protokollet fortsätter autentiseringen. Om klientdatorn inte stöder protokollet misslyckas autentiseringen, oavsett om klientdatorn har behörighet att komma åt resursen.

Alternativet Förhandla

Alternativet förhandla kan användas för att tillåta att klienten och servern försöker hitta ett acceptabelt protokoll. Detta baseras på SPNEGO (Simple and Protected GSS-API Negotiation Mechanism). När autentiseringen börjar med alternativet att förhandla om ett autentiseringsprotokoll sker SPNEGO-utbytet på följande sätt:

  1. Klientdatorn begär åtkomst till en tjänst.

  2. Servern svarar med en lista över autentiseringsprotokoll som den kan stödja och en autentiseringsutmaning eller ett svar, baserat på det protokoll som är det första valet. Servern kan till exempel lista Kerberos-protokollet och NTLM och skicka ett Kerberos-autentiseringssvar.

  3. Klientdatorn undersöker innehållet i svaret och kontrollerar om det stöder något av de angivna protokollen.

    • Om klientdatorn stöder det föredragna protokollet fortsätter autentiseringen.

    • Om klientdatorn inte stöder det föredragna protokollet, men det stöder något av de andra protokollen som anges av servern, låter klientdatorn servern veta vilket autentiseringsprotokoll som stöds och autentiseringen fortsätter.

    • Om klientdatorn inte stöder något av de angivna protokollen misslyckas autentiseringsutbytet.

Ytterligare referenser

Arkitektur för Windows-autentisering