Architecture de l’interface du fournisseur SSP (Security Support Provider)
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Cette rubrique de référence destinée aux professionnels de l’informatique décrit les protocoles d’authentification Windows utilisés dans le cadre de l’architecture SSPI (Security Support Provider Interface).
L’interface SSPI (Security Support Provider Interface) de Microsoft constitue la base de l’authentification Windows. Les applications et services d’infrastructure qui requièrent une authentification utilisent l’interface SSPI pour la fournir.
L’interface SSPI correspond à l’implémentation de l’API de service de sécurité générique (GSSAPI) dans les systèmes d’exploitation Windows Server. Pour plus d’informations sur GSSAPI, consultez les documents RFC 2743 et RFC 2744 dans la base de données RFC de l’IETF.
Les fournisseurs SSP (Security Support Providers) par défaut qui appellent des protocoles d’authentification spécifiques dans Windows sont incorporés dans le SSPI en tant que DLL. Ces fournisseurs SSP par défaut sont décrits dans les sections suivantes. D’autres fournisseurs SSP peuvent être incorporés s’ils peuvent fonctionner avec la SSPI.
Comme illustré dans l’image suivante, l’interface SSPI dans Windows fournit un mécanisme qui transporte des jetons d’authentification sur le canal de communication existant entre l’ordinateur client et le serveur. Lorsque deux ordinateurs ou périphériques doivent être authentifiés afin de pouvoir communiquer en toute sécurité, les demandes d’authentification sont acheminées vers l’interface SSPI, qui achève le processus d’authentification, quel que soit le protocole réseau en cours d’utilisation. L’interface SSPI renvoie des objets binaires volumineux transparents. Ceux-ci sont transmis entre les applications, à ce moment-là, ils peuvent être transmis à la couche SSPI. Ainsi, l’interface SSPI permet à une application d’utiliser différents modèles de sécurité disponibles sur un ordinateur ou réseau sans modifier l’interface du système de sécurité.
Les sections suivantes décrivent les fournisseurs SSP par défaut qui interagissent avec l’interface SSPI. Les fournisseurs SSP sont utilisés de différentes manières dans les systèmes d’exploitation Windows pour promouvoir une communication sécurisée dans un environnement réseau non sécurisé.
Également inclus dans cette rubrique :
Sélection du fournisseur SSP (Security Support Provider)
Fournisseur SSP (Security Support Provider) Kerberos
Ce fournisseur SSP utilise uniquement le protocole Kerberos version 5 implémenté par Microsoft. Ce protocole est basé sur la RFC 4120 du Groupe de travail du réseau et sur les ébauches de révisions. Il s’agit d’un protocole standard du secteur qui est utilisé avec un mot de passe ou une carte à puce pour une ouverture de session interactive. Il s’agit également de la méthode d’authentification préférée des services dans Windows.
Étant donné que le protocole Kerberos est le protocole d’authentification par défaut depuis Windows 2000, tous les services de domaine prennent en charge le fournisseur SSP Kerberos. Ces services comprennent :
Requêtes Active Directory qui utilisent le protocole LDAP
Gestion de serveur ou de station de travail distants utilisant le service d’appel de procédure distante
Services d’impression
Authentification client-serveur
Accès aux fichiers distants utilisant le protocole SMB (également appelé Common Internet File System ou CIFS)
Gestion et référence du système de fichiers distribués
Authentification intranet auprès d’Internet Information Services (IIS)
Authentification de l’autorité de sécurité pour la sécurité du protocole Internet (IPsec)
Demandes de certificat adressées aux services de certificats Active Directory pour les utilisateurs et les ordinateurs du domaine
Location: %Windir%\System32\kerberos.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.
Ressources supplémentaires pour le protocole Kerberos et le fournisseur SSP Kerberos
Améliorations Kerberos pour Windows Vista
Modifications apportées à l’authentification Kerberos pour Windows 7
Fournisseur SSP (Security Support Provider) NTLM
Le fournisseur SSP NTLM est un protocole de messagerie binaire utilisé par l’interface SSPI pour permettre l’authentification de la demande-réponse NTLM et pour négocier des options d’intégrité et de confidentialité. NTLM est utilisé partout où l’authentification SSPI est utilisée, notamment pour l’authentification du protocole SMB ou CIFS, l’authentification HTTP Negotiate (par exemple, l’authentification Web Internet) et le service d’appel de procédure distante. Le fournisseur SSP NTLM inclut les protocoles d’authentification NTLM et NTLM version 2 (NTLMv2).
Les systèmes d’exploitation Windows pris en charge peuvent utiliser le fournisseur SSP NTLM pour les éléments suivants :
Authentification client/serveur
Services d’impression
Accès aux fichiers à l’aide de CIFS (SMB)
Service d’appel de procédure distante sécurisée ou service DCOM
Location: %Windir%\System32\msv1_0.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.
Ressources supplémentaires pour le protocole NTLM et le fournisseur SSP NTLM
Modifications apportées à l’authentification NTLM dans Windows 7
Guide relatif à l’audit et à la restriction de l’utilisation du protocole NTLM
Fournisseur SSP (Security Support Provider) Digest
L’authentification Digest est une norme du secteur utilisée pour le protocole LDAP et l’authentification web. L’authentification Digest transmet les informations d’identification sur le réseau sous forme de hachage MD5 ou de synthèse de message.
Le fournisseur SSP Digest (Wdigest.dll) est utilisé pour les éléments suivants :
Accès Internet Explorer et Internet Information Services (IIS)
Requêtes LDAP
Location: %Windir%\System32\Wdigest.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.
Ressources supplémentaires pour le protocole Digest et le fournisseur SSP Digest
Fournisseur SSP (Security Support Provider) Schannel
Le canal sécurisé (Schannel) est utilisé pour l’authentification de serveur web, par exemple, lorsqu’un utilisateur tente d’accéder à un serveur web sécurisé.
Les protocoles TLS, SSL, PCT (Technologie des communications privées) et DTLS (Protocole de la couche de transport de datagrammes) sont basés sur le chiffrement à clé publique. Schannel fournit tous ces protocoles. Tous les protocoles Schannel utilisent un modèle client/serveur. Le SSP Schannel utilise des certificats de clé publique pour authentifier les tiers. Lors de l’authentification des parties, le fournisseur SSP Schannel sélectionne un protocole selon l’ordre de préférence suivant :
Protocole TLS (Transport Layer Security) version 1.0
Protocole TLS (Transport Layer Security) version 1.1
Protocole TLS (Transport Layer Security) version 1.2
SSL (Secure Socket Layer) version 2.0
SSL (Secure Socket Layer) version 3.0
Technologie des communications privées (PCT)
Note La PCT est désactivée par défaut.
Le protocole sélectionné est le protocole d’authentification préféré que le client et le serveur peuvent prendre en charge. Par exemple, si un serveur prend en charge tous les protocoles Schannel et que le client prend uniquement en charge SSL 3.0 et SSL 2.0, le processus d’authentification utilise SSL 3.0.
Le protocole DTLS est utilisé quand l’application l’appelle explicitement. Pour plus d’informations sur DTLS et les autres protocoles utilisés par le fournisseur Schannel, consultez Référence technique du fournisseur de support de sécurité Schannel.
Emplacement : %Windir%\System32\Schannel.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.
Notes
Le protocole TLS 1.2 a été introduit dans ce fournisseur dans Windows Server 2008 R2 et Windows 7. Le protocole DTLS a été introduit dans ce fournisseur dans Windows Server 2012 et Windows 8.
Ressources supplémentaires pour les protocoles TLS et SSL et le fournisseur SSP Schannel
Fournisseur SSP (Security Support Provider) Negotiate
Le mécanisme de négociation DSGS-API simple et protégé (SPNEGO) constitue la base du SSP Negotiate, qui peut être utilisé pour négocier un protocole d’authentification spécifique. Lorsqu'une application appelle un SSPI à se connecter à un réseau, il peut spécifier un SSP pour traiter la demande. Si l’application spécifie le fournisseur SSP Negotiate, elle analyse la demande et choisit le fournisseur approprié pour gérer la demande, en fonction des stratégies de sécurité configurées par client.
Le mécanisme SPNEGO est spécifié dans RFC 2478.
Dans les versions prises en charge des systèmes d’exploitation Windows, le fournisseur SSP Negotiate sélectionne entre le protocole Kerberos et NTLM. Negotiate sélectionne le protocole Kerberos par défaut, sauf si celui-ci ne peut pas être utilisé par l’un des systèmes impliqués dans l’authentification ou que l’application appelante n’a pas fourni des informations suffisantes pour utiliser le protocole Kerberos.
Location: %Windir%\System32\lsasrv.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.
Ressources supplémentaires pour le SSP Negotiate
[MS-SPNG] : extensions du mécanisme de négociation GSS-API simple et protégé (SPNEGO)
[MS-N2HT] : spécification du protocole d’authentification HTTP Negotiate et Nego2
Protocole CredSSP (Credential Security Support Provider)
Le fournisseur CredSSP (Credential Security Service Provider) fournit une expérience utilisateur d’authentification unique (SSO) lors du démarrage de nouvelles sessions des Services Terminal Server et des Services Bureau à distance. CredSSP permet aux applications de déléguer les informations d’identification des utilisateurs de l’ordinateur client (à l’aide du fournisseur SSP côté client) au serveur cible (via le fournisseur SSP côté serveur), en fonction des stratégies du client. Les stratégies CredSSP sont configurées à l’aide d’une stratégie de groupe, et la délégation des informations d’identification est désactivée par défaut.
Location: %Windir%\System32\credssp.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique.
Ressources supplémentaires pour le fournisseur SSP d’informations d’identification
Fournisseur SSP des extensions Negotiate
Negotiate Extensions (NegoExts) est un package d’authentification qui négocie l’utilisation des SSP, autres que NTLM ou le protocole Kerberos, pour les applications et les scénarios implémentés par Microsoft et d’autres éditeurs de logiciels.
Cette extension au package Negotiate favorise les scénarios suivants :
Disponibilité de clients riches au sein d’un système fédéré. Les documents sont accessibles sur des sites SharePoint et peuvent être modifiés à l’aide d’une application Microsoft Office complète.
Prise en charge des clients riches pour les services Microsoft Office. Les utilisateurs peuvent se connecter aux services Microsoft Office et utiliser une application Microsoft Office complète.
Microsoft Exchange Server et Outlook hébergés. Aucune approbation de domaine n’est établie, car Exchange Server est hébergé sur le web. Outlook utilise le service Windows Live pour authentifier les utilisateurs.
Disponibilité de clients riches entre les ordinateurs clients et les serveurs. Les composants de mise en réseau et d’authentification du système d’exploitation sont utilisés.
Le package Windows Negotiate traite le fournisseur SSP NegoExts de la même manière que Kerberos et NTLM. NegoExts.dll est chargé dans l’autorité système locale (LSA) au démarrage. Lorsqu’une demande d’authentification est reçue, NegoExts négocie entre les fournisseurs SSP pris en charge en fonction de la source de la demande. Il collecte les informations d’identification et les stratégies, les chiffre et envoie ces informations au fournisseur dSSP, où le jeton de sécurité est créé.
Les SSP pris en charge par NegoExts ne sont pas des SSP autonomes tels que Kerberos et NTLM. Par conséquent, dans le fournisseur SSP NegoExts, lorsque la méthode d’authentification échoue pour une raison quelconque, un message d’échec d’authentification s’affiche ou est journalisé. Aucune méthode d’authentification de renégociation ou de secours n’est possible.
Location: %Windir%\System32\negoexts.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, sauf en ce qui concerne Windows Server 2008 et Windows XP.
Fournisseur SSP (Security Support Provider) PKU2U
Le protocole PKU2U a été introduit et implémenté en tant que fournisseur SSP dans Windows 7 et Windows Server 2008 R2. Ce fournisseur SSP permet l’authentification de pair à pair, en particulier par le biais de la fonctionnalité de partage de fichiers et de médias appelée Groupement résidentiel, qui a été introduite dans Windows 7. Cette fonctionnalité permet les partages entre des ordinateurs qui ne sont pas membres d’un domaine.
Location: %Windir%\System32\pku2u.dll
Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique à au début de cette rubrique, sauf en ce qui concerne Windows Server 2008 et Windows XP.
Ressources supplémentaires pour le protocole PKU2U et le fournisseur SSP PKU2U
Sélection du fournisseur SSP (Security Support Provider)
La SSPI Windows peut utiliser n’importe quel protocole pris en charge par le biais des fournisseurs SSP installés. Toutefois, étant donné que tous les systèmes d’exploitation ne prennent pas en charge les mêmes packages SSP que n’importe quel ordinateur exécutant Windows Server, les clients et les serveurs doivent négocier pour utiliser un protocole pris en charge par les deux parties. Windows Server préfère que les ordinateurs clients et les applications utilisent le protocole Kerberos, un protocole fort basé sur des normes, lorsque cela est possible, mais le système d’exploitation continue d’autoriser l’authentification des ordinateurs clients et les applications clientes qui ne prennent pas en charge le protocole Kerberos.
Avant que l’authentification puisse avoir lieu, les deux ordinateurs qui communiquent doivent convenir d’un protocole qu’ils peuvent tous les deux prendre en charge. Pour que n’importe quel protocole soit utilisable via l’interface SSPI, chaque ordinateur doit disposer du fournisseur SSP approprié. Par exemple, pour qu’un ordinateur client et un serveur utilisent le protocole d’authentification Kerberos, ils doivent tous deux prendre en charge Kerberos v5. Windows Server utilise la fonction EnumerateSecurityPackages pour identifier les fournisseurs SSP pris en charge sur un ordinateur et leurs fonctionnalités.
La sélection d’un protocole d’authentification peut être gérée de l’une des deux manières suivantes :
Protocole d’authentification unique
Lorsqu’un seul protocole acceptable est spécifié sur le serveur, l’ordinateur client doit prendre en charge le protocole spécifié ou la communication échoue. Lorsqu’un seul protocole acceptable est spécifié, l’échange d’authentification s’effectue comme suit :
L’ordinateur client demande l’accès à un service.
Le serveur répond à la demande et spécifie le protocole qui sera utilisé.
L’ordinateur client examine le contenu de la réponse et vérifie s’il prend en charge le protocole spécifié. Si l’ordinateur client prend en charge le protocole spécifié, l’authentification continue. Si l’ordinateur client ne prend pas en charge le protocole, l’authentification échoue, que l’ordinateur client soit autorisé ou non à accéder à la ressource.
Option de négociation
L’option de négociation peut être utilisée pour permettre au client et au serveur de tenter de trouver un protocole acceptable. Elle est basée sur le mécanisme de négociation GSS-API simple et protégé (SPNEGO). Lorsque l’authentification commence par l’option de négociation d’un protocole d’authentification, l’échange SPNEGO s’effectue comme suit :
L’ordinateur client demande l’accès à un service.
Le serveur répond par une liste de protocoles d’authentification qu’il peut prendre en charge et un test d’authentification ou une réponse, en fonction du protocole qui constitue son premier choix. Par exemple, le serveur peut répertorier le protocole Kerberos et NTLM, et envoyer une réponse d’authentification Kerberos.
L’ordinateur client examine le contenu de la réponse et vérifie s’il prend en charge les protocoles spécifiés.
Si l’ordinateur client prend en charge le protocole préféré, l’authentification continue.
Si l’ordinateur client ne prend pas en charge le protocole préféré, mais qu’il prend en charge l’un des autres protocoles répertoriés par le serveur, l’ordinateur client indique au serveur quel protocole d’authentification il prend en charge et l’authentification continue.
Si l’ordinateur client ne prend en charge aucun des protocoles répertoriés, l’échange d’authentification échoue.
Références supplémentaires
Commentaires
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour