Technisch overzicht van Schannel-SSP

Artikel
09/02/2016

Gepubliceerd: augustus 2016

Is van toepassing op: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

In dit referentieonderwerp voor IT-professionals wordt uitgelegd wat Secure Channel (Schannel) Security Support Provider (SSP) is en welke verificatieservices hiermee mogelijk zijn via het TLS-protocol (Transport Layer Security) en het SSL-protocol (Secure Sockets Layer).

Dit onderwerp bevat de volgende secties:

Wat zijn TLS, SSL en Schannel?
Algemene scenario's voor TLS en SSL
Schannel SSP Technical Overview
TLS- en SSL-afhankelijkheden

Notitie

TLS wordt beschreven in het onderwerp Transport Layer Security protocol.

DTLS, dat is opgenomen in Schannel-SSP, wordt beschreven in het onderwerp Datagram Transport Layer Security protocol.

Wat zijn TLS, SSL en Schannel?

Een probleem dat bij het beheren van een netwerk moet worden aangepakt, is de beveiliging van gegevens die tussen toepassingen worden verzonden via een niet-vertrouwd netwerk. U kunt TLS/SSL gebruiken om servers en clientcomputers te verifiëren en het vervolgens gebruiken voor het versleutelen van berichten tussen de geverifieerde partijen.

De TLS-protocollen, de SSL-protocollen, het DTLS-protocol en het PCT-protocol (Private Communications Transport) zijn gebaseerd op cryptografie met openbare sleutels. Het Schannel-authenticatieprotocol biedt deze protocollen. Alle Schannel-protocollen maken gebruik van een client-servermodel. Zie Ondersteunde coderingssuites en coderingsprotocollen in de Schannel SSP voor een lijst met ondersteunde protocollen.

Een TLS/SSL-clientcomputer verzendt tijdens het verificatieproces een bericht naar een TLS/SSL-server en deze server reageert met de juiste informatie om zichzelf te verifiëren. De client en server wisselen daarna sessiesleutels uit en de verificatiedialoog wordt beëindigd. Nadat de verificatie is voltooid, kan de SSL-communicatie tussen de server en de client worden gestart met behulp van de symmetrische versleutelingssleutels die tijdens het verificatieproces zijn bepaald.

Bij TLS/SSL is het voor het verifiëren van servers ten opzichte van clients niet nodig dat er serversleutels zijn opgeslagen op domeincontrollers of in een database, zoals Active Directory Domain Services. Clients controleren de geldigheid van de referenties van een server aan de hand van certificaten van een vertrouwde basiscertificeringsinstantie (CA), die worden geïnstalleerd bij het installeren van een Windows-serverbesturingssysteem. Daarom hoeven gebruikers geen accounts te hebben om een beveiligde verbinding met een server te kunnen maken, tenzij de server gebruikersverificatie vereist.

Geschiedenis en standaarden voor TLS en SSL

SSL is in 1994 door Netscape Communications Corporation ontwikkeld voor het beveiligen van transacties via het World Wide Web. Niet lang daarna is Internet Engineering Task Force (IETF) begonnen met het ontwikkelen van een standaardprotocol dat dezelfde functionaliteit bood. Hierbij werd SSL 3.0 als basis gebruikt, waaruit uiteindelijk het TLS-protocol is ontstaan. Met ingang van Windows Server 2003 is het TLS-protocol geïmplementeerd, geheel volgens de specificatie die is gedefinieerd in de volgende specificaties uit de RFC-database van IETF:

TLS en SSL zijn vooral bekend als de protocollen die beveiligde HTTP (HTTPS) bieden voor internettransacties tussen webbrowsers en webservers. Maar TLS/SSL kan ook worden gebruikt voor andere protocollen op toepassingsniveau, zoals FTP (File Transfer Protocol), LDAP (Lightweight Directory Access Protocol) en SMTP (Simple Mail Transfer Protocol). TLS/SSL maakt serververificatie, clientverificatie, gegevensversleuteling en gegevensintegriteit mogelijk via netwerken zoals het World Wide Web.

