Types d'authentification du point de terminaison

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.

La procédure d'authentification du point de terminaison implique l'octroi d'autorisations permettant aux utilisateurs de se connecter aux points de terminaison créés sur le serveur et la spécification du mode d'authentification.

Le mode d'authentification est spécifié à l'aide de la clause AUTHENTICATION de l'instruction CREATE ENDPOINT ou ALTER ENDPOINT. La clause AUTHENTICATION propose les options suivantes pour spécifier le type d'authentification :

  • BASIC

  • DIGEST

  • NTLM

  • KERBEROS

  • INTEGRATED

Notes

L'authentification anonyme sur un point de terminaison n'est pas prise en charge. Pour accéder à un point de terminaison, l'utilisateur doit être un utilisateur Windows authentifié valide (soit un utilisateur Windows approuvé, soit un compte de membre sur l'ordinateur local).

Authentification de base

L'authentification de base est l'un des deux mécanismes d'authentification requis dans la spécification HTTP 1.1. L'authentification de base est constituée de l'en-tête Authentication qui contient le nom d'utilisateur et le mot de passe encodés en base 64 et séparés par un point-virgule. Pour plus d'informations, visitez la page http://www.ietf.org/rfc/rfc2617.txt (en anglais).

Tenez compte des remarques suivantes lorsque vous spécifiez BASIC :

  • La valeur PORTS ne peut pas être définie à CLEAR.

  • Les informations d'identification envoyées en tant qu'authentification HTTP de base doivent correspondre à une connexion Windows valide.

L'authentification de base ne doit être envisagée qu'en dernier recours. Comme l'authentification de base utilise l'encodage en base 64 facile à décoder, si vous la spécifiez, l'instance de SQL Server exige l'utilisation du port SSL (Secure Sockets Layer) pour la connexion HTTP. L'authentification de base peut être employée si l'utilisateur auquel sont accordées les autorisations jusqu'au point de terminaison est un utilisateur local situé sur l'ordinateur serveur proprement dit.

Authentification Digest

Digest est le deuxième mécanisme d'authentification requis par HTTP 1.1. Cette authentification est constituée du nom d'utilisateur et du mot de passe. Ceux-ci sont ensuite hachés à l'aide de MD5 (algorithme de hachage unidirectionnel) et envoyés au serveur. Le serveur a accès au mot de passe brut ou à un hachage MD5 stocké qui a été créé lors de la définition du mot de passe. Le serveur peut ensuite comparer la valeur calculée stockée à celle fournie par le client. De cette manière, le client peut prouver qu'il connaît le mot de passe sans réellement le fournir au serveur. Pour plus d'informations, visitez la page http://www.ietf.org/rfc/rfc2617.txt (en anglais).

Les informations d'identification envoyées en tant qu'éléments d'une authentification Digest sur HTTP doivent correspondre à un compte de domaine Windows valide. Les comptes d'utilisateurs locaux ne sont pas pris en charge par l'authentification Digest Windows.

Notes

Pour des raisons de sécurité, l'authentification Digest Windows ne prend en charge que le chiffrement MD5-sess sur des contrôleurs de domaine qui s'exécutent sous Windows Server 2003.

Authentification NTLM

NTLM est le mécanisme d'authentification pris en charge par Windows 95, Windows 98 et Windows NT 4.0 (client et serveur). Ce mécanisme d'authentification est un protocole de stimulation/réponse offrant une authentification plus poussée que les authentifications de base ou Digest. NTLM est implémenté dans Windows 2000 et les versions ultérieures par une interface SSPI (Security Support Provider Interface). Pour plus d'informations, consultez Microsoft NTLM.

Authentification Kerberos

L'authentification Kerberos est un mécanisme d'authentification Internet standard. Ce mécanisme est pris en charge dans Windows 2000 et les versions ultérieures par une interface SSPI.

Lorsque l'authentification Kerberos est utilisée, l'instance de SQL Server doit associer un nom de principal du service (SPN, Service Principal Name) au compte sous lequel elle s'exécutera. Pour plus d'informations, consultez Inscription de noms de principaux du service Kerberos à l'aide de Http.sys.

Pour plus d'informations sur l'authentification Kerberos, consultez Microsoft Kerberos.

Authentification intégrée

Les points de terminaison configurés pour prendre en charge l'authentification intégrée peuvent répondre par l'un des types d'authentification suivants dans le cadre de la stimulation d'authentification : Kerberos ou NTLM.

Dans cette configuration, le serveur tente d'authentifier le client avec tout type utilisé par le client lors de la demande d'authentification.

Notes

Si cette procédure échoue pour un type d'authentification intégré, le serveur met fin à la connexion du client. Il ne revient pas en arrière pour tenter l'autre type d'authentification.