Начало работы с конфигурацией в IIS 7 и более поздних версиях

2023-07-19

Краткие сведения

Система конфигурации в IIS 7 и выше основана на распределенных, понятных, XML-файлах, которые содержат параметры конфигурации для всей платформы веб-сервера, включая IIS, ASP.NET и другие компоненты, а также могут быть установлены в каталогах содержимого вместе с веб-содержимым. Различные уровни иерархии конфигурации могут делегироваться администратором компьютера другим пользователям, таким как администратор сайта или разработчик приложения. Безопасные значения по умолчанию и блокировка по умолчанию ограничивают доступ на запись к параметрам конфигурации только администратору компьютера; однако сложные и детализированные функции блокировки позволяют безопасно разблокировать и делегирование управления определенными параметрами конфигурации для большего числа пользователей для их использования в области веб-пространства имен. Система является обратно совместимой на уровне API с предыдущими версиями IIS и на уровне XML с предыдущими версиями платформы .NET. В этом документе представлен общий обзор новой системы конфигурации.

Введение

Система конфигурации в IIS основана на распределенных, понятных текстовых, XML-файлах, которые содержат параметры конфигурации для всей платформы веб-сервера, включая IIS, ASP.NET и другие компоненты, и при необходимости могут быть установлены в каталогах содержимого вместе с веб-содержимым. Различные уровни иерархии конфигурации могут делегироваться администратором компьютера другим пользователям, таким как администратор сайта или разработчик приложения. Безопасные значения по умолчанию и изначальная блокировка ограничивают доступ на запись к параметрам конфигурации только для администратора компьютера; однако сложные и детализированные функции блокировки позволяют безопасно разблокировать и делегировать управление определенными параметрами конфигурации большему числу пользователей, в рамках их области веб-пространства имен. Система является обратно совместимой на уровне API с предыдущими версиями IIS и на уровне XML с предыдущими версиями платформы .NET.

Новая система конфигурации предназначена для того, чтобы быть:

Простой: все состояние находится в файлах; Не используется частное хранилище; Нет базы данных конфигурации в памяти, которая является реальным мастером состояния конфигурации (в отличие от службы IISADMIN в IIS 6.0); Схема управляется данными и составляет 100% декларативным и обнаруживаемым.
Низкие затраты на владение (TCO): конфигурацию можно переносить (xcopied) вместе с веб-контентом; необязательное делегированное администрирование устраняет необходимость участия администратора системы в каждом изменении конфигурации; унификация параметров конфигурации и модели для IIS, ASP.NET и всей платформы веб-сервера предоставляет централизованную систему для управления сервером с использованием одного набора инструментов и API (например, файлы web.config могут содержать настройки как IIS, так и ASP.NET, и есть одно место для управления функциями, такими как аутентификация, авторизация, пользовательские ошибки); резервное копирование, восстановление, управление безопасностью (ACL) основаны на стандартных инструментах и процессах файловой системы.
Безопасность. При установке IIS состояние конфигурации находится в одном файле, защищенном только для доступа администратора компьютера; По умолчанию делегирование не включено; Конфиденциальные данные (например, пароли) не хранятся по умолчанию; Если конфиденциальная информация должна записываться в файлы конфигурации, она автоматически шифруется на диске; Конфигурация для каждого приложения может быть песочницей и изолирована в выделенном файле (защищенном доступом ACL файловой системы), чтобы другие приложения не могли совместно использовать параметры.
Расширяемый: добавление к схеме — это просто вопрос копирования XML-файла в папку схем; для расширения схемы не требуется вызывать API или запускать средства; параметры упорядочены в логически связанных блоках, называемых "разделами" (точно так же, как в конфигурации платформы .NET), и добавление новых разделов является легким процессом (в отличие от конфигурации платформы .NET, здесь не нужно писать код). Чтение пользовательских параметров раздела из модуля сервера или приложения является простым и прямолинейным.
Совместимость: существующие приложения IIS могут продолжать вызывать интерфейсы, такие как базовые объекты администрирования (ABO), поставщик IIS ADSI и поставщик WMI IIS 6.0; Существующие приложения платформы .NET могут продолжать вызывать интерфейсы, такие как System.Configuration и System.Web.Configuration; Пользователи, знакомые с форматом XML machine.config и web.config, будут продолжать работать с тем же форматом и синтаксисом в этих файлах, а также смогут вручную изменять параметры IIS, которые соответствуют одному и тому же формату и модели; Пользователи, знакомые с именами свойств Метабазы IIS, будут находить те же имена свойств в новых файлах конфигурации IIS 7.0 и выше.

