Procédure : activer l'authentification Kerberos sur un cluster SQL Server avec basculement

  • Article

Mis à jour : 15 septembre 2007

Kerberos est un protocole d'authentification de réseau conçu pour fournir une authentification renforcée pour applications client/serveur. Kerberos fournit une base d'interopérabilité tout en améliorant la sécurité de l'authentification réseau à l'échelle de l'entreprise.

Vous pouvez utiliser l'authentification Kerberos avec des instances autonomes de Microsoft SQL Server 2005 ou avec des instances du cluster avec basculement s'exécutant sur Microsoft Windows 2000 Service Pack 3 (SP3). SQL Server 2005 prend en charge cette fonctionnalité en tant que partie intégrante d'une installation classique de domaine Active Directory Microsoft Windows 2000.

Lorsque la ressource de nom de réseau dont dépend SQL Server se trouve sur un cluster Windows 2000, vous pouvez utiliser l'authentification Kerberos sur la ressource après la mise à niveau de l'ordinateur vers Windows 2000 SP3. Pour plus d'informations sur l'activation de Kerberos sur des clusters de serveurs, consultez l'article de la Base de connaissances « Prise en charge de Kerberos sur les clusters de serveurs Windows 2000 ».

La section suivante décrit la connexion à un serveur exécutant Microsoft Internet Information Services (IIS) pour établir une connexion Kerberos à un serveur exécutant SQL Server.

Configuration requise

Vous ne pouvez utiliser cette fonctionnalité que si vous exécutez Windows 2000 SP3.

Avant d'effectuer la procédure d'installation, téléchargez les utilitaires Kerbtray et SetSPN.

  • Pour télécharger l'utilitaire Kerbtray, visitez le site Web suivant de Microsoft. Kerbtray.exe permet de vérifier et/ou de supprimer des tickets Kerberos sur tout ordinateur associé actuellement utilisé.
  • Pour télécharger l'utilitaire SetSPN, visitez le site Web de Microsoft.

SQL Server n'utilise Kerberos que si le client utilise le protocole TCP/IP pour se connecter à SQL Server. Si, par exemple, un client utilise le protocole Canaux nommés, Kerberos n'est pas utilisé. Si vous disposez de plusieurs instances de SQL Server sur un ordinateur, vous devez configurer un nom principal de serveur (SPN) pour chaque instance de SQL Server parce que chacune d'entre elles utilise un port TCP-IP qui lui est propre.

Activation de Kerberos pour SQL Server 2005

Connectez-vous à un serveur exécutant Microsoft Internet Information Services et établissez une connexion Kerberos à SQL Server 2005.

  1. Étape 1 : Configuration du contrôleur de domaine

