Prise en main de la configuration dans IIS 7 et versions ultérieures

Article
03/07/2024

Abstract

Le système de configuration dans IIS 7 et dans les versions ultérieures sont basés sur des fichiers XML distribués, en texte clair, qui contiennent les paramètres de configuration de l’ensemble de la plateforme de serveur web, y compris IIS, ASP.NET et d’autres composants, et peuvent éventuellement être définis sur les répertoires de contenu avec le contenu web. Différents niveaux de la hiérarchie de configuration peuvent être délégués par l’administrateur de l’ordinateur à d’autres utilisateurs, tels que l’administrateur de site ou le développeur d’applications. Sécuriser les paramètres de configuration par défaut et de verrouillage hors connexion limite l’accès en écriture aux paramètres de configuration de l’administrateur de l’ordinateur uniquement ; Toutefois, les fonctionnalités de verrouillage sophistiquées et granulaires permettent le déverrouillage sécurisé et la délégation de la gestion des paramètres de configuration spécifiques à davantage d’utilisateurs, pour leur étendue de l’espace de noms web. Le système est rétrocompatible, au niveau de l’API, avec les versions précédentes d’IIS et au niveau XML, avec les versions précédentes du .NET Framework. Ce document donne une vue d’ensemble générale du nouveau système de configuration.

Introduction

Le nouveau système de configuration est conçu pour être :

Simple : tout l’état se trouve dans les fichiers ; Aucun magasin propriétaire n’est utilisé ; Aucune base de données de configuration en mémoire qui est le maître réel de l’état de configuration (contrairement au service IISADMIN dans IIS 6.0) ; Le schéma est piloté par les données et est déclaratif et détectable à 100 %.
Low-TCO : La configuration peut être copiée avec du contenu web ; L’administration déléguée facultative élimine l’implication de l’administrateur de l’ordinateur dans chaque modification de configuration ; L’unification des paramètres de configuration et du modèle dans IIS, ASP.NET et le reste de la plateforme de serveur web fournit un point d’arrêt pour gérer le serveur à l’aide du même ensemble d’outils et d’API (par exemple, les fichiers web.config peuvent contenir des paramètres IIS et ASP.NET, et il existe un emplacement unique pour contrôler les fonctionnalités telles que l’authentification, l’autorisation, les erreurs personnalisées) ; les listes de contrôle d’accès (ACL) de sauvegarde, de restauration et de sécurité sont basées sur les outils et processus standard du système de fichiers.
Sécurisé : lorsque IIS est installé, l’état de configuration se trouve dans un fichier protégé uniquement pour l’accès administrateur de l’ordinateur ; Aucune délégation n’est activée par défaut ; Aucune information sensible (par exemple, les mots de passe) n’est stockée par défaut ; Lorsque des informations sensibles doivent être écrites dans les fichiers de configuration, elles sont automatiquement chiffrées sur disque ; La configuration par application peut être encadrée par sable et isolée dans un fichier dédié (protégé par la liste de contrôle d’accès du système de fichiers) afin que d’autres applications ne puissent pas partager ni lire les paramètres.
Extensible : l’ajout au schéma est simplement une question de suppression d’un fichier XML dans le dossier schémas ; Il n’est pas nécessaire d’appeler des API ou d’exécuter des outils pour étendre le schéma ; Les paramètres sont organisés en blocs logiquement appelés « sections » (exactement comme dans la configuration du .NET Framework) et l’ajout de nouvelles sections est facile (il n’est pas nécessaire d’écrire du code, contrairement à la configuration du .NET Framework) ; La lecture des paramètres de section personnalisée à partir d’un module serveur ou d’une application est simple et directe.
Compatible : les applications IIS existantes peuvent continuer à appeler des interfaces comme Administration Objets de base (ABO), le fournisseur IIS ADSI et le fournisseur WMI IIS 6.0 ; Les applications .NET Framework existantes peuvent continuer à appeler des interfaces telles que System.Configuration et System.Web.Configuration ; Les utilisateurs qui connaissent le format XML de machine.config et web.config continueront d’avoir le même format et la même syntaxe dans ces fichiers, et ils pourront modifier manuellement les paramètres IIS qui suivent le même format et le même modèle ; Les utilisateurs qui connaissent les noms de propriétés de métabase IIS trouvent les mêmes noms pour les propriétés dans les nouveaux fichiers de configuration IIS 7.0 et versions ultérieures.

Nettoyer le schéma

Voici un exemple qui illustre le schéma de configuration.

Il montre comment les paramètres d’authentification sont organisés dans IIS 6, et dans IIS 7.0 et versions ultérieures.

Remarque

Les lecteurs qui ne connaissent pas les concepts IIS 6.0 peuvent simplement ignorer la comparaison avec IIS 6.0 et lire simplement les concepts et avantages IIS 7.0 et versions ultérieures.

