Enregistrer un nom de principal du service pour les connexions Kerberos

S’applique à : SQL Server

Pour utiliser l'authentification Kerberos avec SQL Server, les deux conditions suivantes doivent être remplies :

• Les ordinateurs clients et serveurs doivent faire partie du même domaine Windows ou appartenir à des domaines approuvés.

• Un nom de principal du service (SPN, Service Principal Name) doit être inscrit dans Active Directory, qui joue le rôle de centre de distribution de clés dans un domaine Windows. Une fois inscrit, le SPN est mappé au compte Windows qui a démarré le service de l'instance de SQL Server. Si l'inscription du SPN n'a pas été effectuée ou échoue, la couche de sécurité Windows ne peut pas déterminer le compte associé au SPN et l'authentification Kerberos n’est pas utilisée.

  Notes

  Si le serveur ne parvient pas à inscrire automatiquement le SPN, celui-ci doit être inscrit manuellement. Consultez Inscription manuelle des SPN.

Vous pouvez vérifier qu'une connexion utilise Kerberos en interrogeant la vue de gestion dynamique sys.dm_exec_connections. Exécutez la requête suivante et vérifiez la valeur de la colonne auth_scheme, qui est KERBEROS si Kerberos est activé.

SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Rôle du SPN dans l'authentification

Lorsqu'une application ouvre une connexion et utilise l'authentification Windows, SQL Server Native Client transmet le nom de l'ordinateur SQL Server , le nom de l'instance et, éventuellement, un SPN. Si la connexion transmet un SPN, il est utilisé sans aucune modification.

Si la connexion ne transmet pas de SPN, un SPN par défaut est construit à partir du protocole utilisé, du nom de serveur et du nom de l'instance.

Dans les deux scénarios précédents, le SPN est envoyé au centre de distribution de clés pour obtenir un jeton de sécurité en vue d'authentifier la connexion. Si un jeton de sécurité ne peut pas être obtenu, l'authentification utilise le protocole NTLM.

Un SPN est le nom par lequel un client identifie de manière unique une instance d'un service. Le service d'authentification Kerberos peut utiliser le nom principal d'un service pour authentifier un service. Pour se connecter à un service, le client localise une instance du service, compose le nom principal du service pour cette instance, se connecte au service et présente le nom principal de service pour que le service s'authentifie.

L'Authentification Windows est la méthode recommandée pour authentifier les utilisateurs sur SQL Server. Les clients qui utilisent l'Authentification Windows sont authentifiés à l'aide de NTLM ou Kerberos. Dans un environnement Active Directory, l'authentification Kerberos est toujours tentée en premier.

autorisations

Lorsque le service Database Engine démarre, il tente d'enregistrer le nom de principal du service (SPN). Supposons que le compte démarrant SQL Server ne dispose pas de l’autorisation d’inscrire un nom SPN dans Active Directory Domain Services. Dans ce cas, cet appel échoue et un message d'avertissement est enregistré dans le journal des événements de l'application, ainsi que dans le journal des erreurs de serveur SQL.

Pour enregistrer le SPN, le moteur de base de données doit s'exécuter sous un compte intégré comme Local System (non recommandé) ou NETWORK SERVICE, ou sous un compte qui a l'autorisation d'enregistrer un SPN. Vous pouvez enregistrer un SPN à l'aide d'un compte d'administrateur de domaine, mais cela n'est pas recommandé dans un environnement de production. Vous pouvez exécuter SQL Server à l'aide d'un compte virtuel ou d'un compte de service administré (MSA). Les comptes virtuels et les comptes de service administré peuvent enregistrer un SPN. Si SQL Server ne s’exécute pas sous l’un de ces comptes, le SPN n’est pas inscrit lors du démarrage et l’administrateur de domaine doit l’inscrire manuellement.

Formats des SPN

Le format des SPN prend en charge l'authentification Kerberos sur le protocole TCP/IP, les canaux nommés et la mémoire partagée. Les formats de SPN pris en charge pour les instances nommées et par défaut sont les suivants.

Instance nommée

• MSSQLSvc/<FQDN>:[<port> | <nom_instance>], où :

  • MSSQLSvc est le service en cours d'inscription.
  • <FQDN> est le nom de domaine complet du serveur.
  • <port> est le numéro de port TCP.
  • <instancename> représente le nom de l'instance SQL Server.

Instance par défaut

• MSSQLSvc/<FQDN>:<port> | MSSQLSvc/<FQDN>, où :

  • MSSQLSvc est le service en cours d'inscription.
  • <FQDN> est le nom de domaine complet du serveur.
  • <port> est le numéro de port TCP.

¹ Le format SPN ne requiert pas de numéro de port. Un serveur à port multiple ou un protocole qui n'utilise pas de numéro de port peut toujours utiliser l'authentification Kerberos.

Pour une connexion TCP/IP, où le port TCP est inclus dans le SPN, SQL Server doit activer le protocole TCP afin de permettre à un utilisateur de se connecter à l'aide de l'authentification Kerberos.

Inscription automatique des SPN

