pilgrim[.maleo.net]

Un ami (Olivier pour ne pas le citer) m'a soumis un article de son cru écrit après un problème auquel il a été confronté lors de la migration d'une application web écrite en CGI Delphi sur un serveur Windows 2003. Je le publie ici dans l'espoir qu'il puisse servir à d'autres, le fait étant qu'il n'y a pas beaucoup de ressources francophone sur le sujet.

Description du problème

Il m’est arrivé un sérieux souci récemment lorsqu’il a fallu porter une application web écrite en cgi Delphi sur un serveur windows 2003 équipé de IIS 6.0. Après moult recherche, la solution a fini par être trouvée.

Devant le peu de ressources Internet, surtout dans les pages francophones, j’ai pensé qu’il serait bon de placer quelques notes concernant ce problème sur Internet. Voici le résultat de ces analyses.

Précisons tout d’abord qu’il existe un bug dans l’unité « Sysutils.pas » de Delphi, qui rend les CGI créés en mode autonome (les « .exe », cela ne concerne pas les dlls) incompatibles sous Windows Server 2003, que vous utilisiez Apache ou IIS.

Le problème sous Apache se traduisait dès que l’on essaye de manipuler la querystring. Sous IIS, aucun CGI ne marche et l’on aboutit toujours à une erreur 404 (belle identification de l’erreur d’ailleurs, vu que ça n’a rien à voir avec une page introuvable…).

Ce problème est résolu à partir de la version 7.1 de Delphi. Si comme moi vous utilisez encore la version 6, vous devrez modifier votre unité « Sysutils.pas ». Avant de compiler votre projet, modifiez la fonction « GetEnvironmentVariable » comme suit :

function GetEnvironmentVariable(const Name: string): string;
var
   Len: integer;
   W : String;
begin
   Result := '';
   SetLength(W,1);
   Len := GetEnvironmentVariable(PChar(Name), PChar(W), 1);
   if Len > 0 then
   begin
   	SetLength(Result, Len - 1);
	   GetEnvironmentVariable(PChar(Name), PChar(Result), Len);
   end;
end;

Pour ceux qui ont accès au support de Borland, cette erreur est référencée dans le « quality center » par le numéro 4319.

Une fois votre projet compilé, les cgi fonctionneront normalement sous Apache. En revanche, vous ne pourrez toujours pas migrer votre application vers IIS 6.0 sans mettre la main à la pâte dans la configuration du serveur web.

Les explications ci-dessous ne se limitent plus qu’aux CGI Delphi. Les développeurs Perl pourront également y trouver des astuces intéressantes, même si je ne m’attarderai pas sur le mappage des applications (les CGI Delphi étant autonomes, ils n’ont pas besoins d’être mappé). La suite peut également intéresser toute personne soucieuse de connaître un peu mieux la nouvelle stratégie de sécurité de Microsoft, et comment gérer les difficultés liées aux droits utilisateurs.

Les cgi ne sont par défaut pas autorisés dans IIS. A l’installation, le serveur n’est configuré que pour exécuter des pages statiques.

Solution : dans le gestionnaire des services IIS, déroulez le nœud « Extension du service web » et cliquez sur le bouton « autoriser » sur l’extension du service web « Toutes les extensions cgi inconnues ».

Maintenant, il va falloir donner les bons droits aux applications. Trois possibilités s’offrent à vous suivant la configuration que vous souhaitez mettre en place.

I. Utiliser un compte prédéfini de IIS

IIS 6 est installé avec un minimum de droits par défaut. Il utilise, en plus du compte utilisateur classique « IUSER », un autre compte appelé « Network Service » pour donner des droits aux applications.

Dans le nouveau système de Microsoft est utilisé le mode « Pool d’applications » par défaut. Avec ce système, il convient de donner des droits plus conséquents aux CGI. Pour ce faire :

• dans l’explorateur de IIS, exécutez un clic-droit sur le nœud « Pool d’applications », choisissez l’option « Propriétés »
• cliquez sur l’onglet « Identité »
• dans la liste déroulante des comptes de sécurité prédéfini, choisissez « Système Local » (attention � ne pas confondre avec le compte « Service Local »)
• appliquez la modification, IIS vous prévient que cette solution peut engendrer des risques de sécurité. Cliquez sur « Oui ».
• à titre de précaution, redémarrez le service « Pool d’applications » (icônes « stop » et « lecture »)

II. Ajouter uniquement les droits nécessaires à l’exécution des CGI

Avec la méthode précédente, IIS nous informe que nous donnons des droits pouvant être dangereux pour la stratégie de sécurité du serveur.

Après plusieurs recherches, il est possible de n’ajouter que les droits manquant au compte par défaut de sécurité (« Service Réseau »).

Le compte Service Réseau est membre du groupe « IIS_WPG ». Il faut ajouter à ce dernier les droits d’utilisateurs suivants :

• changer les quotas de mémoire d'un processus
• remplacer un jeton au niveau du processus

Sur notre machine de test, ces droits étaient à configurer à deux endroits distincts :

• dans la stratégie de sécurité du contrôleur de domaine
• dans la stratégie de sécurité du domaine