Nous allons d’abord comparer la façon dont la configuration est conservée dans le fichier, puis nous examinerons la définition du schéma.

Dans le fichier de configuration lui-même :

//
// Snippet from IIS 6.0 Metabase.xml
//
<IIsWebService    Location ="/LM/W3SVC"
      ... many lines here ...
    AuthFlags="AuthAnonymous"
      ... many lines here ...
    >
</IIsWebService>
<IIsWebDirectory    Location ="/LM/W3SVC/1/ROOT/aspnet_webadmin/2_0_41016"
    AuthFlags="AuthAnonymous | AuthNTLM"
    >
</IIsWebDirectory>
<IIsWebVirtualDir    Location ="/LM/W3SVC/Info/Templates/Public Web Site/Root"
        AuthFlags="AuthAnonymous"
    >
</IIsWebVirtualDir>

//
// Snippet from IIS 7.0 applicationHost.config
//
<anonymousAuthentication enabled="true"  userName="…"  password="…" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<windowsAuthentication enabled="true" >
    <providers>
        <add value="Negotiate" />
        <add value="NTLM" />
    </providers>
</windowsAuthentication>

Points clés à retenir :

IIS 6.0 utilise une liste de propriétés très longue, « plate ». Il n’existe aucune hiérarchie ni regroupement de propriétés. Il est difficile de rechercher des paramètres de configuration parmi des centaines de paramètres dans la même liste. IIS 7.0 et les versions ultérieures utilisent une hiérarchie de sections et de groupes de sections, ainsi que des sous-éléments dans les sections. Il est facile de rechercher les paramètres d’authentification, en les recherchant dans le groupe de sections d’authentification ou dans une section d’authentification spécifique.
IIS 6.0 utilise des indicateurs pour définir des schémas d’authentification. IIS 7.0 et les versions ultérieures utilisent une section par schéma d’authentification, avec enabled="true|false » sur chacun d’eux. Les paramètres supplémentaires qui sont pertinents uniquement pour certains schémas d’authentification peuvent être définis uniquement dans les sections pertinentes (par exemple, le nom d’utilisateur et le mot de passe ne peuvent être définis que pour l’authentification anonyme).
IIS 6.0 utilise des chemins d’accès à l’intérieur du fichier Metabase pour spécifier le niveau de configuration (service, répertoire virtuel, répertoire physique). La configuration de l’ensemble du serveur se trouve dans un seul fichier. IIS 7.0 et les versions ultérieures utilisent un fichier par défaut, mais les utilisateurs peuvent tirer parti des fichiers web.config distribués dans les répertoires de contenu, qui spécifient les paramètres de configuration de leur étendue.
IIS 6.0 utilise des noms de propriétés longs dans une tentative d’auto-description des paramètres de configuration. Cela tente d’améliorer la lisibilité du fichier et d’aider l’utilisateur à comprendre ce que fait la propriété. IIS 7.0 et les versions ultérieures utilisent des noms courts, mais ils sont toujours dans le contexte d’une section spécifique, ou même sous-élément avec dans la section.
IIS 6.0 utilise multi-sz (éléments délimités par des virgules dans une propriété de chaîne) et des indicateurs pour gérer plusieurs valeurs d’élément, telles que NTAuthenticationProviders. IIS 7.0 et les versions ultérieures utilisent des regroupements, avec une syntaxe simple d’ajouter/supprimer/effacer, exactement comme la configuration du .NET Framework. Cela permet aux niveaux inférieurs de la hiérarchie d’ajouter (ou de supprimer) uniquement l’élément dont ils ont besoin, au lieu de dupliquer les données entières avec (ou sans) l’élément dit. Il offre également une meilleure lisibilité du fichier (ce qui se traduit par des erreurs humaines moins importantes lors de sa modification directe).

Dans le fichier de schéma :

//
// Snippet from IIS 6.0 MBSchema.xml
//
<Property InternalName="AuthFlags" ID="6000" Type="DWORD" UserType="IIS_MD_UT_FILE" Attributes="INHERIT" >
    <Flag   InternalName="AuthAnonymous"   Value="1"   ID="6218"   />
    <Flag   InternalName="AuthBasic"             Value="2"   ID="6219"  />
    <Flag   InternalName="AuthNTLM"            Value="4"   ID="6220"  />
    <Flag   InternalName="AuthMD5"              Value="16"  ID="6221"  />
    <Flag   InternalName="AuthPassport"        Value="64"  ID="6299"  />
</Property>

