Prise en charge des noms de principaux de service (SPN) dans les connexions clientes dans SQL Server Native Client

Article
01/10/2024

S’applique à :SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Important

SQL Server Native Client (SNAC) n’est pas fourni avec :

2022 - SQL Server 16 (16.x) et versions ultérieures
SQL Server Management Studio 19 et versions ultérieures

SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) hérité ne sont pas recommandés pour le développement de nouvelles applications.

Pour les nouveaux projets, utilisez l'un des pilotes suivants :

Pour SQLNCLI qui est fourni en tant que composant du moteur de base de données SQL Server (versions 2012 à 2019), consultez cette exception du cycle de vie du support.

À partir de SQL Server 2008 (10.0.x), la prise en charge des noms de principal du service (SPN) a été étendue pour permettre une authentification mutuelle entre tous les protocoles. Dans les versions antérieures de SQL Server, les noms de principal du service étaient pris en charge uniquement pour Kerberos sur TCP quand le nom de principal du service par défaut de l’instance de SQL Server était inscrit auprès d’Active Directory.

Les noms de principal du service sont utilisés par le protocole d’authentification pour déterminer le compte dans lequel s’exécute une instance de SQL Server. Si le compte de l'instance est connu, l'authentification Kerberos peut être utilisée pour fournir une authentification mutuelle par le client et le serveur. Si le compte de l'instance n'est pas connu, l'authentification NTLM, qui fournit uniquement une authentification du client par le serveur, est utilisée. Actuellement, SQL Server Native Client effectue la recherche d’authentification, dérivant le SPN à partir du nom de l’instance et des propriétés de connexion réseau. Les instances de SQL Server tentent d’inscrire les noms de principal du service au démarrage, mais ces derniers peuvent également être inscrits manuellement. Toutefois, l'inscription échoue si les droits d'accès sont insuffisants pour le compte qui essaie d'inscrire les noms principaux de service.

Les comptes de domaine et d'ordinateur sont inscrits automatiquement dans Active Directory. Ceux-ci peuvent être utilisés en tant que SPN, ou les administrateurs peuvent définir leurs propres SPN. SQL Server rend l’authentification sécurisée plus gérable et plus fiable en autorisant les clients à spécifier directement le nom de principal du service à utiliser.

Notes

Un nom principal de service spécifié par une application cliente est utilisé uniquement lorsqu'une connexion est établie avec la sécurité intégrée Windows.

Conseil

Microsoft pour SQL Server est un outil de diagnostic qui permet de dépanner les problèmes de connexion que rencontre Kerberos avec SQL Server. Pour plus d'informations, consultez Gestionnaire de configuration de Microsoft Kerberos pour SQL Server.

Pour plus d'informations sur Kerberos, consultez les articles suivants :

Utilisation

Le tableau suivant décrit les scénarios les plus courants dans lesquels les applications clientes peuvent activer l'authentification sécurisée.