Il n’en sera peut être pas de même chez vous. Si votre serveur est contrôleur de domaine, il vous faut mettre les droits sur les deux stratégies. En revanche, si votre machine n’est pas contrôleur de domaine, mettre les droits en local (« stratégie de sécurité du domaine ») devrait s’avérer suffisant.

Procédure pour l’affectation des droits :

• ouvrez les outils d’administrations puis choisissez « services »
• repérez la ligne « Service d’administration IIS ». Arrêter le service. Il va vous être demandé si vous souhaitez arrêter les services dépendants (service de publication www, http SSL). Cliquez sur « Oui »
  

  

• ouvrez les outils d’administrations puis choisissez « stratégie de sécurité du domaine »
• dans l’explorateur du volet gauche, dépliez les nœuds « stratégie locale » puis « Attribution des droits utilisateurs »

Dans le volet droit s’affiche les différents droits disponibles :

• repérez le droit nommé « Changer les quotas de mémoire d’un processus ». Double-cliquez sur la ligne.
• la fenêtre d’attribution des comptes pour ce droit s’affiche :
  

  

• cliquez sur le bouton « Ajouter un utilisateur ou un groupe »
• choisissez le compte utilisateur « IIS_WPG »
  

  

• validez votre saisie jusqu’à revenir � la fenêtre listant les droits utilisateurs disponibles
• répétez l’étape pour la ligne « Remplacer un jeton au niveau du processus »

Conformément à ce qui a été expliqué ci-dessus, vous aurez peut-être à dupliquer ces opérations pour la stratégie concernant le contrôleur de domaine.

Il reste à prendre en compte ces nouvelles stratégies de sécurité. Vous disposez de la commande « gpupdate ». Ouvrez la console MS-Dos (démarrer -> exécuter -> « cmd »). Tapez la commande : « gpupdate /force »

Vous pouvez maintenant redémarrer les services IIS (voir plus haut).

Nous avons hélas constaté que, même après cette manipulation, les stratégies n’étaient pas forcément appliquées dans la foulée. Hormis l’attente et les redémarrages successifs de la machine, il n’a pas été trouvé de solution miracle. Pour autant, tout devrait rentrer dans l’ordre en s’armant de patience.

Pour être efficace et propre, cette politique de sécurité nécessite qu’on l’utilise uniquement avec les applications en ayant besoin. Nous conseillons donc de suivre les étapes suivantes dans la configuration de IIS pour configurer un « Pool d’applications » propre à une application :

• ouvrez le gestionnaire des services internet IIS
• sélectionnez le nœud « Pool d’applications », clic-droit. Puis, dans la liste déroulante, « Nouveau => Pool d’applications » :
  

  

• saisissez un nom parlant pour la boîte « ID du pool d’applications ». Laissez les paramètres par défaut. Validez la saisie.
• votre nouveau pool apparaît dans la liste. Sélectionnez le, exécutez un clic-droit => propriétés et vérifiez dans l’onglet « identité » qu’il est bien appliqué au compte de sécurité « Services Réseau »

L'étape finale consiste à associer les répertoires virtuels au pool d’application que vous venez de créer :

• dépliez les nœuds « Sites Web » et « Site Web Par Défaut ».
• sélectionnez votre répertoire virtuel, clic-droit => propriétés
• dans l’onglet répertoire virtuel, repérez le bloc « Paramètres d’applications ». Au sein de ce dernier, vous avez une liste déroulante permettant de choisir un pool d’application. Choisissez celui que vous venez de créer :
  

  

III. Mode Isolation IIS 5.0

Une alternative au « Pool d’applications » existe. Elle consiste à revenir dans le mode d’isolation de IIS 5.0. Pour ce faire :

• dans l’explorateur de IIS, exécutez un clic-droit sur le nœud « Sites Web », choisissez l’option « Propriétés »
• positionnez-vous sur l’onglet « Service »
• cliquez, dans l’encart « Mode d’isolation », cochez la case « Exécuter les services Web en mode d’isolation IIS 5.0 »
• appliquez la modification, IIS va vous signaler qu’il doit redémarrer le service. Cliquez sur « Oui ».
• vous pouvez quitter la fenêtre des propriétés « Sites Web »

Vous constatez que le nœud « Pool d’application » a disparu.

Quel choix appliquer parmi les trois solutions proposées ?

La solution n°2, consistant à n’ajouter que les droits nécessaires au compte disposant des plus grandes restrictions semblent la plus opportune. Elle est en revanche la plus compliquée à mettre en place.

Le choix n°1 fonctionne sans demander d’efforts particuliers. Par contre, elle attribue des droits conséquents à des applicatifs n’en n’ayant pas forcément besoin. Il est écrit noir sur blanc dans la documentation qu’un utilisateur malveillant peut avoir le contrôle complet de la machine. A utiliser en connaissance de cause.

Le choix n°3 enlève les pré dispositions de Microsoft en termes de sécurité, vu que le nouveau système « Pool d’application » n’est plus utilisé. Il est confronté aux mêmes problèmes que IIS 5.0.