Partager via

Comment utiliser le verrouillage dans la configuration d'IIS 7.0

  • Article

AuteurSaad Ladki

Abstract

Le présent document explique comment verrouiller et déverrouiller la configuration sur le serveur. Vous découvrirez les paramètres que les fichiers de configuration au niveau de l'application peuvent remplacer et comment utiliser l'élément <location> pour verrouiller des sections entières.

Vous expérimenterez un verrouillage plus granulaire des paramètres de configuration, à l'intérieur des sections, notamment :

  • Verrouillage d’éléments et d’attributs spécifiques
  • Verrouillage de tout, à l’exception d’éléments ou d’attributs spécifiques
  • Verrouillage de directives de collecte spécifiques comme les directives <add>,<remove>, et <clear>
  • Verrouillage d'éléments spécifiques dans les collections

Après avoir lu ce document, vous saurez comment gérer les différentes caractéristiques du verrouillage de la configuration en modifiant directement les éléments XML dans les fichiers de configuration (l'interface de programmation permettant d'effectuer ces tâches suit de très près la structure XML).

Ce document se concentre intentionnellement sur l'édition d'éléments XML dans les fichiers de configuration, au lieu de montrer comment accomplir les mêmes tâches à l'aide de l'API d'administration, de scripts ou de l'interface utilisateur (UI).

Introduction

IIS 7.0 et les versions ultérieures permettent de verrouiller et de déverrouiller les paramètres de configuration à différents niveaux et dans différentes portées. Le verrouillage de la configuration signifie qu'elle ne peut pas être remplacée (ou définie du tout) à des niveaux inférieurs de la hiérarchie. Le déverrouillage de la configuration ne peut se faire qu'au niveau où elle a été verrouillée. Ceci est utile, par exemple, lorsque l'on crée une configuration différente pour différents sites ou chemins, et que seuls certains sites et chemins sont autorisés à la remplacer. Le verrouillage peut être effectué au niveau de la section ou pour des éléments, attributs, éléments de collection et directives de collection spécifiques au sein des sections.

Tâche 1 : verrouiller une section à l'aide d'une balise <location>

Dans cette tâche, vous apprenez à utiliser la balise <location> pour verrouiller (ou déverrouiller) des sections de configuration entières au niveau global afin qu'elles ne puissent pas être remplacées aux niveaux d'application de la hiérarchie de configuration.

Remarque

La plupart des sections IIS du fichier applicationHost.config sont verrouillées par défaut, et aucune section de l’infrastructure .NET ne l'est (notamment les sections ASP.NET du groupe de sections <system.web> du fichier machine.config et du fichier web.config racine).

À l'aide d'un éditeur de texte tel que le Bloc-notes, ouvrez le fichier applicationHost.config à l'emplacement suivant :

%windir%\system32\inetsrv\config\applicationHost.config

Examinez la section<configSections> située tout en haut du fichier : elle contient des métadonnées sur les sections de configuration de ce fichier, telles que les noms des sections, les groupes de sections qu'elles contiennent et le fait qu'elles soient verrouillées ou non.

Les sections verrouillées sont spécifiées par l'attribut « overrideModeDefault », qui est soit « Allow » (Autoriser), soit « Deny » (Refuser). Très peu de sections ne sont pas verrouillées par défaut, comme le précise cette ligne par exemple :

<section name="defaultDocument" overrideModeDefault="Allow" />

Ici, nous avons affaire à la section <windowsAuthentication>. Elle est verrouillée par défaut.

Afin de déverrouiller la section entière pour toutes les applications sur le serveur, déplacez son contenu de son emplacement actuel dans le fichier au bas du fichier et placez-le à l'intérieur d'un élément <location overrideMode="Allow">. N'oubliez pas les groupes de sections qui l’entourent : <system.webServer>puis <security> et ensuite <authentication>. Le résultat final doit ressembler à ceci :

<location overrideMode="Allow">
  <system.webServer>
     <security>
        <authentication>
          <!-- the content of windowsAuthentication section is here -->
        </authentication>
     </security>
  </system.webServer>
</location>