Verschillen tussen TLS en SSL

Er is wel een aantal kleine verschillen tussen SSL 3.0 en de versies van TLS, maar in deze handleiding wordt naar het protocol verwezen als TLS/SSL.

Notitie

TLS en SSL 3.0 zijn niet uitwisselbaar, hoewel de verschillen klein zijn. Als de client en de server niet hetzelfde protocol ondersteunen, moet er een gemeenschappelijke protocol worden afgesproken om te kunnen communiceren.

Omdat SSL kwetsbaar was voor het toenemende aantal aanvallen op de beveiliging, heeft IETF internetstandaarden ontwikkeld voor een veiliger protocol, TLS. In de volgende lijst wordt beschreven welke verbeteringen in TLS zijn aangebracht ten opzichte van SSL, om communicatie via niet-vertrouwde netwerken beter te kunnen beveiligen.

Het HMAC-algoritme (Hash-based Message Authentication Code) vervangt het MAC-algoritme (Message Authentication Code) van SSL.
TLS is gestandaardiseerd en is een internetstandaard. SSL heeft talrijke varianten.
TLS bevat aanvullende waarschuwingsberichten.
Voor SSL zijn certificaten vereist die zijn uitgegeven door (of teruggekoppeld naar) de basis-CA. Wanneer u TLS gebruikt, is het niet altijd nodig om certificaten op te nemen die naar de basis-CA zijn teruggekoppeld. U kunt een CA gebruiken die als intermediair optreedt.
In de TLS-RFC zijn geen Fortezza-algoritmen opgenomen omdat deze niet openbaar kunnen worden beoordeeld.

Voordelen van TLS en SSL

TLS/SSL biedt veel voordelen ten opzichte van andere methoden voor verificatie voor clients en servers. In de volgende tabel worden enkele van deze voordelen beschreven.

Voordeel	Beschrijving
Sterke verificatie, privacy van berichten en integriteit.	TLS/SSL kan verzonden gegevens helpen beveiligen met behulp van versleuteling. Met TLS/SSL worden servers en eventueel clients geverifieerd om de identiteit aan te tonen van de systemen die bezig zijn met beveiligde communicatie. Bovendien wordt de integriteit van gegevens gegarandeerd via een integriteitscontrolewaarde. Naast het beveiligen tegen openbaarmaking van gegevens, kan het beveiligingsprotocol TLS/SSL worden gebruikt om te helpen beschermen tegen maskerade-aanvallen, man-in-the-middle-aanvallen (ook bucket-brigade-aanvallen genoemd), aanvallen waarbij de encryptieversie wordt teruggedraaid en aanvallen waarbij onderschepte code wordt herhaald.
Interoperabiliteit.	TLS/SSL werkt met de meeste webbrowsers en op de meeste besturingssystemen en webservers. Het is vaak geïntegreerd in nieuwslezers, LDAP-servers en tal van andere op de markt verkrijgbare toepassingen.
Algoritmeflexibiliteit	TLS/SSL biedt opties voor de verificatiemechanismen, versleutelingsalgoritmen en hash-algoritmen die tijdens de beveiligde sessie worden gebruikt.
Eenvoudig te implementeren	TLS/SSL wordt door veel toepassingen op transparante wijze gebruikt in Windows Server-besturingssystemen. U kunt TLS gebruiken voor betere beveiliging tijdens het websurfen wanneer u Internet Explorer en Internet Information Services (IIS) gebruikt. Als er al een servercertificaat op de server is geïnstalleerd, hoeft u alleen in Internet Explorer het selectievakje in te schakelen.
Eenvoudig te gebruiken	Omdat u TLS/SSL onder de toepassingslaag implementeert, zijn de meeste bewerkingen volledig onzichtbaar voor de clientcomputer. Dit maakt het mogelijk dat de client weinig of geen kennis van de communicatiebeveiliging hoeft te hebben om toch te worden beschermd tegen kwaadwillende personen.

