Configuration des sécurités de SQL Server 7.0 et de IIS

Pourquoi ne peut-on pas substituer un nom d’utilisateur et un mot de passe NT
à  son équivalent SQL Server dans une chaîne de connexion ? SQL Server ne supporte
pas les connexions qui font référence explicitement à  un nom d’utilisateur et
un mot de passe NT. Le plus approchant serait d’utiliser une connexion sécurisée,
ce qui signifie qu’une personne ou un programme doit déjà  être connecté avec un
compte NT valide, et que SQL Server utilise les références et les autorisations
de ce compte pour la connexion. Pour les pages Web servies par IIS et délivrant
des connexions base de données au public, ce compte NT est le compte anonyme associé
à  chaque page Web.

Chacune des pages Web d’un serveur IIS utilise soit un accès anonyme, soit nécessite
un login et un mot de passe. Les pages qui utilisent des login Windows sont sécurisées,
mais pour les pages Web publiques, il faut choisir le compte Windows que IIS va
utiliser lorsque les utilisateurs la demanderont. Par défaut, le compte local
IUSR_servername du serveur IIS est celui qui est mappé. Si le site Web n’utilise
qu’un jeu commun d’autorisations pour toutes les pages, ce compte utilisateur
par défaut sera peut être le seul nécessaire.

S’il faut plus d’un jeu d’autorisations, on peut attribuer individuellement des
comptes Windows différents aux pages Web. Par exemple, le compte utilisateur anonyme
de  » page1.asp  » peut être User1, alors que le compte de page2.asp pourra être
User2. On peut modifier le login du compte anonyme pour tout le site, pour toutes
les pages d’un répertoire, ou page par page. Les pages Web utilisant IIS peuvent
utiliser n’importe quelle combinaison de comptes entre les répertoires et les
pages, mais ne peuvent utiliser qu’un seul compte par page. Bien sûr, dans le
cas où on aurait besoin de plusieurs jeux de droits pour une page, il faut utiliser
un login conditionnel, pour lequel la variable résultat dépend de l’utilisateur
connecté. Le listing 1 montre un exemple de ce type en VBScript.

Pour modifier le compte utilisateur anonyme sous NT 4.0 en utilisant IIS 4.0,
on ouvre la console de gestion IIS Manager et on descend jusqu’au niveau d’un
répertoire ou d’une page du site Web. On choisit un répertoire/page et on clique-droit
sur Properties, puis on choisit l’onglet Directory Security (cf. figure 1). Cliquer
sur le bouton Edit dans la section Anonymous Access and Authentication Control,
et sélectionner Allow Anonymous Access (cf. figure 2). Ensuite, cliquer sur le
bouton Edit pour ouvrir la fenêtre Anonymous User Account (cf. figure 3). Cliquer
sur Browse pour choisir un nouveau compte. En SQL Server, on doit spécifier le
compte Windows pour lequel on choisit les droits requis par les procédures cataloguées,
et les requêtes appelées par la page Web.
Sachez que lorsqu’on transforme un compte utilisateur anonyme en un compte NT,
la fonctionnalité de synchronisation automatique des mots de passe ne fonctionne
plus. Il faut la désactiver et entrer le mot de passe du compte à  la main. La
synchronisation automatique ne fonctionne qu’avec des comptes locaux par rapport
au serveur Web.
Maintenant, tout est prêt pour créer des chaînes de connexion sécurisées. En VB,
il faut d’abord créer un projet standard, sélectionner References, et ajouter
la bibliothèque de type Microsoft OLE DB Service Component 1.0. Ajouter ensuite
le code suivant :

Dim objDataLink As New DataLinks
Dim strConn$
strConn = objDataLink.PromptNew

Lorsqu’on exécute le code, PromptNew va ouvrir la fenêtre  » Data Link Properties
« , comme le montre la figure 4. Pour plus d’information sur la façon de créer
des chaînes de connexion, référez-vous à  l’article Microsoft : HOWTO: Use Data
Links to Create a Connection String at Run-Time (http://support.microsoft.com/support/kb/articles/q218/6/00.asp).
Ensuite, il faut choisir une source de données. Voici un conseil pour améliorer
les performances des connexions utilisant OLE DB : choisir le provider Microsoft
OLE DB pour SQL Server plutôt que celui pour les drivers ODBC, pour éliminer les
couches ODBC inutiles et améliorer les performances.
Ensuite, on sélectionne l’onglet Connection ou on clique sur Next, on entre le
nom du serveur de base de données, on choisit Use Windows NT Integrated Security,
puis on entre le nom de la base de données
(cf. figure 5). En cliquant sur le bouton Test Connection, on peut tester l’accès
au serveur et à  la base de données avec son compte NT.

La chaîne construite par la méthode qui se cache derrière le bouton ne
contient pas de nom d’utilisateur ni de mot de passe

Mais la chaîne construite par la méthode qui se cache derrière le bouton ne contient
pas de nom d’utilisateur ni de mot de passe. Donc, dès qu’un utilisateur appelle
cette chaîne, elle sera remplie avec les données du compte sous l’autorité duquel
elle se trouve. Dans le cas d’ASP (Active Server Pages), ce compte est le compte
utilisateur anonyme. Le fait que ces chaînes de connexion ne contiennent pas de
noms d’utilisateur ni de mots de passe améliore par la suite la sécurité en protégeant
l’information de toute personne ayant accès aux code source de la page Web.
Si on exécute un projet VB en mode déboguage, on peut revenir au projet en cliquant
sur OK, et la variable strConn contiendra la nouvelle chaîne. Par exemple, une
chaîne OLE DB de connexion sécurisée pourrait ressembler à  ceci :

Provider=SQLOLEDB.1;Integrated
Security=SSPI;Persist Security
Info=False;Initial Catalog=Sales;Data
Source=Server2

où Data Source est le nom du serveur et Initial Catalog le nom de la base de données.
Voici un exemple de chaîne de connexion ODBC :

DSN=Sales;SERVER=Server2;APP=Visual
Basic;WSID=WS2;DATABASE=Sales;QueryLogFile
=Yes

Maintenant, insérez la nouvelle chaîne de connexion sécurisée dans les objets
ou les pages Web. En plaçant L’insertion des chaînes de connexion dans le code
compilé des objets MTS est bien plus efficace que dans les scripts d’une page
Web, tant pour les sécurités que pour les performances. Mais si l’on n’est pas
familier de MTS, des chaînes de connexion sécurisées OLE DB dans les scripts des
pages amélioreront toujours les performances et les sécurités, en comparaison
des connexions ODBC avec les comptes sur SQL Server, ce qui est illustré par le
listing 2.
Après avoir terminé d’installer la nouvelle chaîne de connexion, et fini d’utiliser
les comptes SQL Server, tout est prêt pour reconfigurer SQL Server pour qu’il
puisse utiliser une authentification NT, ce qui est rapide et facile. Il faut
ouvrir Enterprise Manager, cliquer-droit sur le serveur, sélectionner Properties,
puis l’onglet Security. Comme le montre la figure 6, sélectionner Windows NT only
dans la section Authentication, puis cliquer sur OK dans chacun des écrans suivants.
Enfin, il suffit d’arrêter et de redémarrer SQL Server pour que les modifications
prennent effet.
En suivant ces conseils, on améliore les sécurités et les performances de la connexion
aux données avec SQL Server.