La section est maintenant déverrouillée pour toutes les applications. Vous pouvez spécifier un chemin sur la balise d’emplacement, de sorte que la section ne sera déverrouillée que pour ce chemin. Le chemin par défaut, s'il n'est pas spécifié (comme dans l'étape précédente), est chemin d’accès="." (ou chemin d’accès="", ce qui revient au même), ce qui signifie « le niveau actuel ». Dans ce cas, puisqu'il s'agit de applicationHost.config, le niveau actuel est le niveau global. Vous pouvez également utiliser des balises d'emplacement n'importe où dans la hiérarchie de l'espace de noms, par exemple dans un web.config au niveau vdir, pour verrouiller la configuration à partir de ce point vers le bas.

Voici un exemple indiquant comment déverrouiller cette section uniquement pour le site « AdminSuperTrusted ». Cela signifie que les fichiers Web.config de ce site peuvent remplacer les paramètres de cette section ; cependant, pour tous les autres sites de la boîte, ils sont verrouillés au niveau global et ne peuvent pas être remplacés.

Dans cet exemple, vous devez laisser le contenu de la section à son emplacement d'origine dans applicationHost.config, puis spécifier la section dans la balise d’emplacement avec un chemin spécifique :

<location path="AdminSuperTrustedSite" overrideMode="Allow">
  <system.webServer>
    <security>
      <authentication>
        <!-- note: this is different than previous example, in that  -->
        <!-- the content of the section is in the original place and -->
        <!-- was not moved here; in addition, the section is also    -->
        <!-- specified here, just by its name, so that it gets       -->
        <!-- unlocked only for the site specified in the location.   -->
        <windowsAuthentication/>
      </authentication>
    </security>
  </system.webServer>
</location>

Revenant au troisième exemple ci-dessus, la section est déverrouillée pour toutes les applications de tous les sites (chemin d’accès de l’emplacement="."). Vérifiez que le groupe de sections d'<authentification> primaire (celui qui se trouve à l'extérieur de l'<location>élément, plus haut dans le fichier) ne contient pas de section <windowsAuthentication>. Une section ne peut pas apparaître dans le même fichier à la fois en dehors d'une balise d’emplacement et à l’intérieur d’une balise <chemin d’accès de l’emplacement="."> ; cela est en effet considéré comme une configuration non valide.

Pour vérifier si une section est verrouillée ou non, allez à http://localhost/app dans le navigateur.

Si la section est verrouillée, le navigateur affiche une erreur car le fichier Web.config au niveau de l'application contient la section <windowsAuthentication>. Cela signifie que le fichier Web.config tente de remplacer <windowsAuthentication> à son niveau. Toutefois, comme cette section est désormais verrouillée au niveau global, la configuration du fichier web.config n'est pas valide.

Modifiez la balise location pour qu'elle ait overrideMode=« Deny ». Cela verrouille à nouveau la section. Expérimentez avec d'autres sections, telles que les sections ASP.NET dans machine.config ou web.config racine. Essayez de les verrouiller au niveau global et de les remplacer au niveau du fichier web.config.

Tâche 2 : verrouiller des éléments et des attributs spécifiques

En vous basant sur la tâche précédente, localisez la section <windowsAuthentication> à l'intérieur de la balise <location>. Définissez la balise d’emplacement pour déverrouiller la section : overrideMode=« Allow ». Nous ne verrouillerons pas des parties spécifiques de la section.

Définissez l'attribut enabled (activé) à true (vrai), puis verrouillez-le en définissant lockAttributes=« enabled » (activé).

Cela empêche un fichier de configuration au niveau de l'application de modifier la valeur de l'<windowsAuthentication>attribut activé de la section.

Si vous souhaitez verrouiller d'autres attributs, ajoutez-les à la valeur lockAttributes en les séparant par des virgules, comme dans l'exemple suivant :

lockAttributes="enabled,attribute1,attribute2"

Vous pouvez également verrouiller tous les attributs à l’aide de « * », comme dans cet exemple :

lockAttributes="*"

La section doit maintenant ressembler à ce qui suit :

<location path="." overrideMode="Allow">   <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication enabled="true" lockAttributes="enabled">          
          <providers>
            <add value="Negotiate" />
            <add value="NTLM" />
          </providers>
        </windowsAuthentication>
      </authentication>
    </security>
  </system.webServer>
</location>

Dans le fichier Web.config de votre application, essayez de remplacer les paramètres de la section <windowsAuthentication>.

Dans le navigateur, demandez la page pour vérifier que vous pouvez remplacer tous les paramètres à l'exception de ceux que vous avez verrouillés, en l'occurrence l'attribut enabled (activé).

Remarque

Le simple fait de spécifier l'attribut dans le fichier Web.config entraîne un échec de la configuration, même si l'attribut défini dans le fichier Web.config a la même valeur que dans le fichier ApplicationHost.config. La définition d'un attribut verrouillé à n'importe quelle valeur est considérée comme une tentative d'annulation de l'attribut et échoue donc. (Notez également que les attributs sont différents des éléments ; dans la prochaine tâche, vous verrouillerez un élément.)

Supprimez l’attribut lockAttributes.

Définissez lockElements=« providers » (fournisseurs) pour verrouiller l'élément <providers> dans la section.

Si vous avez d'autres éléments à verrouiller, vous pouvez les ajouter en les séparant par des virgules, comme ceci :

lockElements="providers,element1,element2"

La section doit maintenant ressembler à ce qui suit :

<location path="." overrideMode="Allow">   <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication enabled="true" lockElements="providers">
          <providers>
            <add value="Negotiate" />
            <add value="NTLM" />
          </providers>
        </windowsAuthentication>
      </authentication>
    </security>
  </system.webServer>
</location>

Dans le fichier Web.config de l'application, remplacez l'élément <providers> en le définissant ou en essayant d'ajouter, de retirer ou d'effacer la collection.

Dans le navigateur, demandez la page et remarquez qu'une erreur s'affiche. Dans le fichier web.config, remplacez d’autres éléments ou attributs tels que l’attribut enabled (activé). Accédez à la page et vérifiez qu'aucune erreur n'est affichée.

Supprimez l’attribut lockElements.

Tâche 3 : tout verrouiller sauf des attributs spécifiques

Dans cette tâche, vous apprenez à verrouiller tous les éléments ou attributs d'une section, à l'exception des attributs spécifiques que vous définissez. Ceci est utile si vous n'êtes pas sûr des propriétés que la section a actuellement ou aura à l’avenir, et que vous souhaitez tout verrouiller à l'exception des propriétés que vous avez explicitement définies comme devant être déverrouillées.

En vous basant sur la tâche précédente, localisez la section <windowsAuthentication> dans la balise d’emplacement.

Définissez les attributs lockAllElementsExcept ou lockAllAttributesExcept sur une liste d’éléments ou d’attributs à verrouiller délimités par des virgules. Par exemple, la section pourrait se présenter comme suit :

<windowsAuthentication enabled="true" lockAllElementsExcept="providers">
     <providers>
          <add value="Negotiate" />
          <add value="NTLM" />
     </providers>
</windowsAuthentication>

Ou comme cela :

<windowsAuthentication enabled="true" lockAllAttributesExcept="enabled">
     <providers>
          <add value="Negotiate" />
          <add value="NTLM" />
     </providers>
</windowsAuthentication>

Dans cette section en particulier, il n’existe actuellement aucun autre attribut ou élément. Si vous souhaitez tester l’effet de la définition des attributs lockAllElementsExcept oulockAllAttributesExcept, ajoutez les mêmes attributs à d’autres sections qui ont un ensemble plus riche d’attributs.

Tâche 4 : verrouiller certaines directives de collecte

Dans cette tâche, vous apprendrez à verrouiller les directives <add> et <remove> d’une collection afin que les éléments de fichier de configuration puissent être ajoutés au niveau de l’application, mais pas supprimés.

En vous basant sur la tâche précédente, localisez la section <windowsAuthentication> dans la balise d’emplacement.

Définissez l’attribut lockElements dans la collection <providers> pour supprimer , effacer.

Au terme de l’opération, la section se présentera comme suit :

<windowsAuthentication enabled="true" >
  <providers lockElements="remove,clear">
    <add value="Negotiate" />
    <add value="NTLM" />
  </providers>
</windowsAuthentication>

Dans le fichier web.config de l’application, créez un élément <remove> qui supprime l’élément NTLM de la collection.

Au terme de l’opération, le fichier web.config se présentera comme suit :

<configuration>
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication>
          <providers>
            <remove value="NTLM" />
          </providers>
        </windowsAuthentication>
      </authentication>
    </security>
  </system.webServer>
</configuration>

Dans le navigateur, demandez http://localhost/app.

Tâche 5 : verrouiller des éléments spécifiques dans une collection

Dans cette tâche, vous apprendrez à verrouiller des éléments de collection spécifiques. Les développeurs peuvent toujours ajouter des éléments à la collection à des niveaux inférieurs (application) de la hiérarchie, et ils peuvent toujours supprimer des éléments non verrouillés de la collection. Toutefois, ils ne peuvent pas supprimer les éléments que vous avez verrouillés de manière spécifique. La collection ne peut pas être désactivée, car cela impliquerait la suppression de tous les éléments de la collection.

En utilisant les tâches précédentes, recherchez la section <windowsAuthentication> dans la balise d’emplacement.

Dans la collection <providers>, dans l’élément <add> du fournisseur NTLM, définissez l’élément lockItem sur « true » (vrai).

Au terme de l’opération, la section se présentera comme suit :

<windowsAuthentication enabled="true" >
  <providers>
    <add value="Negotiate" />
    <add value="NTLM" lockItem="true" />
  </providers>
</windowsAuthentication>

Dans le fichier web.config de l’application, créez un élément <remove> qui supprime l’élément NTLM de la collection.

Au terme de l’opération, le fichier Web.config se présentera comme suit :

<configuration>
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication>
          <providers>
            <remove value="NTLM" />
          </providers>
       </windowsAuthentication>
      </authentication>
    </security>
  </system.webServer>
</configuration>

Dans le navigateur, demandez http://localhost/app -- la requête échoue.

Résumé

Dans ce document, vous avez appris à verrouiller les paramètres de configuration. Vous pouvez verrouiller une section entière, soit à l’aide d’un élément <location>, soit en définissant l’attribut lockItem d’une balise sur « true » (vrai). Le verrouillage peut être plus flexible et granulaire si vous utilisez les paramètres lockAttributes, lockElements,lockAllAttributesExcept,lockAllElementsExceptoulockItemsur les éléments de collection, et si vous utilisez les paramètres lockElements sur les collections pour spécifier des directives de collection particulières (<add>, <remove>ou <clear>). Le verrouillage peut être effectué à n'importe quel niveau de la hiérarchie, pas seulement dans ApplicationHost.config. Le verrouillage entre en vigueur à partir de ce niveau.