Beperkingen van TLS en SSL

Er zijn een aantal beperkingen bij het gebruik van SSL/TLS, zoals beschreven in de volgende tabel.

Beperking	Beschrijving
Hogere processorbelasting	Dit is de belangrijkste beperking bij de implementatie van TLS/SSL. Bij cryptografie, en speciaal bij bewerkingen met openbare sleutels, wordt intensief gebruik gemaakt van de CPU. Als gevolg hiervan zijn de prestaties wisselend wanneer u SSL gebruikt. Er is helaas geen manier om erachter te komen hoeveel prestatievermogen u zult verliezen. De prestaties zijn wisselend, afhankelijk van hoe vaak er verbinding wordt gemaakt en hoe lang de verbindingen duren. De meeste bronnen worden door TLS gebruikt bij het tot stand brengen van verbindingen.
Meer beheertaken	Een omgeving met TLS/SSL is complex en vereist onderhoud. De systeembeheerder moet het systeem configureren en certificaten beheren.

Hogere processorbelasting

Dit is de belangrijkste beperking bij de implementatie van TLS/SSL. Bij cryptografie, en speciaal bij bewerkingen met openbare sleutels, wordt intensief gebruik gemaakt van de CPU. Als gevolg hiervan zijn de prestaties wisselend wanneer u SSL gebruikt. Er is helaas geen manier om erachter te komen hoeveel prestatievermogen u zult verliezen. De prestaties zijn wisselend, afhankelijk van hoe vaak er verbinding wordt gemaakt en hoe lang de verbindingen duren. De meeste bronnen worden door TLS gebruikt bij het tot stand brengen van verbindingen.

Meer beheertaken

Een omgeving met TLS/SSL is complex en vereist onderhoud. De systeembeheerder moet het systeem configureren en certificaten beheren.

Algemene scenario's voor TLS en SSL

Veel mensen zien TLS en SSL als protocollen die in webbrowsers worden gebruikt voor veiliger surfen op internet. Dit zijn echter ook protocollen voor algemene doeleinden die kunnen worden gebruikt wanneer verificatie en gegevensbeveiliging nodig zijn. Omdat u via SSPI (Security Service Provider Interface) toegang hebt tot deze protocollen, kunt u ze in feite voor vrijwel elke toepassing gebruiken. Veel toepassingen worden gewijzigd om te kunnen profiteren van de functies van TLS/SSL. In de volgende tabel ziet u voorbeelden van het gebruik van TLS/SSL.

