Inscription de noms de principaux du service Kerberos à l'aide de Http.sys
Les services Web XML natifs sont déconseillés. 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é.
Lorsque vous créez ou modifiez des points de terminaison HTTP à l'aide de l'instruction CREATE ENDPOINT ou ALTER ENDPOINT, vous spécifiez le type d'authentification utilisé pour authentifier les utilisateurs qui envoient une demande SOAP HTTP au point de terminaison. Pour plus d'informations, consultez CREATE ENDPOINT (Transact-SQL) et ALTER ENDPOINT (Transact-SQL).
En utilisant CREATE ENDPOINT ou ALTER ENDPOINT, vous pouvez faire en sorte que les points de configuration prennent en charge l'authentification Kerberos. Pour ce faire, vous devez procéder de l'une des deux façons suivantes :
Avec AUTHENTICATION=KERBEROS, Kerberos devient le seul mode d'authentification HTTP.
Lorsque AUTHENTICATION=INTEGRATED, l'authentification HTTP associée au point de terminaison peut offrir les options suivantes dans le cadre de la demande d'authentification : NEGOTIATE, KERBEROS et NTLM. Dans le cas de l'option NEGOTIATE, le client et le serveur essaient d'établir une authentification Kerberos. Si Kerberos n'est pas pris en charge par le client ou si la négociation est impossible, l'authentification repasse en NTLM. Pour éviter que le client ne repasse en NTLM lorsque vous utilisez NEGOTIATE, il est recommandé de spécifier sur le client AUTHENTICATION=KERBEROS pour le point de terminaison.
Pour prendre en charge l'authentification mutuelle sous Kerberos, il est nécessaire qu'une instance de SQL Server associe un nom de principal du service (SPN) au compte sous lequel elle s'exécutera, par exemple, un compte système local ou un compte d'utilisateur de domaine. Les détails spécifiques relatifs à une inscription de nom SPN par l'instance déterminée de SQL Server dépendent du type de compte de service sous lequel elle a été configurée. Si SQL Server s'exécute sous le compte système local ou le compte de service réseau, les noms SPN doivent être inscrits sous le nom de l'ordinateur. Si SQL Server s'exécute sous un compte d'utilisateur de domaine, les noms SPN doivent être inscrits sous le nom de l'utilisateur du domaine.
Utilisation de SetSPN.exe
Pour permettre l'association d'un nom SPN au compte sous lequel s'exécute l'instance de SQL Server, utilisez l'outil de support de Windows, SetSPN.exe. Cet outil ajoute le nom SPN pour le nom de l'ordinateur sur lequel l'instance de SQL Server s'exécute sous le compte d'utilisateur du service de domaine Windows situé dans Active Directory. Dans ce scénario, l'outil SetSPN.exe peut être utilisé pour ajouter deux SPN : un pour le nom NetBIOS et un autre pour le nom DNS complet.
Par exemple, si l'outil SetSPN.exe est exécuté à partir de l'instance de SQL Server qui s'exécute sur MyComputer, les deux noms SPN sont associés au compte sous lequel l'instance de SQL Server s'exécute et doivent être ajoutés à l'annuaire :
HTTP/MyComputer;
HTTP/MyComputer.fully.qualified.domain.name.com
Notez qu'un compte unique peut avoir plusieurs noms SPN, mais qu'un nom SPN ne peut être inscrit que pour un seul compte.
Pour supprimer ces deux noms SPN identiques, à la fois le nom NetBIOS et le nom DNS complet, utilisez également l'outil SetSPN.exe.
Observations
À l'instar de Httpcfg.exe, SetSPN.exe est fourni avec Windows Server 2003 et s'installe lorsque vous utilisez la procédure d'installation de Httpcfg.exe et des autres outils de support de Windows. Pour plus d'informations, consultez Configuration du pilote en mode noyau HTTP (Http.sys).
Si une instance de SQL Server ne s'exécute pas sous le compte système local, seuls les utilisateurs de l'authentification intégrée disposant de privilèges DOMAIN ADMIN peuvent modifier l'inscription d'un SPN avec l'outil SetSPN.exe.
Si une instance de SQL Server s'exécute sous le compte système local, seuls les membres du rôle serveur fixe sysadmin de SQL Server peuvent modifier l'inscription d'un nom SPN avec l'outil SetSPN.exe.
Si le compte de service est Système local, le nom SPN est ajouté au compte Active Directory de l'ordinateur sans qu'il soit nécessaire d'utiliser l'outil SetSPN.exe.
Syntaxe pour SetSPN.exe
La syntaxe à utiliser pour SetSPN est la suivante :
setspn { -ASPN | -DSPN | -L } service_account
Arguments
-A
Ajoute le nom SPN spécifié au compte.-D
Supprime le nom SPN spécifié du compte.-L
Affiche la liste de tous les noms SPN inscrits dans le compte.
Exemples
Si une instance de SQL Server s'exécute en tant qu'utilisateur de domaine (MyDomain\MySQLAccount) sur un ordinateur nommé MySQLHost, les commandes suivantes peuvent être utilisées pour définir les noms SPN appropriés :
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySqlHost.Mydomain.Mycorp.com MyDomain\MySQLAccount
Notez qu'un compte unique peut avoir plusieurs noms SPN (un pour chaque service ou nom d'hôte), mais qu'un nom SPN peut être inscrit sous un seul compte. L'inscription d'un même nom SPN sur plusieurs comptes fait échouer l'authentification Kerberos.
Par exemple, il serait tout à fait envisageable d'inscrire dans le compte MyDomain\MySQLAccount les différents noms SPN indiqués ci-dessous. Les deux premières commandes concernent les deux services distincts (http et rpc). La dernière est destinée à un nom d'hôte différent, à supposer que l'ordinateur dispose de plusieurs noms d'hôte.
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A rpc/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySecondHost MyDomain\MySQLAccount
À l'inverse, le scénario suivant entraînera inévitablement un échec de Kerberos :
setspn –A http/MySQLHost MyDomain\MySQLAccountOne
setspn –A http/MySQLHost MyDomain\MySQLAccountTwo
Cet échec se produit car il existe deux instances de SQL Server sur un ordinateur qui s'exécute sous deux comptes de service différents (MySQLAccountOne et MySQLAccountTwo). L'inscription de deux noms SPN, un pour chaque instance de SQL Server, n'est pas un scénario pris en charge.
Cela a des incidences lorsque plusieurs instances de SQL Server sont exécutées sur le même ordinateur sous des comptes différents. Le nom SPN ne peut être inscrit que pour un seul compte. Si vous tenez à ce que plusieurs instances de SQL Server (par exemple, Inst1 et Inst2) coexistent aux côtés d'autres applications (telles que IIS) et si vous voulez utiliser l'authentification Kerberos HTTP pour tous les services, optez pour l'une des options suivantes pour résoudre les conflits d'inscription de noms SPN :
Faites en sorte que toutes les instances et applications s'exécutent sous le même compte.
Par exemple, Inst1, Inst2 et IIS doivent tous s'exécuter sous le compte LocalSystem ou Mydomain\MyServiceAccount.
Inscrivez plusieurs noms d'hôte pour le même ordinateur et faites en sorte que chaque instance et application soient à l'écoute d'un hôte différent. Ainsi, en pareil cas, voici les opérations que vous devriez effectuer :
Créer trois noms d'hôte différents pour l'ordinateur.
Affecter chaque hôte à une application différente.
Inscrire trois ensembles de noms SPN, un pour chaque combinaison nom d'hôte/application.
Résolution des problèmes liés à l'inscription de noms SPN Kerberos
Les problèmes les plus fréquents en matière d'inscription de noms SPN Kerberos sont les suivants :
Nom SPN non inscrit.
Lorsqu'un nom SPN n'est pas inscrit, l'authentification Kerberos fonctionne sur l'ordinateur local sur lequel s'exécute l'instance de SQL Server, mais elle échoue sur les ordinateurs clients distants.
Nom SPN inscrit plusieurs fois.
Il est des scénarios où un administrateur peut dupliquer les noms principaux de service (SPN) dans l'annuaire du domaine, ce qui entraîne l'échec de l'authentification Kerberos. Ces scénarios en question sont les suivants :
Le compte de domaine sous lequel s'exécute l'instance de SQL Server est modifié
Si SetSpn.exe est exécuté alors qu'une instance de SQL Server s'exécute sous un compte de domaine, tel que DOMAIN\User1, et que le compte de domaine sous lequel s'exécute SQL Server est modifié (p.ex., DOMAIN\User2), lorsque SetSPN.exe est de nouveau exécuté, le même nom SPN est inséré dans l'annuaire sous les deux comptes.
Plusieurs instances de SQL Server exécutées sous des comptes différents sont installées
Si vous installez plusieurs instances de SQL Server et que vous exécutez chacune d'elles sous un compte différent, si SetSpn.exe est exécuté sur chaque instance, l'annuaire présentera des comptes en double sous chaque compte de service SQL Server. Ceci s'applique aux instances qui s'exécutent à la fois sous un compte d'utilisateur de domaine mais également sous le compte Système local.
Une instance de SQL Server est supprimée et réinstallée sous un compte différent
Si vous installez SQL Server sous un compte, inscrivez les noms SPN, supprimez et réinstallez SQL Server sous un compte différent, puis que vous réinscrivez les noms SPN, chaque compte de domaine présentera les mêmes noms SPN. Autrement dit, les noms SPN seront dupliqués.
Dans chacun de ces scénarios, le problème réside dans le fait que le point de terminaison repassera à l'authentification NTLM tant que le problème n'aura pas été résolu. Cela implique généralement de rechercher les noms SPN en double ou caduques dans l'annuaire, puis de les supprimer manuellement.