Очистка схемы

Ниже приведен пример, демонстрирующий схему конфигурации.

Здесь показано, как параметры проверки подлинности организованы в IIS 6 и в IIS 7.0 и выше.

Замечание

Читатели, которые не знакомы с концепциями IIS 6.0, могут просто игнорировать сравнение с IIS 6.0 и просто читать понятия и преимущества IIS 7.0 и выше.

Сначала мы сравним способ сохранения конфигурации в файле, а затем рассмотрим определение схемы.

В самом файле конфигурации:

//
// 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>

Ключевые моменты:

IIS 6.0 использует очень длинный список свойств. Иерархия или группирование свойств отсутствует. Трудно найти параметры конфигурации среди сотен параметров в одном списке. IIS 7.0 и более поздних версий использует иерархию разделов и групп разделов и вложенных элементов в разделах. Параметры проверки подлинности можно легко найти, выполнив поиск в группе разделов проверки подлинности или в определенном разделе проверки подлинности.
IIS 6.0 использует флаги для задания схем проверки подлинности. IIS 7.0 и выше использует секцию для каждой схемы проверки подлинности, с параметром enabled="true|false" у каждой. Дополнительные параметры, относящиеся только к некоторым схемам проверки подлинности, можно задать только в соответствующих разделах (например, имя пользователя и пароль можно задать только для анонимной проверки подлинности).
IIS 6.0 использует пути внутри файла Metabase для указания уровня конфигурации (службы, виртуального каталога, физического каталога). Конфигурация для всего сервера находится в одном файле. IIS 7.0 и более поздних версий использует один файл по умолчанию, но пользователи могут использовать распределенные web.config файлы в каталогах содержимого, которые указывают параметры конфигурации для их области.
IIS 6.0 использует длинные имена свойств в попытке самостоятельно описывать параметры конфигурации. Это пытается улучшить удобочитаемость файла и помочь пользователю понять, что делает свойство. IIS 7.0 и более поздние версии используют короткие имена, но они всегда находятся в контексте определенного раздела или даже подэлемента в этом разделе.
IIS 6.0 использует multi-sz (элементы с разделителями-запятыми в одном строковом свойстве) и флаги для обработки нескольких значений элементов, таких как NTAuthenticationProviders. IIS 7.0 и более поздних версий использует коллекции с простым синтаксисом add/remove/clear, точно так же, как конфигурация платформы .NET. Это позволяет более низким уровням иерархии добавлять (или удалять) только нужный элемент, а не дублировать все данные с указанным элементом (или без него). Он также обеспечивает большую удобочитаемость файла (что преобразуется в меньшее количество человеческих ошибок при непосредственном редактировании файла).

В файле схемы:

//
// 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>

Ключевые моменты:

IIS 6.0 использует идентификаторы (числа) для назначения параметров. IIS 7.0 и более поздние версии используют понятные строки для именования настроек.
IIS 6.0 использует неинтуитивные понятия, такие как UserType и терминология, например InternalName. IIS 7.0 и более поздних версий использует понятные имена для читателей, а не только приложений.

Иерархия файлов конфигурации

Состояние master для конфигурации всегда является файлами конфигурации (в отличие от IIS 6.0, где она была базой данных конфигурации в памяти, которая периодически сбрасывалась на диск).

На корневом (или глобальном) уровне существует два отдельных файла:

system32\inetsrv\config\applicationHost.config: содержит глобальные значения по умолчанию для параметров веб-сервера (IIS).
\windows\microsoft.net\framework\v2.0.50727\config\machine.config. Содержит глобальные значения по умолчанию для параметров платформы .NET, включая некоторые из ASP.NET (остальные из них находятся в web.config в той же папке, которая иногда называется корневой web.config)

Причина, по которой все еще существуют два отдельных файла, заключается в том, что две технологии версионируются по-разному (по графику и по продукту). IIS является частью Windows, а платформа .NET Framework может обновляться независимо, как часть выпусков Visual Studio.

В каталогах веб-содержимого могут присутствовать необязательные файлы web.config, которые управляют поведением на их уровне иерархии и ниже. Они могут быть локальными или удаленными (например, если каталог содержимого находится на общем ресурсе по UNC). Они могут содержать службы IIS, ASP.NET или любые другие параметры конфигурации платформы .NET, которые можно указать на их уровне. По умолчанию нет web.config файлов.

С точки зрения иерархии наследования, корневой файл machine.config, затем файл web.config в том же каталоге (известный как корень web.config), затем applicationHost.config, а затем необязательные файлы web.config в пространстве имен.