//
// Snippet from IIS 7.0 IIS_Schema.xml
//
<sectionSchema name="system.webServer/security/authentication/basicAuthentication">
  <attribute name="enabled" type="bool" defaultValue="false" />
  <attribute name="realm" type="string" />
  <attribute name="defaultLogonDomain" type="string" />
  <attribute name="logonMethod" type="enum" defaultValue="ClearText">
    <enum name="Interactive" value="0" />
    <enum name="Batch" value="1" />
    <enum name="Network" value="2" />
    <enum name="ClearText" value="3" />
  </attribute>
</sectionSchema>

Points clés à retenir :

IIS 6.0 utilise des IDs (nombres) pour identifier les paramètres. IIS 7.0 et les versions ultérieures utilisent des chaînes conviviales pour nommer les paramètres.
IIS 6.0 utilise des concepts non intuitifs tels que UserType et la terminologie telles que InternalName. IIS 7.0 et les versions ultérieures utilisent des noms conviviaux qui sont pertinents pour les lecteurs humains, et non seulement les applications.

Hiérarchie des fichiers de configuration

L’état « maître » de la configuration est toujours les fichiers de configuration (contrairement à IIS 6.0, où il s’agissait de la base de données de configuration en mémoire, qui a été vidée régulièrement sur le disque).

Au niveau racine (ou global), il existe deux fichiers distincts :

system32\inetsrv\config\applicationHost.config : contient les valeurs par défaut globales pour les paramètres de serveur web (IIS).
\windows\microsoft.net\framework\v2.0.50727\config\machine.config : contient les valeurs par défaut globales pour les paramètres du .NET Framework, y compris certains des ASP.NET (le reste d’entre eux se trouvent dans le fichier web.config dans le même dossier, ce qui est parfois appelé le fichier web.config racine)

La raison pour laquelle il existe encore deux fichiers distincts est parce que les deux technologies sont différentes (selon la planification et les produits). IIS fait partie de Windows et du .NET Framework peut être version indépendante, dans le cadre des versions de Visual Studio.

Dans les répertoires de contenu web, il peut y avoir des fichiers web.config facultatifs qui contrôlent le comportement de leur niveau de hiérarchie et vers le bas. Ils peuvent être locaux ou distants (si le répertoire de contenu se trouve sur un partage UNC, par exemple). Ils peuvent contenir IIS, ASP.NET ou tout autre paramètre de configuration du .NET Framework qui peut être spécifié à leur niveau. Par défaut, il n’existe aucun fichier web.config.

En termes de hiérarchie d’héritage, le fichier racine est machine.config, puis web.config au même répertoire (appelé racine web.config), puis applicationHost.config, puis les fichiers web.config facultatifs le long de l’espace de noms.

La configuration comprennent les fichiers

Dans certains cas, il est utile que le fichier web.config inclue un autre fichier .config. Pour ce faire, utilisez l’attribut configSource. Actuellement, il est limité à pointer vers des chemins physiques relatifs dans les sous-répertoires, pour des raisons de sécurité (c’est-à-dire le fichier A ne peut inclure que le fichier B si B se trouve dans le sous-répertoire physique d’A). Voici un exemple de base qui montre comment utiliser configSource :

<!-- in inetsrv\applicationHost.config -->
<configuration>
  <system.webServer>
  
    <!-- mimemaps moved by the customer to a different file -->
    <!-- so that this file is shorter and more readable -->
    <staticContent configSource="staticContent.config"/>
  
    <!-- the rest of system.webServer sections are here… -->
  </system.webServer>
</configuration>
  
<!-- in inetsrv\staticContent.config -->
<configuration>
  <system.webServer>
    <staticContent>
      <!-- all the mimemap definitions are here -->
      <mimeMap ….. />
      <mimeMap ….. />
      <mimeMap ….. />
    </staticContent>
  </system.webServer>
</configuration>

Dans cet exemple, le client souhaitait déplacer le contenu de la section staticContent vers un fichier distinct afin d’avoir un fichier plus court, plus lisible, applicationHost.config.

Notez que lorsque les paramètres de configuration changent dans un fichier .config, le serveur récupère automatiquement les modifications et agit dessus. Le client ne doit pas s’inquiéter du recyclage des applications ou des pools d’applications ou du serveur entier (le serveur lui-même peut recycler les pools d’applications, par exemple, en fonction des paramètres de configuration modifiés).

Paramètres de l'organisation

Dans un fichier de configuration (par exemple, pour un niveau donné de la hiérarchie), les paramètres sont organisés de manière structurée, et non en tant que liste plate. L’unité de base du déploiement, de l’inscription et de l’extensibilité est la section de configuration. Une section est contenue dans un groupe de sections, qui peut à son tour être contenue dans un groupe de sections parent. Les sections elles-mêmes ne sont pas imbriquées. Les groupes de sections sont.

Voici un exemple d’applicationHost.config :