Lors du démarrage d’une instance Moteur de base de données SQL Server, SQL Server tente d’inscrire le nom SPN du service SQL Server. Lors de l’arrêt de l’instance, SQL Server tente d’annuler l’inscription du nom SPN. Pour une connexion TCP/IP, le SPN est inscrit au format MSSQLSvc/<FQDN>:<tcpport>. Les instances nommées et l'instance par défaut sont inscrites en tant que MSSQLSvc, en s'appuyant sur la valeur <tcpport> pour différencier les instances.

Pour les autres connexions qui prennent en charge Kerberos, le SPN est inscrit au format MSSQLSvc/<FQDN>:<instancename> pour une instance nommée. Le format MSSQLSvc/<FQDN> est utilisé pour l'inscription de l'instance par défaut.

Pour accorder des autorisations au compte de démarrage SQL Server afin d'enregistrer et modifier le SPN, procédez comme suit :

1. Sur la machine du contrôleur de domaine, accédez à Utilisateurs et ordinateurs Active Directory.

2. Sélectionnez Affichage > Avancé.

3. Sous Ordinateurs, recherchez l’ordinateur SQL Server, puis cliquez avec le bouton droit et sélectionnez Propriétés.

4. Sélectionnez l'onglet Sécurité et sélectionnez Avancé.

5. Dans la liste, si le compte de démarrage SQL Server n'est pas répertorié, sélectionnez Ajouter pour l'ajouter. Une fois ajouté, procédez comme suit :

   1. Sélectionnez le compte, puis sélectionnez Modifier.

   2. Sous Autorisations, sélectionnez Validated Write servicePrincipalName.

   3. Faites défiler vers le bas et sous Propriétés, sélectionnez :

      • Read servicePrincipalName
      • Write servicePrincipalName

   4. Sélectionnez OK deux fois.

6. Fermez Utilisateurs et ordinateurs Active Directory.

Une intervention manuelle peut être requise pour inscrire ou annuler l'inscription du SPN si le compte de service ne possède pas les autorisations requises pour ces actions.

Inscription manuelle des SPN

Pour enregistrer le SPN manuellement, vous pouvez utiliser l'outil setspn intégré à Windows. setspn.exe est un outil en ligne de commande qui vous permet de lire, modifier et supprimer la propriété du répertoire des Noms de principaux du service (SPN). Cet outil vous permet également d'afficher les SPN actuels, de réinitialiser les SPN par défaut du compte et d'ajouter ou de supprimer des SPN supplémentaires.

Pour plus d'informations sur l'outil setspn, les autorisations requises et des exemples d'utilisation, reportez-vous à setspn.

L’exemple suivant illustre la syntaxe utilisée pour inscrire manuellement un SPN pour une connexion TCP/IP à l’aide d’un compte d’utilisateur de domaine :

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:1433 redmond\accountname

setspn -S MSSQLSvc/myhost.redmond.microsoft.com redmond\accountname

Pour une instance nommée, utilisez :

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename redmond\accountname

Pour plus d’informations sur les configurations de groupes de disponibilité Always On, consultez Écouteurs et Kerberos (SPN).

Connexions clientes

Les SPN spécifiés par l'utilisateur sont pris en charge dans les pilotes clients. Toutefois, si aucun SPN n'est fourni, il est généré automatiquement en fonction du type de connexion cliente. Pour une connexion TCP, un nom SPN au format MSSQLSvc/FQDN:[<port>] est utilisé à la fois pour les instances nommées et par défaut.

Pour les connexions par canaux nommés et mémoire partagée, un SPN au format MSSQLSvc/<FQDN>:<instancename> est utilisé pour une instance nommée et MSSQLSvc/<FQDN> est utilisé pour l'instance par défaut.

Utiliser un compte de service comme SPN

Les comptes de service peuvent être utilisés comme SPN. Ils sont spécifiés par le biais de l'attribut de connexion pour l'authentification Kerberos et assument les formats suivants :

• username\@domain ou domain\username pour un compte d'utilisateur de domaine

• machine$\@domain ou host\FQDN pour un compte de domaine d'ordinateur comme Local System ou NETWORK SERVICE.

Pour déterminer la méthode d'authentification d'une connexion, exécutez la requête suivante.

SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Paramètres par défaut de l'authentification

Le tableau suivant décrit les paramètres d'authentification par défaut utilisés selon les scénarios d'inscription de SPN.

Notes

La connexion administrateur dédiée utilise un SPN basé sur un nom d'instance. L'authentification Kerberos peut être utilisée avec une connexion DAC si l'inscription de ce SPN réussit. En guise d'alternative, un utilisateur peut spécifier le nom du compte comme SPN.

Si l’inscription du nom SPN échoue au démarrage, cet échec est consigné dans le journal des erreurs de SQL Server et le démarrage se poursuit.

Si l'annulation de l'inscription du SPN échoue pendant l'arrêt, cet échec est consigné dans le journal des erreurs de serveur SQL et l'arrêt se poursuit.

Contenu connexe

• Prise en charge des noms de principaux de service (SPN) dans les connexions clientes dans SQL Server Native Client
• Noms de principaux du service (SPN) dans les connexions clientes (OLE DB)
• Noms de principaux du service (SPN) dans les connexions clientes (ODBC)
• Fonctionnalités de SQL Server Native Client
• Gérer les problèmes d’authentification Kerberos dans un environnement Reporting Services