Scenario	Beschrijving
SSL-transacties bij een webwinkel	Het gaat hier om standaardgebruik van SSL tussen een browser en een webserver. Een voorbeeld is de site van een webwinkel waar gebruikers het nummer van hun creditcard moeten opgeven. Via het protocol wordt eerst gecontroleerd of het certificaat van de website geldig is. Vervolgens worden de creditcardgegevens als gecodeerde tekst verzonden. Als het servercertificaat afkomstig is van een vertrouwde bron, vindt voor dit type transactie alleen verificatie van de server plaats. Voor de webpagina waar de gegevenstransacties worden uitgevoerd, bijvoorbeeld een formulier, moet TLS/SSL zijn ingeschakeld.
Geverifieerde clienttoegang tot een website met SSL-beveiliging	Op de client en de server moeten certificaten aanwezig zijn van een door beide vertrouwde certificeringsinstantie (CA). Bij Schannel-SSPl kunnen clientcertificaten op basis van een-op-een of veel-op-een worden toegewezen aan gebruikers- of computeraccounts in een Windows-serverbesturingssysteem. Deze kunnen vervolgens worden beheerd via Active Directory: gebruikers en Computers. Gebruikers kunnen dan worden geverifieerd voor een website zonder dat ze een wachtwoord hoeven op te geven. Veel-op-een-toewijzing kan in diverse situaties worden gebruikt. Als u bijvoorbeeld meerdere gebruikers toegang wilt geven tot vertrouwelijke informatie, kunt u een groep maken, de certificaten van de gebruikers toewijzen aan de groep en vervolgens de groep de voor het materiaal benodigde toegangsrechten geven. Bij een een-op-een-toewijzing heeft de server een kopie van het certificaat van de client. Wanneer een gebruiker zich aanmeldt via de clientcomputer, controleert de server of het clientcertificaat overeenkomt met de kopie. Zo’n een-op-een-toewijzing wordt doorgaans gebruikt voor persoonlijke gegevens, zoals bij een telebankierwebsite waar slechts één persoon het recht heeft om een persoonlijk account te bekijken.
Externe toegang	Bij telewerken wordt Schannel-SSP vaak gebruikt. U kunt deze technologie gebruiken voor verificatie en gegevensbeveiliging, wanneer gebruikers zich extern bij Windows-systemen of -netwerken aanmelden. Gebruikers kunnen dan op een veiliger manier toegang krijgen tot hun e-mail of zakelijke toepassingen, zowel thuis als onderweg, met minder risico dat de informatie voor iedereen op internet te lezen is.
Toegang tot SQL Server	U kunt verificatie van een clientcomputer vereisen wanneer deze verbinding maakt met een server waarop SQL Server wordt uitgevoerd. De client of de server kan zo worden geconfigureerd dat versleuteling is vereist van de gegevens die tussen deze twee worden overgebracht. Zeer vertrouwelijke gegevens, zoals die in financiële of medische databases, kunnen worden beveiligd om onbevoegde toegang te voorkomen en ervoor te zorgen dat er geen informatie over het netwerk wordt verspreid.
E-mail	Wanneer u Exchange Server gebruikt, kunt u SSP Schannel gebruiken om gegevens te beschermen als deze op het intranet of op internet van de ene naar de andere server gaan. Voor volledige end-to-end-beveiliging moet mogelijk S/MIME (Secure/Multipurpose Internet Mail Extensions) worden gebruikt. Het beveiligen van gegevens die tussen servers worden uitgewisseld, maakt het echter voor bedrijven mogelijk veilig via internet e-mail over te brengen tussen afdelingen binnen het bedrijf zelf en tussen dochterondernemingen en partners. Het speelt hierbij geen rol of S/MIME wordt gebruikt.

Schannel-SSP-architectuur

In de Windows Server-besturingssystemen is TLS opgenomen in de verificatieprotocolsuite van Schannel. Het volgende diagram laat zien welke plaats Schannel-SSP inneemt tussen deze en andere technologieën. Client- of servertoepassingen gebruiken Secur32.dll via SSPI-aanroepen om te communiceren met LSASS (Local Security Authority Subsystem Service).

Schannel-SSP-architectuur

Schannel Architecture

In de volgende tabel ziet u een lijst met beschrijvingen van de elementen die deel uitmaken van TLS/SSL.

Beveiligingssubsysteemelementen die worden gebruikt bij TLS- en SSL-verificatie

Element	Beschrijving
Schannel.dll	TLS/SSL-verificatieprotocol Dit protocol biedt verificatie via een versleuteld kanaal in plaats van een minder veilig onversleuteld kanaal.
Lsasrv.dll	LSASS dwingt beveiligingsbeleid af en fungeert als beveiligingspakketbeheerder voor de lokale certificeringsinstantie (LSA).
Netlogon.dll	Met betrekking tot TLS-services geeft de Netlogon-service gegevens over het certificaat van de gebruiker via een SSL-kanaal door aan de domeincontroller, die het gebruikerscertificaat aan een gebruikersaccount toewijst.
Secur32.dll	De provider voor meervoudige verificatie, die SSPI implementeert.