Включаемые в конфигурацию файлы

В некоторых случаях может потребоваться, чтобы файл web.config включал в себя другой файл .config. Это можно сделать с помощью атрибута configSource. В настоящее время это ограничивается указанием относительных физических путей в вложенных каталогах по соображениям безопасности (т. е. файл A может включать только файл B, если B находится в физическом подкаталоге A). Ниже приведен базовый пример, в который показано, как использовать 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>

В этом примере клиент хотел переместить содержимое раздела staticContent в отдельный файл, чтобы сделать его более коротким и более читаемым applicationHost.config.

Обратите внимание, что при изменении параметров конфигурации в файле .config сервер автоматически учтёт изменения и применит их. Клиент не должен беспокоиться о перезапуске приложений или пулов приложений или всего сервера (сам сервер может перезапустить пулы приложений, например в зависимости от того, какие параметры конфигурации изменились).

Организация настроек

В файле конфигурации (т. е. для заданного уровня иерархии) параметры организованы структурированным образом, а не как плоский список. Основной единицей развертывания, регистрации и расширяемости является раздел конфигурации. Раздел содержится в группе разделов, которая, в свою очередь, может содержаться в родительской группе разделов. Разделы сами по себе не имеют иерархии. Группы разделов:

Ниже приведен пример 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>

Параметры конфигурации всегда принадлежат определенному разделу.

Группы разделов существуют только для лучшего структурирования; они не имеют параметров непосредственно в них, такие параметры есть только у разделов.

В разделе структура выглядит следующим образом:

Элемент конфигурации: содержит параметры конфигурации и потенциально другие элементы конфигурации. Представлен как XML-элемент. Разделы также являются элементами.
Коллекция конфигураций: частный случай элемента конфигурации, который содержит список элементов конфигурации, в виде добавления и удаления или очистки (которые называются директивами коллекции). Представлен как XML-элемент с <добавлением>, <удалением>, <очисткой> подэлементов.
Свойство конфигурации: это параметр конфигурации [leaf]. Представляется в виде XML-атрибута.

Ниже приведен пример 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>

По умолчанию applicationHost.config содержит две основные группы разделов: system.applicationHost и system.webServer. Он также содержит раздел с именем <configSections>, который является несколько особенным в том, что он используется внутренне системой конфигурации для регистрации всех остальных разделов.

По умолчанию machine.config содержит несколько групп разделов. Параметры ASP.NET находятся в группе разделов system.web.

Теги расположения и файлы конфигурации

Во многих случаях желательно избегать web.config файлов в каталогах контента, но по-прежнему сохранять конфигурацию на уровне URL, которая переопределяет глобальные значения по умолчанию. Например, администратор хочет указать, что определенный сайт должен использовать определенную схему проверки подлинности, а администраторы сайта (и разработчики приложений на этом сайте) не должны иметь возможности отключить его.

Самый простой способ достичь этого заключается в использовании тегов расположения. Это механизм для указания конфигурации для конкретного пути без наличия web.config в папке, сопоставленной с виртуальным путем.

В этом примере показано, как тег расположения используется в 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>

Теги расположения можно использовать для указания конфигурации глобального уровня (path=".), для сайта или для определенного пути внутри сайта. В файле может быть несколько тегов расположения. Теги расположения могут находиться в любом файле .config, а не только applicationHost.config или machine.config.

Теги расположения также можно использовать для блокировки и разблокировки разделов. Более подробная информация об этом находится в лаборатории по блокировке конфигурации.

В некоторых случаях для использования тегов расположения нет альтернативы:

К одному физическому каталогу сопоставлены два или более виртуальных пути. Очевидно, что если два виртуальных пути имеют другую конфигурацию, его нельзя указать в файле web.config, так как он является общим.
Конфигурация для конкретного файла. Файла с тегом web.config для отдельных файлов не существует; он есть только для целой папки.

Сводка

В этом документе приведены начальные общие сведения о системе конфигурации в IIS 7.0 и выше. Выделен формат более чистой схемы; распределенный характер системы конфигурации и способ делегирования параметров конфигурации владельцу сайта или разработчику приложений; структурированная организация параметров в файлах конфигурации; и интеграция между службами IIS и системами конфигурации ASP.NET.

Для получения дополнительных сведений рекомендуется ознакомиться с остальными документами конфигурации и, в частности, документом "Встроенные компоненты конфигурации", который переходит к более низким уровням сведений о системе, включая его дизайн и архитектуру.