Sur un contrôleur de domaine, dans Utilisateurs et ordinateurs Active Directory :

  1. Cliquez avec le bouton droit sur l'ordinateur que vous souhaitez configurer pour la délégation (serveur IIS), puis cliquez sur Approuver cet ordinateur pour la délégation. Si l'ordinateur qui exécute SQL Server semble être le dernier ordinateur contacté mais est lié à un serveur, il doit lui aussi recevoir des autorisations de délégation. S'il n'est pas le dernier ordinateur de la chaîne, tous les ordinateurs intermédiaires doivent être approuvés pour la délégation.
  2. Octroyez une autorisation de délégation au compte d'utilisateur de domaine du compte de service SQL Server. Vous devez avoir un compte d'utilisateur de domaine pour les installations SQL Server en clusters (cette étape n'est pas requise pour les ordinateurs qui exécutent SQL Server et qui utilisent un compte système local) :
    1. Dans le dossier des utilisateurs, cliquez avec le bouton droit sur le compte d'utilisateur, puis cliquez sur Propriétés.
    2. Dans la boîte de dialogue des propriétés du compte d'utilisateur, cliquez sur l'onglet Compte.
    3. Sous Options de compte, cliquez pour activer la case à cocher Le compte est approuvé pour la délégation. Vérifiez que la case à cocher Le compte est sensible et ne peut pas être délégué est désactivée pour ce compte.
  3. Employez l'utilitaire Kerbtray.exe pour vérifier que des tickets Kerberos ont été reçus du contrôleur de domaine et de l'hôte :
    1. Cliquez avec le bouton droit sur l'icône Kerbtray dans la zone de notification, puis cliquez sur purge tickets.
    2. Attendez que l'icône Kerbtray verte passe du vert au jaune. Dès que ceci se produit, ouvrez une fenêtre d'invite de commandes et exécutez cette commande :
      net session* /d
      Cette opération supprime les sessions existantes et force l'établissement d'une nouvelle session et la réception d'un ticket Kerberos.

Étape 2 : Configuration du serveur IIS

  1. Remplacez les fichiers Wwwroot du site Web par défaut par les exemples de fichiers .asp. Pour créer les exemples de fichiers .asp, utilisez le code fourni dans la section « Script de test ASP pour récupération de données SQL Server ».
  2. Ajoutez le fichier au dossier Wwwroot. Pour cela, utilisez l'exemple de code fourni dans la section « Script de test ASP pour récupération de données SQL Server ». Enregistrez le fichier sous Default.asp.
  3. Reconfigurez le serveur Web pour prévoir l'utilisation exclusive de l'authentification Windows intégrée :
    1. Cliquez avec le bouton droit sur le serveur Web par défaut, puis cliquez sur le dossier Sécurité.
    2. Dans le dossier Sécurité, apportez les modifications appropriées, puis cliquez pour désactiver accès anonyme.
    3. À partir d'une invite de commandes, exécutez la commande suivante :
      cscript C:\Inetpub\Adminscripts\adsutil.vbs get w3svc/NTAuthenticationProviders
      Si Negotiate est activé, la sortie suivante est retournée :
      NTAuthenticationProviders : (STRING) Negotiate,NTLM
      Pour plus d'informations sur la configuration d'IIS pour prendre en charge l'authentification Kerberos et l'authentification NTLM, consultez l'article de la Base de connaissances suivant Comment configurer IIS pour prendre en charge l'authentification Kerberos et NTLM.
    ms189585.note(fr-fr,SQL.90).gifRemarque :
    Vous devez installer Microsoft Data Access (MDAC) 2.8 SP1 ou version ultérieure sur le serveur IIS. Pour cela (et pour rendre les outils disponibles pour les tests), installez les outils clients Microsoft SQL Server 2000 sur le serveur Web. Pour installer uniquement MDAC 2.8 SP1 ou version ultérieure sans installer les outils clients, visitez ce site Web de Microsoft.
  4. Vérifiez que la valeur HKLM\SW\MS\MSSQLSERVER\Client\DSQUERY est présente dans le registre. Si la valeur n'est pas affichée, ajoutez-la sous la forme DSQUERY:Reg_SZ:DBNETLIB.
  5. Employez l'utilitaire Kerbtray.exe pour vérifier que des tickets Kerberos ont été reçus du contrôleur de domaine et de l'hôte :
    1. Cliquez avec le bouton droit sur l'icône Kerbtray dans la zone de notification, puis cliquez sur purge tickets.
    2. Attendez que l'icône Kerbtray verte passe du vert au jaune. Dès que ceci se produit, ouvrez une fenêtre d'invite de commandes et exécutez cette commande :
      net session * /d
      Cette opération supprime les sessions existantes et force l'établissement d'une nouvelle session et la réception d'un ticket Kerberos.

Étape 3 : Création d'un SPN pour SQL Server

ms189585.Caution(fr-fr,SQL.90).gifAttention :
SQL Server n'utilise Kerberos que si le client utilise le protocole TCP/IP pour se connecter à SQL Server. Par exemple, si un client utilise le protocole Canaux nommés, Kerberos n'est pas utilisé. Si vous disposez de plusieurs instances de SQL Server sur un ordinateur, vous devez configurer un nom principal de serveur (SPN) pour chaque instance de SQL Server parce que chacune d'entre elles utilise un port TCP-IP qui lui est propre.
ms189585.note(fr-fr,SQL.90).gifImportant :
Si le service SQL Server s'exécute sous le compte LocalSystem, vous n'avez pas à configurer manuellement un SPN pour SQL Server. Le SPN est créé automatiquement lors du démarrage du service SQL Server. Si le service SQL Server s'exécute sous un compte d'utilisateur de domaine, vous devez configurer manuellement un SPN. Pour cela, procédez comme suit :

Pour configurer un SPN pour SQL Server, employez l'utilitaire SETSPN du kit de ressources Microsoft Windows. Pour télécharger l'utilitaire SETSPN, visitez le site Web suivant de Microsoft.

Avant d'exécuter SETSPN, tenez compte des informations suivantes :

  • Vous devez exécuter setspn.exe sous un compte d'ouverture de session possédant des autorisations d'inscription du SPN.
  • Notez le compte d'utilisateur de domaine sous lequel s'exécute l'instance de SQL Server. Dans les exemples suivants, ce compte se nomme <SQL_Service_Account>.
    Important   Si l'instance de SQL Server s'exécute sous le compte LocalSystem, vous n'avez pas besoin d'exécuter l'utilitaire SETSPN.
  • Vous devez connaître le nom de domaine complet (FQDN) de l'ordinateur exécutant SQL Server. Pour déterminer le nom de domaine complet de l'ordinateur exécutant SQL Server, employez l'utilitaire ping. Pour cela, procédez comme suit :
  1. Soumettez une requête ping à l'ordinateur qui exécute SQL Server pour identifier son adresse IP :
    C:\>ping MySQLServer
    Pinging MySQLServer.MyDomain.com [10.10.10.10] with 32 bytes of data:
    Reply from 10.10.10.10: bytes=32 time=1ms TTL=128
  2. Utilisez ping -a pour effectuer une recherche inverse de l'adresse IP afin de vous assurer que le nom de domaine complet est correctement retourné par le protocole DNS (Domain Name System) :
    C:\>ping -a 10.10.10.10
    Pinging MySQLServer.MyDomain.com [10.10.10.10] with 32 bytes of data:
    Reply from 10.10.10.10: bytes=32 time<1ms TTL=128
  3. Soumettez une requête ping sur le nom de l'instance de cluster avec basculement pour obtenir l'adresse IP, puis exécutez ping -a pour vous assurer que le nom de domaine complet est correctement retourné par le protocole DNS.
ms189585.note(fr-fr,SQL.90).gifRemarque :
Si vous utilisez le clustering SQL Server avec basculement, vous pouvez utiliser le nom de domaine complet pour le nom de l'instance de cluster avec basculement. Notez le port TCP/IP exact que l'instance de SQL Server utilise. Pour obtenir cette information, ouvrez le Gestionnaire de configuration SQL Server sur l'ordinateur exécutant SQL Server, cliquez sur l'instance de SQL Server, puis affichez les propriétés du protocole TCP/IP (port par défaut).

Une fois que vous avez déterminé le compte d'utilisateur de domaine sous lequel le service SQL Server s'exécute, le nom de domaine complet de l'ordinateur exécutant SQL Server et le port TCP/IP que l'instance de SQL Server utilise, suivez ces instructions pour créer le SPN pour SQL Server.

ms189585.note(fr-fr,SQL.90).gifRemarque :
Vous devez être membre du groupe Administrateurs du domaine pour exécuter la commande SETSPN.
  1. Si vous utilisez le clustering avec basculement de SQL Server, exécutez la commande SETSPN suivante :
    setspn -A MSSQLSvc/<FQDN> <SQL_Service_Account>
    Par exemple, si MySQLServer.MyDomain.com s'exécute sous le compte d'utilisateur de domaine SQLSVC, où MySQLServer.MyDomain.com est le nom de l'instance de SQL Server 2005 en clusters, exécutez la commande suivante :
    setspn -A MSSQLSvc/MySQLServer.MyDomain.com SQLSVC
  2. Pour les ordinateurs cluster et non cluster qui exécutent SQL Server, exécutez la commande SETSPN suivante pour inscrire un SPN pour le port que l'ordinateur exécutant SQL Server utilise :
    setspn -A MSSQLSvc/<FQDN>:<Port> <SQL_Service_Account>
    Par exemple, si MySQLServer.MyDomain.com s'exécute sous le compte d'utilisateur de domaine SQLSVC sur le port 1433, exécutez la commande SETSPN suivante :
    setspn -A MSSQLSvc/MySQLServer.MyDomain.com:1433 SQLSVC
  3. Une fois que SPN est inscrit, vérifiez qu'il est correctement inscrit à l'aide de la fonction LIST (commutateur -L) de l'utilitaire SETSPN. Exécutez SETSPN -L <SQL_Service_Account> pour répertorier tous les SPN qui sont inscrits dans le compte d'utilisateur de domaine sous lequel l'instance de SQL Server s'exécute :
    setspn -L <SQL_Service_Account>
    Par exemple, si MySQLServer.MyDomain.com s'exécute sous le compte d'utilisateur de domaine SQLSVC sur le port 1433, exécutez la commande suivante :
    setspn -A SQLSVC
    Le SPN que vous avez créé à l'étape 1 (si SQL Server est organisé en clusters) et à l'étape 2 (si SQL Server n'est pas organisé en clusters) apparaît dans la sortie suivante :
    C:\>setspn -l SQLSVC
    Registered ServicePrincipalNames for CN=SQLSVC,CN=Users,DC=MyDomain,DC=com:
        MSSQLSvc/MySQLServer.MyDomain.com
        MSSQLSvc/MySQLServer.MyDomain.com:1433
ms189585.note(fr-fr,SQL.90).gifRemarque :
Si vous utilisez le clustering avec basculement de SQL Server, vous devrez inscrire un SPN sans le numéro de port et un autre SPN avec le numéro de port. Avec un ordinateur classique non cluster exécutant SQL Server, il vous suffit d'inscrire le SPN avec le numéro de port. Cependant, si vous avez un SPN supplémentaire sans le numéro de port, il ne causera pas de problèmes avec les ordinateurs non cluster.
ms189585.note(fr-fr,SQL.90).gifRemarque :
Vous pouvez également employer l'utilitaire Ldifde.exe sur le contrôleur de domaine pour vérifier les deux inscriptions SPN. Cette opération est décrite dans la section « Collecte d'une liste d'informations de nom principal de serveur Active Directory » dans cette rubrique.

Étape 4 : Configuration des ordinateurs clients

  1. Pour chaque client qui se connectera, vérifiez que Microsoft Internet Explorer est configuré pour utiliser l'authentification Windows :
  2. Dans Internet Explorer, dans le menu Outils, cliquez sur Options Internet.
  3. Cliquez sur l'onglet Options avancées.
    Sous Sécurité, cliquez pour activer la case à cocher Activer l'authentification intégrée de Windows (nécessite un redémarrage), puis cliquez sur OK.

Étape 5 : Test de la configuration

Pour chaque ordinateur qui est impliqué :

  1. Connectez-vous à l'ordinateur, puis utilisez Kerbtray.exe pour vérifier que l'ordinateur peut obtenir un ticket Kerberos valide du contrôleur de domaine.
  2. Utilisez Kerbtray.exe pour supprimer tous les tickets sur l'ordinateur.
  3. Créez la page Web qui retourne les données SQL Server et connectez-vous à celle-ci.
ms189585.note(fr-fr,SQL.90).gifRemarque :
Remplacez SQLSERVERNAME par le nom de l'ordinateur qui exécute SQL Server :
  • Si des données sont renvoyées, cette page affiche le type d'authentification Negotiate, et les données SQL Server du résultat de la procédure stockée sp_helpdb qui devrait renvoyer la liste des bases de données présentes sur le serveur en cours de connexion via la page .ASP.
  • Si la fonction d'audit est activée sur SQL Server, vous verrez dans le journal des applications que la connexion est « trusted » (approuvée).

Script de test ASP pour la récupération de données SQL Server

Voici un script de test ASP pour des données SQL Server. Si vous utilisez cet exemple de code, veillez à remplacer SQLSERVERNAME par le nom de l'ordinateur exécutant SQL Server :

<%@ Language=VBScript %>

<HTML>

<HEAD>

<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">

</HEAD>

<BODY>

<%="'auth_user' is" & request.servervariables("auth_user")%>

<P>

<%="'auth_type' is" & request.servervariables("auth_type")%>

<P>

Connections string is <B>" Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=SQLSERVERNAME </B>

<P>

<%

set rs = Server.CreateObject("ADODB.Recordset")

set cn = Server.CreateObject("ADODB.Connection")

cn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=SQLSERVERNAME"

rs.open "MASTER..sp_helpdb",cn

Response.Write cstr(rs.Fields.Count) +"<BR>"

while not rs.EOF

Response.Write cstr(rs(0))+"<BR>"

rs.MoveNext

wend

rs.Close

cn.Close

set rs = nothing ' Frees memory reserved by the recordset.

set cn = nothing ' Frees memory reserved by the connection.

%>

</BODY>

</HTML>

Collecte d'une liste d'informations de nom principal de serveur Active Directory

Pour collecter une liste d'informations de nom principal de serveur (SPN) Active Directory, tapez la commande suivante sur l'un de vos contrôleurs de domaine, où betaland est le nom de domaine NetBIOS et NewoutputUsers.txt est le nom du fichier de sortie que vous utiliserez pour transférer les résultats. Si vous n'utilisez pas un chemin complet, le fichier est placé dans le dossier en cours où vous exécutez la ligne de commande. Cet exemple de commande interroge la totalité du domaine :

ldifde -d "CN=Users,DC=betaland" -l servicePrincipalName -F NewoutputUsers.txt

Cette syntaxe crée un fichier nommé NewoutputUsers.txt qui contient des informations similaires à la sortie de la section « Sortie de niveau domaine de NewouputUsers.txt » de cette rubrique.

Cette sortie est peut-être volumineuse lorsqu'elle couvre l'ensemble d'un domaine. Par conséquent, pour limiter les informations recueillies à un nom d'utilisateur spécifique, utilisez la syntaxe suivante où User Name est le nom de l'utilisateur et betaland le domaine que vous interrogez :

ldifde -d "CN=User Name,DC=betaland" -l servicePrincipalName -F NewoutputUsers.txt

La collecte des informations d'un utilisateur spécifique réduit considérablement les données sur lesquelles porte la recherche. Si vous collectez les informations pour un domaine complet, recherchez le nom d'utilisateur spécifique du serveur en question. Dans l'exemple de sortie, vous voyez :

  • Des entrées pour des serveurs qui n'existent plus, mais qui ont été complètement supprimés d'Active Directory.
  • L'utilisateur « User Name » a des informations SPN valides sur environ dix serveurs différents.

En outre, vous pouvez utiliser l'outil ADSI (Active Directory Service Interfaces) pour corriger les entrées Active Directory qui ne sont pas valides.

Attention   Si vous utilisez le composant logiciel enfichable ADSI Edit, l'utilitaire LDP ou tout autre client LDAP version 3, et si vous modifiez incorrectement les attributs d'objets Active Directory, vous pouvez causer de graves problèmes. Ces problèmes peuvent imposer la réinstallation de Microsoft Windows 2000 Server, Microsoft Exchange 2000 Server, ou les deux. Microsoft ne garantit pas que les problèmes causés par une modification incorrecte des attributs d'objets Active Directory peuvent être résolus. Modifiez ces attributs à vos propres risques.

Sortie de niveau domaine de NewouputUsers.txt

dn: CN=User Name,CN=Users,DC=betaland

changetype: add

servicePrincipalName: MSSQLSvc/CLUSTERDEFAULT.betaland:1257

servicePrincipalName: MSSQLSvc/INST3.betaland:3616

servicePrincipalName: MSSQLSvc/INST2.betaland:3490

servicePrincipalName: MSSQLSvc/SQLMAN.betaland:1433

servicePrincipalName: MSSQLSvc/VSS1.betaland:1433

servicePrincipalName: MSSQLSvc/INST1.betaland:2536

servicePrincipalName: MSSQLSvc/INST4.betaland:3967

servicePrincipalName: MSSQLSvc/SQLVIRTUAL1.betaland:1434

servicePrincipalName: MSSQLSvc/SQLVIRTUAL.betaland:1433

servicePrincipalName: MSSQLSvc/SQLBUSTER.betaland:1315

Voir aussi

Autres ressources

Rubriques d'aide relatives à la configuration de la disponibilité
Installation de SQL Server 2005
Mise à niveau vers SQL Server 2005

Aide et Informations

Assistance sur SQL Server 2005