De verificatieprotocolsuite wordt ingeschakeld door Schannel-SSP, dat wordt ondersteund door de SSPI-API (Application Programming Interface) die de beveiligingsservices voor Windows Server-besturingssystemen verzorgt.

SSPI (Microsoft Security Support Provider Interface) vormt de basis voor verificatie in het Windows-besturingssysteem. Dit houdt in dat toepassingen en infrastructuurservices waarvoor verificatie is vereist, hiervoor SSPI gebruiken. Wanneer een client en een server moeten worden geverifieerd om veiliger te kunnen communiceren, worden de aanvragen voor verificatie doorgestuurd naar SSPI, dat het verificatieproces afrondt, ongeacht het op dat moment gebruikte protocol. SSPI is de implementatie van GSSAPI (Generic Security Service API). Raadpleeg de volgende RFC's in the RFC-database van IETF voor meer informatie over GSSAPI.

Zie Security Support Provider Interface Architecture voor meer informatie over de SSPI-architectuur voor alle SSP’s en uitleg hoe de Kerberos-provider in deze architectuur past.

U kunt Schannel-SSP gebruiken voor toegang tot webdiensten, zoals e-mail of persoonlijke gegevens die op webpagina's worden geleverd. Voor verificatie van derden gebruikt Schannel-SSP certificaten met een openbare sleutel. In de suite zijn vier verificatieprotocollen opgenomen. Bij het verifiëren van derden selecteert Schannel-SSP een van de vier protocollen in de volgende volgorde van voorkeur:

TLS-versie 1.2
TLS-versie 1.1
TLS-versie 1.0
SSL-versie 3.0

Schannel-SSP selecteert vervolgens het hoogste verificatieprotocol uit dit rijtje dat door zowel de client als de server kan worden ondersteund. Als een server bijvoorbeeld alle vier Schannel-protocollen ondersteunt en de clientcomputer alleen SSL 3.0, gebruikt de Schannel-provider SSL 3.0 voor verificatie.

Beheer van vertrouwde uitgevers van certificaten voor clientverificatie

Vóór Windows Server 2012 en Windows 8 konden toepassingen of processen die de Schannel-SSP gebruikten (inclusief HTTP.sys en IIS) een lijst verschaffen van de vertrouwde uitgevers van certificaten die ze ondersteunden voor clientverificatie. Deze informatie werd geboden via een certificaatvertrouwenslijst (CTL).

Als SSL of TLS wordt gebruikt en verificatie van de clientcomputer wordt vereist, kan de server zodanig worden geconfigureerd dat deze een lijst met vertrouwde certificaatverleners verzendt. Deze lijst bevat de certificaatverleners die door de server worden vertrouwd, en geeft de clientcomputer een hint welk clientcertificaat deze moet selecteren als er meerdere certificaten aanwezig zijn. Bovendien moet de certificaatketen die de clientcomputer naar de server verzendt, worden gevalideerd met de lijst met geconfigureerde vertrouwde uitgevers.

In Windows Server 2012 en Windows 8 zijn de volgende wijzigingen aangebracht in het onderliggende verificatieproces:

Beheer van een lijst met vertrouwde uitgevers op basis van een CTL wordt niet meer ondersteund.
Het verzenden van de lijst met vertrouwde uitgevers is standaard uitgeschakeld. De standaardwaarde van de registersleutel SendTrustedIssuerList is nu 0 (standaard uitgeschakeld) in plaats van 1.
De compatibiliteit met eerdere versies van het Windows-besturingssystemen blijft behouden.

Dit maakt meer vertrouwde beheerbaarheid mogelijk via de bestaande certificaatmanagement-cmdlets in de Windows PowerShell-provider en opdrachtregelprogramma's zoals certutil.exe. Hoewel de maximale grootte van de lijst met vertrouwde certificeringsinstanties die door Schannel-SSP worden ondersteund (16 KB) hetzelfde is gebleven als in Windows Server 2008 R2, is er in Windows Server 2012 een nieuw speciaal certificaatarchief aanwezig voor uitgevers van certificaten voor clientverificatie, zodat er in het client-/serverbericht geen niet-gerelateerde certificaten worden opgenomen.