Scénario	Description
Une application héritée ne spécifie pas de nom principal de service.	Ce scénario de compatibilité garantit l'absence de tout changement de comportement dans les applications développées pour les versions antérieures de SQL Server. Si aucun nom principal de service n'est spécifié, l'application s'appuie sur les noms principaux de service générés et n'a aucune connaissance de la méthode d'authentification utilisée.
Une application cliente utilisant la version actuelle de SQL Server Native Client spécifie un SPN dans le chaîne de connexion en tant que compte d’utilisateur ou d’ordinateur de domaine, en tant que SPN spécifique à l’instance ou en tant que chaîne définie par l’utilisateur.	Le mot clé ServerSPN peut être utilisé dans une chaîne de fournisseur, une chaîne d'initialisation ou une chaîne de connexion afin d'effectuer les opérations suivantes : -Spécifiez le compte utilisé par l’instance de SQL Server pour une connexion. Cela simplifie l'accès à l'authentification Kerberos. Si un centre de distribution de clés Kerberos (KDC) est présent et si le compte approprié est spécifié, l'utilisation de l'authentification Kerberos est plus probable que celle de l'authentification NTLM. Le centre de distribution de clés se trouve habituellement sur le même ordinateur que le contrôleur de domaine. -Spécifiez un nom de principal du service pour rechercher le compte de service de l’instance de SQL Server. Pour chaque instance de SQL Server, deux noms de principal du service par défaut sont générés et peuvent être utilisés à cette fin. Toutefois, il n'est pas certain que ces clés soient présentes dans Active Directory ; par conséquent, dans cette situation, l'authentification Kerberos n'est pas garantie. -Spécifiez un nom de principal du service à utiliser pour rechercher le compte de service de l’instance de SQL Server. Il peut s'agir de n'importe quelle chaîne définie par l'utilisateur et mappée au compte de service. Dans ce cas, la clé doit être inscrite manuellement dans le centre de distribution de clés et doit répondre aux exigences relatives à un nom principal de service défini par l'utilisateur. Le mot clé FailoverPartnerSPN peut être utilisé pour spécifier le nom principal de service du serveur partenaire de basculement. La plage des valeurs de comptes et de clés Active Directory est identique à celle des valeurs que vous pouvez spécifier pour le serveur principal.
Une application ODBC spécifie un nom principal de service en tant qu'attribut de connexion pour le serveur principal ou le partenaire de basculement.	L'attribut de connexion SQL_COPT_SS_SERVER_SPN peut être utilisé pour spécifier le nom principal de service d'une connexion au serveur principal. L'attribut de connexion SQL_COPT_SS_FAILOVER_PARTNER_SPN peut être utilisé pour spécifier le nom principal de service du serveur partenaire de basculement.
Une application OLE DB spécifie un nom principal de service en tant que propriété d'initialisation d'une source de données pour le serveur principal ou pour un partenaire de basculement.	La propriété de connexion SSPROP_INIT_SERVER_SPN du jeu de propriétés DBPROPSET_SQLSERVERDBINIT peut être utilisée pour spécifier le nom principal de service d'une connexion. La propriété de connexion SSPROP_INIT_FAILOVER_PARTNER_SPN dans DBPROPSET_SQLSERVERDBINIT peut être utilisée pour spécifier le nom principal de service du serveur partenaire de basculement.
Un utilisateur spécifie un nom principal de service pour un serveur ou un partenaire de basculement dans un nom de source de données ODBC.	Le nom principal de service peut être spécifié dans un nom de source de données ODBC via les boîtes de dialogue d'installation du nom de la source de données.
L'utilisateur spécifie un nom principal de service pour un serveur ou un serveur partenaire de basculement dans une boîte de dialogue Liaison de données ou Connexion OLE DB.	Le nom principal de service peut être spécifié dans une boîte de dialogue Liaison de données ou Connexion . La boîte de dialogue Connexion peut être utilisée avec ODBC ou OLE DB.
Une application ODBC détermine la méthode d'authentification utilisée pour établir une connexion.	Lorsqu'une connexion est ouverte avec succès, une application peut interroger l'attribut de connexion SQL_COPT_SS_INTEGRATED_AUTHENTICATION_METHOD pour déterminer la méthode d'authentification utilisée. Les valeurs incluent NTLM et Kerberosmais ne se limitent pas à ces dernières.
Une application OLE DB détermine la méthode d'authentification utilisée pour établir une connexion.	Lorsqu'une connexion est ouverte avec succès, une application peut interroger la propriété de connexion SSPROP_AUTHENTICATION_METHOD dans le jeu de propriétés DBPROPSET_SQLSERVERDATASOURCEINFO pour déterminer la méthode d'authentification utilisée. Les valeurs incluent NTLM et Kerberosmais ne se limitent pas à ces dernières.

Basculement

Les noms principaux de service ne sont pas stockés dans le cache de basculement et par conséquent ne peuvent pas être passés entre les connexions. Les noms principaux de service sont utilisés lors de toutes les tentatives de connexion au principal et au serveur partenaire lorsque cela est spécifié dans la chaîne de connexion ou les attributs de connexion.

Regroupement de connexions

Les applications doivent prendre en compte le fait que la spécification de noms principaux de service dans une partie (au lieu de la totalité) des chaînes de connexion peut contribuer à la fragmentation du regroupement.

Les applications peuvent spécifier par programme des noms principaux de service en tant qu'attributs de connexion, au lieu de spécifier des mots clés de chaînes de connexion. Cela peut permettre de gérer la fragmentation du regroupement de connexions.