<!-- section group for web server configuration -->
<system.webServer>
  
  <!-- section group for web server security configuration -->
  <security>
    <!-- section group for web server authentication configuration -->
    <authentication>
  
      <!-- three sections for authentication -->
  
      <basicAuthentcation ... />
      <windowsAutnentication ... />
      <anonymousAuthentication ... />
    </authentication>
  </security>
</system.webServer>

Les paramètres de configuration appartiennent toujours à une section spécifique.

Les groupes de sections existent uniquement pour une meilleure structure ; ils n’ont pas de paramètres directement dans eux, seules les sections.

Dans une section, la structure est la suivante :

Élément de configuration : contient les paramètres de configuration et potentiellement d’autres éléments de configuration. Représenté en tant qu’élément XML. Les sections sont également des éléments.
Collection de configuration : cas privé d’élément de configuration, qui contient une liste d’éléments de configuration, sous la forme d’ajouter/supprimer/effacer (qui sont appelés directives de collection). Représenté en tant qu’élément XML avec <ajout>, <suppression et suppression>< de >sous-éléments.
Propriété de configuration : il s’agit d’un paramètre de configuration [feuille]. Représenté en tant qu’attribut XML.

Voici un exemple d’applicationHost.config :

<!-- "windowsAuthentcation" is a section which is an element -->
<!-- "enabled" is a property -->
<windowsAuthentication enabled="true">
  
  <!-- "providers" is a collection which is an element -->
  <providers>
  
    <!-- the collection contains two elements -->
    <!-- "add" is the collection directive; "value" is the property -->
    <add value="Negotiate"/>
    <add value=""NTLM/>
  </providers>
</windowsAuthentication>

Par défaut, applicationHost.config contient deux groupes de sections principaux : system.applicationHost et system.webServer. Il contient également une section appelée <configSections>, qui est un peu spéciale dans le fait qu’elle est utilisée en interne par le système de configuration pour inscrire toutes les autres sections.

Par défaut, machine.config contient plusieurs groupes de sections. Les paramètres ASP.NET se trouvent dans le groupe de sections system.web.

Balises d’emplacement vs. Fichiers de configuration

Dans de nombreux cas, il est souhaitable d’éviter les fichiers web.config dans les répertoires de contenu, mais ils ont toujours une configuration par URL qui remplace les valeurs par défaut globales. Par exemple : l’administrateur souhaite spécifier qu’un site spécifique doit utiliser un schéma d’authentification, et les administrateurs de site (et les développeurs d’applications sur ce site) ne doivent pas être en mesure de le désactiver.

Pour ce faire, le moyen le plus simple consiste à utiliser des balises d’emplacement. Il s’agit d’un mécanisme permettant de spécifier la configuration d’un chemin spécifique, sans avoir de web.config dans le dossier mappé au chemin virtuel.

Cet exemple montre comment une balise d’emplacement est utilisée dans applicationHost.config :

<!-- the following will take effect on MyAdminSite -->
<location path="MyAdminSite">
  <system.webServer>
    <security>
      <authentication>
        <basicAuthentication enabled="false"/>
        <windowsAuthentication enabled="true"/>
        <anonymousAuthentication enabled="false"/>
      </authentication>
    </security>
  </system.webServer>
</location>

Les balises d’emplacement peuvent être utilisées pour spécifier la configuration du niveau global (path="."), pour un site ou pour un chemin spécifique à l’intérieur d’un site. Il peut y avoir plusieurs balises d’emplacement dans un fichier. Les balises d’emplacement peuvent se trouver dans n’importe quel fichier .config, pas seulement applicationHost.config ou machine.config.

Les balises d’emplacement peuvent également être utilisées pour verrouiller et déverrouiller des sections. Pour plus d’informations sur ce problème, consultez le labo de verrouillage de configuration.

Dans certains cas, il n’existe aucune alternative à l’utilisation des balises d’emplacement :

Deux chemins virtuels ou plus mappés au même dossier physique. Évidemment, si les deux chemins virtuels ont une configuration différente, il ne peut pas être spécifié dans un fichier web.config, car il est partagé.
Configuration spécifique au fichier. Il n’existe aucun fichier web.config pour les fichiers ; uniquement pour l’ensemble du dossier.

Résumé

Ce document a fourni une vue d’ensemble initiale, générale et initiale du système de configuration dans IIS 7.0 et versions ultérieures. Il a mis en évidence le format de schéma propre er ; la nature distribuée du système de configuration et la façon dont il permet la délégation des paramètres de configuration au propriétaire du site ou au développeur d’applications ; l’organisation structurée des paramètres dans les fichiers de configuration ; et l’intégration entre IIS et ASP.NET systèmes de configuration.

Pour plus d’informations, il est recommandé de passer en revue le reste des documents de configuration, et en particulier, le document Intrinsèques de configuration, qui passe en revue plus de détails de bas niveau sur le système, y compris sa conception et son architecture.

Share via