Hoe het werkt

De lijst met vertrouwde uitgevers is geconfigureerd met behulp van certificaatarchieven: één standaard algemeen computercertificaatarchief en een optioneel archief per site. De bron van de lijst wordt als volgt bepaald:

Als er een specifiek referentie-archief voor de site is geconfigureerd, wordt dit als bron gebruikt.
Als er geen certificaten aanwezig zijn in het toepassingsspecifieke archief, controleert Schannel het archief voor uitgevers van certificaten voor clientverificatie op de lokale computer. Als daar certificaten aanwezig zijn, gebruikt Schannel dat archief als bron.
Als zowel het algemene archief als de lokale archieven geen certificaten bevatten, gebruikt Schannel-SSP het archief voor vertrouwde basiscertificeringsinstanties als bron voor de lijst met vertrouwde uitgevers. (Dit is ook het gedrag in Windows Server 2008 R2.)

U kunt een lijst opstellen met namen van waarschijnlijke uitgevers van certificaten die de eindgebruiker hints geeft over de te kiezen uitgever. Deze lijst wordt geconfigureerd met Groepsbeleid.

Als het archief voor vertrouwde basiscertificeringsinstanties een combinatie van basiscertificaten (zelf ondertekend) en door certificeringsinstanties uitgegeven certificaten bevat, worden standaard alleen de door certificeringsinstanties uitgegeven certificaten naar de server verzonden.

Schannel configureren voor het gebruik van het certificaatarchief voor vertrouwde uitgevers van certificaten

Schannel-SSP gebruikt standaard de hierboven beschreven archieven voor het beheren van de lijst met vertrouwde uitgevers. Voor het beheren van certificaten kunt u nog steeds de bestaande certificaatmanagement-cmdlets in de Windows PowerShell-provider gebruiken, en ook opdrachtregelprogramma's zoals certutil.exe.

Zie AD CS Administration Cmdlets in Windows (Engelstalig) voor meer informatie over het beheren van certificaten met de Windows PowerShell-provider.

Zie certutil.exe (Engelstalig) voor meer informatie over het beheren van certificaten met behulp van het certificaathulpprogramma.

Zie SCHANNEL_CRED structure (Windows) (Engelstalig) voor meer informatie over welke gegevens (met inbegrip van het toepassingsspecifieke archief) er zijn gedefinieerd voor een Schannel-referentie.

Configureren van een toepassing of functie voor gebruik van het archief voor uitgevers van certificaten voor clientverificatie

Bij sommige technologieën wordt het archief voor uitgevers van certificaten voor clientverificatie niet standaard gebruikt. In dergelijke gevallen moet u de technologie configureren voor gebruik van het archief.

In de webserver is bijvoorbeeld HTTP.sys, waarmee de Windows HTTP-serverstack wordt geïmplementeerd, niet standaard geconfigureerd voor gebruik van het archief voor uitgevers van certificaten voor clientverificatie.

Om HTTP. SYS te configureren voor gebruik van het archief voor uitgevers van certificaten voor clientverificatie kunt u de volgende opdracht gebruiken:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Om de waarden voor certhash en appid op uw server op te zoeken kunt u de volgende opdracht gebruiken:

netsh http show sslcert

Standaardinstellingen voor vertrouwensmodi