Les applications doivent prendre en compte le fait que les noms principaux de service dans les chaînes de connexion peuvent être substitués en définissant les attributs de connexion correspondants ; toutefois, les chaînes de connexion utilisées par le regroupement de connexions tirent parti des valeurs de chaînes de connexion à des fins de regroupement.

Comportement de serveur de bas niveau

Le nouveau comportement de connexion est implémenté par le client ; par conséquent, il n’est pas spécifique à une version de SQL Server.

Serveurs liés et délégation

Lorsque des serveurs liés sont créés, le paramètre @provstr de sp_addlinkedserver peut être utilisé pour spécifier les noms principaux de service du serveur et du serveur partenaire de basculement. Les avantages de ce choix sont les mêmes que pour la spécification de noms principaux de service dans les chaînes de connexion des clients : davantage de simplicité et de fiabilité pour l'établissement des connexions qui utilisent l'authentification Kerberos.

La délégation avec des serveurs liés requiert l'authentification Kerberos.

Aspects liés à la gestion des noms principaux de service spécifiés par les applications

Lorsque vous choisissez de spécifier des SPN dans une application (via des chaînes de connexion) ou par programme via des propriétés de connexion (plutôt que de compter sur les SPN générés par le fournisseur par défaut), tenez compte des facteurs suivants :

Sécurité : est-ce que le nom principal de service spécifié divulgue des informations protégées ?
Fiabilité : pour permettre l’utilisation des noms de principal du service par défaut, le compte de service dans lequel s’exécute l’instance de SQL Server doit avoir les privilèges suffisants pour mettre à jour Active Directory sur le centre de distribution de clés.
Commodité et transparence de l'emplacement : comment les noms principaux de service d'une application sont-ils affectés si la base de données correspondante est déplacée vers une autre instance de SQL Server ? Cela s'applique à la fois au serveur principal et à son partenaire de basculement, si vous utilisez la mise en miroir de bases de données. Si une modification du serveur signifie une modification des noms principaux de service, comment cela affecte-t-il les applications ? Est-ce que les modifications sont gérées ?

Spécification du nom principal de service

Vous pouvez spécifier un nom principal de service dans les boîtes de dialogue et dans le code. Cette section explique comment vous pouvez spécifier un nom principal de service.

La longueur maximale d'un nom principal de service est 260 caractères.

La syntaxe que les noms principaux de service utilisent dans la chaîne de connexion ou les attributs de connexion est la suivante :

Syntaxe	Description
MSSQLSvc/fqdn	Nom principal de service par défaut, généré par le fournisseur, pour une instance par défaut lorsqu'un autre protocole que TCP est utilisé. fqdn est un nom de domaine complet.
MSSQLSvc/fqdn:port	Nom principal de service par défaut, généré par le fournisseur, lorsque le protocole TCP est utilisé. port est un numéro de port TCP.
MSSQLSvc/fqdn:InstanceName	Nom principal de service par défaut, généré par le fournisseur, pour une instance nommée lorsqu'un autre protocole que TCP est utilisé. InstanceName est le nom d’une instance de SQL Server.
HOST/fqdn HOST/MachineName	Nom principal de service mappé aux comptes d'ordinateur intégrés qui sont inscrits automatiquement par Windows.
Username@Domain	Spécification directe d'un compte de domaine. Username est un nom de compte d'utilisateur Windows. Domain est un nom de domaine ou nom de domaine complet Windows.
MachineName$@Domain	Spécification directe d'un compte d'ordinateur. (Si le serveur auquel vous vous connectez s'exécute sous les comptes LOCAL SYSTEM ou NETWORK SERVICE, pour obtenir l'authentification Kerberos, ServerSPN peut être au format MachineName$@Domain .)
KDCKey/MachineName	Nom principal de service spécifié par l'utilisateur. KDCKey est une chaîne alphanumérique conforme aux règles d'une clé du centre de distribution de clés.

Syntaxe ODBC et OLE DB prenant en charge les noms principaux de service

Pour plus d'informations spécifiques à la syntaxe, consultez les rubriques suivantes :

Voir aussi

Fonctionnalités de SQL Server Native Client
Inscrire un nom de principal du service pour les connexions Kerberos

Partager via