Er zijn drie vertrouwensmodi voor clientverificatie die door Schannel SSP worden ondersteund. De vertrouwensmodus bepaalt hoe de validatie van de certificaatketen voor de client wordt uitgevoerd. Dit is een instelling voor het hele systeem die wordt beheerd door REG_DWORD "ClientAuthTrustMode" onder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Waarde	Vertrouwensmodus	Beschrijving
0	Vertrouwen van de computer (standaard)	Dit vereist dat het clientcertificaat is uitgegeven door een certificaat in de lijst met vertrouwde uitgevers.
1	Uitsluitend basisvertrouwen	Dit vereist dat een clientcertificaat gekoppeld is aan een basiscertificaat dat is opgenomen in een door de aanroeper opgegeven archief van vertrouwde uitgevers. Het certificaat moet ook zijn uitgegeven vanuit uit de lijst met vertrouwde uitgevers.
2	Uitsluitend vertrouwen op certificeringsinstantie	Dit vereist dat een clientcertificaat gekoppeld is aan een certificaat van een CA die als intermediair optreedt of aan een basiscertificaat in een door de aanroeper opgegeven archief van vertrouwde uitgevers.

Zie artikel 280256 (Engelstalig) in de Microsoft Knowledge Base voor meer informatie over verificatiefouten vanwege problemen in de lijst met vertrouwde uitgevers.

TLS- en SSL-afhankelijkheden

Voor een correcte werking zijn TLS en SSL afhankelijk van diverse verwante technologieën en bronnen. In de volgende tabel worden deze technologieën en resources beschreven en wordt een overzicht gegeven van hun relatie met TLS-/SSL-verificatie.

Afhankelijkheid	Beschrijving
Besturingssysteem	TLS- en SSL-verificatie zijn afhankelijk van clientfunctionaliteit die is ingebouwd in de Windows Server-besturingssystemen en de Windows client-besturingssystemen. Als op een client of een server een besturingssysteem wordt uitgevoerd dat geen ondersteuning biedt voor TLS/SSL, is TLS-/SSL-verificatie niet mogelijk.
TCP/IP-netwerkverbinding	Als TLS- of SSL-verificatie moet worden uitgevoerd, moet er eenTCP/IP-netwerkverbinding zijn tussen de client en de doelserver. Zie TCP/IP voor meer informatie.
Active Directory-domein	Als voor een servertoepassing clientverificatie is vereist, probeert Schannel-SSP het certificaat dat door de client is ingesteld voor een gebruikersaccount, automatisch toe te wijzen. U kunt gebruikers die zich aanmelden met een clientcertificaat, verifiëren door handmatig toewijzingen te maken die de gegevens koppelen aan een Windows-gebruikersaccount. Wanneer u een certificaattoewijzing hebt gemaakt en ingeschakeld, koppelt de servertoepassing die gebruiker automatisch aan het juiste gebruikersaccount in het Windows-besturingssysteem zodra een client een certificaat aanbiedt. Als u certificaattoewijzing wilt gebruiken, moet u gebruikersaccounts in Active Directory Domain Services gebruiken. Zie Overzicht van Active Directory Domain Services voor meer informatie.
Vertrouwde certificeringsinstanties	Omdat verificatie afhankelijk is van digitale certificaten, vormen certificeringsinstanties (CA's) (zoals Verisign of Active Directory Certificate Services) een belangrijk onderdeel van TLS/SSL. Een CA is een wederzijds vertrouwd, niet-Microsoft-certificaat dat de identiteit van de certificaataanvrager (meestal een gebruiker of computer) bevestigt en vervolgens een certificaat naar de aanvrager verstuurt. In het certificaat is de identiteit van de aanvrager gebonden aan een openbare sleutel. Certificeringsinstanties zorgen, indien nodig, ook voor het vernieuwen en intrekken van certificaten. Als een client bijvoorbeeld een servercertificaat aangeboden krijgt, zal de clientcomputer wellicht proberen de CA van de server te matchen met de lijst van vertrouwde certificeringsinstanties op de client. Als de uitgevende certificeringsinstantie wordt vertrouwd, controleert de client of het certificaat authentiek is en of er niet mee is geknoeid. Zie Active Directory Certificate Services Overview (Engelstalig) voor meer informatie.

Zie ook

Technische naslaginformatie voor Schannel Security Support Provider

Delen via