Freigeben über

Erste Schritte mit der Konfiguration in IIS 7 und höher

von Tobin Titus

Zusammenfassung

Das Konfigurationssystem in IIS 7 und höher basiert auf verteilten, Klartext-, XML-Dateien, die die Konfigurationseinstellungen für die gesamte Webserverplattform enthalten, einschließlich IIS, ASP.NET und anderen Komponenten, und kann optional zusammen mit dem Webinhalt an den Inhaltsverzeichnissen festgelegt werden. Verschiedene Ebenen der Konfigurationshierarchie können vom Computeradministrator an andere Benutzer delegiert werden, z. B. der Websiteadministrator oder der Anwendungsentwickler. Sichere Standardeinstellungen und sofort einsatzbereiten Sperrmodus beschränken den Schreibzugriff auf Konfigurationseinstellungen auf den Maschinenadministrator; Komplexe und feingranulare Sperrfunktionen ermöglichen jedoch eine sichere Entsperrung und Delegierung der Verwaltung bestimmter Konfigurationseinstellungen für mehr Benutzer, innerhalb des Umfangs des Webnamensraums. Das System ist abwärtskompatibel, auf API-Ebene, mit früheren Versionen von IIS und auf XML-Ebene mit früheren Versionen von .NET Framework. Dieses Dokument bietet eine allgemeine Übersicht über das neue Konfigurationssystem.

Einleitung

Das Konfigurationssystem in IIS basiert auf verteilten, Klartext-, XML-Dateien, die die Konfigurationseinstellungen für die gesamte Webserverplattform enthalten, einschließlich IIS, ASP.NET und anderen Komponenten, und kann optional zusammen mit dem Webinhalt an den Inhaltsverzeichnissen festgelegt werden. Verschiedene Ebenen der Konfigurationshierarchie können vom Computeradministrator an andere Benutzer delegiert werden, z. B. der Websiteadministrator oder der Anwendungsentwickler. Sichere Standardeinstellungen und ein sofort einsatzbereiter Sperrmodus beschränken den Schreibzugriff auf Konfigurationseinstellungen nur auf den Computeradministrator. Komplexe und präzise Sperrfunktionen ermöglichen jedoch eine sichere Entsperrung und Delegierung der Verwaltung bestimmter Konfigurationseinstellungen auf mehr Benutzer innerhalb des Geltungsbereichs des Webnamensraums. Das System ist abwärtskompatibel, auf API-Ebene, mit früheren Versionen von IIS und auf XML-Ebene mit früheren Versionen von .NET Framework.

Das neue Konfigurationssystem ist darauf ausgelegt, dass:

  • Einfach: Der gesamte Zustand befindet sich in Dateien; Es wird kein proprietärer Speicher verwendet; Keine In-Memory-Konfigurationsdatenbank, die der echte Master des Konfigurationszustands ist (im Gegensatz zum IISADMIN-Dienst in IIS 6.0); Das Schema ist datengesteuert und ist 100% deklarativ und auffindbar.

  • Low-TCO: Konfiguration kann zusammen mit Webinhalten kopiert werden; Optionale delegierte Verwaltung beseitigt die Einbindung des Computeradministrators in jede Konfigurationsänderung; Die Vereinheitlichung von Konfigurationseinstellungen und -modellen in IIS, ASP.NET und Der rest der Webserverplattform bietet eine zentrale Anlaufstelle für die Verwaltung des Servers mit denselben Tools und APIs (z. B. web.config Dateien können sowohl IIS- als auch ASP.NET-Einstellungen enthalten, und es gibt eine zentrale Stelle, um Funktionen wie Authentifizierung, Autorisierung, benutzerdefinierte Fehler zu steuern); Sicherung, Wiederherstellung, Sicherheitsverwaltung (ACLs) basieren auf standardmäßigen Dateisystemtools und -prozessen.

  • Sicher: Wenn IIS installiert wird, befindet sich der Konfigurationsstatus in einer Datei, die nur für den Computeradministratorzugriff geschützt ist; Standardmäßig ist keine Delegierung aktiviert; Standardmäßig werden keine vertraulichen Informationen (z. B. Kennwörter) gespeichert. Wenn vertrauliche Informationen in die Konfigurationsdateien geschrieben werden müssen, wird sie automatisch auf dem Datenträger verschlüsselt. Die Konfiguration pro Anwendung kann in einer dedizierten Datei (durch Dateisystem-ACL geschützt) sandkastent und isoliert werden, sodass andere Anwendungen die Einstellungen nicht freigeben oder lesen können.

  • Erweiterbar: Das Hinzufügen zum Schema ist einfach eine Frage des Ablegens einer XML-Datei in den Schemaordner; Sie müssen keine APIs aufrufen oder Tools ausführen, um das Schema zu erweitern; Die Einstellungen sind in logischen Blöcken mit dem Namen "Sections" (genau wie in der .NET Framework-Konfiguration) angeordnet und das Hinzufügen neuer Abschnitte ist einfach (es ist nicht erforderlich, Code zu schreiben – im Gegensatz zur .NET Framework-Konfiguration); Das Lesen von benutzerdefinierten Abschnittseinstellungen aus einem Servermodul oder einer Anwendung ist einfach und einfach.

  • Kompatibel: Vorhandene IIS-Anwendungen können weiterhin Schnittstellen wie Admin Base Objects (ABO), den IIS ADSI-Anbieter und den IIS 6.0-WMI-Anbieter aufrufen; Vorhandene .NET Framework-Anwendungen können weiterhin Schnittstellen wie System.Configuration und System.Web.Configuration aufrufen; Benutzer, die mit dem XML-Format von machine.config und web.config vertraut sind, erleben weiterhin das gleiche Format und dieselbe Syntax in diesen Dateien, und sie können IIS-Einstellungen, die demselben Format und Modell folgen, manuell bearbeiten; Benutzer, die mit den NAMEN der IIS-Metabasiseigenschaft vertraut sind, finden dieselben Namen für Eigenschaften in den neuen IIS 7.0- und höher-Konfigurationsdateien.

Sauberes Schema

Hier ist ein Beispiel, das das Schema für die Konfiguration veranschaulicht.

Es zeigt, wie Authentifizierungseinstellungen in IIS 6 und in IIS 7.0 und höher organisiert sind.

Hinweis

Leser, die mit den IIS 6.0-Konzepten nicht vertraut sind, können einfach den Vergleich mit IIS 6.0 ignorieren und einfach die Konzepte und Vorteile von IIS 7.0 und höher lesen.

Zunächst vergleichen wir die Art und Weise, wie die Konfiguration in der Datei beibehalten wird, und dann sehen wir uns die Schemadefinition an.

In der Konfigurationsdatei selbst:

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

Die zentralen Thesen :

  • IIS 6.0 verwendet eine sehr lange , "flache" Liste von Eigenschaften. Es gibt keine Hierarchie oder Gruppierung von Eigenschaften. Es ist schwierig, Konfigurationseinstellungen unter Hunderten von Einstellungen in derselben Liste zu durchsuchen. IIS 7.0 und höher verwendet eine Hierarchie von Abschnitten und Abschnittsgruppen sowie Unterelemente innerhalb der Abschnitte. Es ist einfach, Authentifizierungseinstellungen nachzuschlagen, indem sie in der Authentifizierungsbereichsgruppe oder in einem bestimmten Authentifizierungsbereich suchen.
  • IIS 6.0 verwendet Flags zum Festlegen von Authentifizierungsschemas. IIS 7.0 und höher verwendet einen Abschnitt pro Authentifizierungsschema, wobei "enabled="true|false" für jeden verwendet wird. Zusätzliche Einstellungen, die nur für einige Authentifizierungsschemas relevant sind, können nur in den relevanten Abschnitten festgelegt werden (beispielsweise kann Benutzername und Kennwort nur für die anonyme Authentifizierung festgelegt werden).
  • IIS 6.0 verwendet Pfade innerhalb der Metabasisdatei, um die Konfigurationsebene (Dienst, virtuelles Verzeichnis, physisches Verzeichnis) anzugeben. Die Konfiguration für den gesamten Server befindet sich in einer Datei. IIS 7.0 und höher verwendet standardmäßig eine Datei, aber Benutzer können verteilte web.config Dateien in den Inhaltsverzeichnissen nutzen, die Konfigurationseinstellungen für ihren Bereich angeben.
  • IIS 6.0 verwendet lange Eigenschaftsnamen in einem Versuch, selbst beschreibende Konfigurationseinstellungen zu verwenden. Dies versucht, die Lesbarkeit der Datei zu verbessern und dem Benutzer zu helfen, zu verstehen, was die Eigenschaft tut. IIS 7.0 und höher verwenden Kurznamen, aber sie befinden sich immer im Kontext eines bestimmten Abschnitts oder sogar unterelements im Abschnitt.
  • IIS 6.0 verwendet multi-sz (durch Trennzeichen getrennte Elemente in einer Zeichenfolgeneigenschaft) und Flags, um mehrere Elementwerte wie NTAuthenticationProviders zu verarbeiten. IIS 7.0 und höher verwendet Sammlungen mit einfacher Add/Remove/Clear-Syntax, genau wie die .NET Framework-Konfiguration. Dadurch können die unteren Ebenen der Hierarchie nur das benötigte Element hinzufügen oder entfernen, anstatt die gesamten Daten mit oder ohne das genannte Element zu duplizieren. Außerdem bietet sie eine bessere Lesbarkeit der Datei (was sich bei der direkten Bearbeitung in weniger menschliche Fehler übersetzt).

In der Schemadatei:

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

Die zentralen Thesen :

  • IIS 6.0 verwendet IDs (Zahlen), um Einstellungen zu identifizieren. IIS 7.0 und höher verwenden anzeigefreundliche Zeichenfolgen zum Benennen von Einstellungen.
  • IIS 6.0 verwendet nicht intuitive Konzepte wie UserType und Terminologie wie InternalName. IIS 7.0 und höher verwenden benutzerfreundliche Namen, die für menschliche Leser sinnvoll sind, und nicht nur Anwendungen.

Konfigurationsdateihierarchie

Der Status "Master" für die Konfiguration ist immer die Konfigurationsdateien (im Gegensatz zu IIS 6.0, wo es sich um die In-Memory-Konfigurationsdatenbank handelte, die in regelmäßigen Abständen auf den Datenträger geleert wurde).

Auf der Stammebene (oder global) gibt es zwei separate Dateien:

  • system32\inetsrv\config\applicationHost.config: Enthält die globalen Standardwerte für die Webservereinstellungen IIS.
  • \windows\microsoft.net\framework\v2.0.50727\config\machine.config: Enthält die globalen Standardwerte für die .NET Framework-Einstellungen, einschließlich einiger der ASP.NET Einstellungen (die restlichen befinden sich im web.config im selben Ordner, der manchmal als Stamm-web.configbezeichnet wird)

Der Grund dafür, dass es noch zwei separate Dateien gibt, liegt daran, dass die beiden Technologien unterschiedlich (zeitplanweise und produktweise) versioniert sind. IIS ist Teil von Windows, und das .NET Framework kann unabhängig als Teil von Visual Studio-Versionen aktualisiert werden.

In den Webinhaltsverzeichnissen gibt es möglicherweise optionale web.config Dateien, die das Verhalten für ihre Hierarchieebene und die darunter liegenden Ebenen steuern. Sie können lokal oder entfernt sein (wenn sich das Inhaltsverzeichnis beispielsweise auf einer UNC-Freigabe befindet). Sie können IIS, ASP.NET oder andere .NET Framework-Konfigurationseinstellungen enthalten, die auf ihrer Ebene angegeben werden können. Standardmäßig sind keine web.config Dateien vorhanden.

Im Hinblick auf die Vererbungshierarchie wird die Stammdatei machine.config, dann web.config im selben Verzeichnis (als Stamm-web.configbezeichnet), dann applicationHost.configund dann die optionalen web.config Dateien entlang des Namespaces.

Konfiguration umfasst Dateien

In einigen Fällen ist es nützlich, dass die web.config Datei einige andere .config Datei enthält. Dies kann mithilfe des configSource-Attributs erfolgen. Derzeit ist sie aus Sicherheitsgründen auf relative physische Pfade in Unterverzeichnissen beschränkt (d. h. Datei A kann Datei B nur enthalten, wenn B sich in einem physischen Unterverzeichnis von A befindet). Hier ist ein einfaches Beispiel, das zeigt, wie ConfigSource verwendet wird:

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

In diesem Beispiel wollte der Kunde den Inhalt des staticContent-Abschnitts in eine separate Datei verschieben, um eine kürzere, besser lesbare applicationHost.configzu haben.

Beachten Sie, dass beim Ändern von Konfigurationseinstellungen in einer .config Datei der Server die Änderungen automatisch übernimmt und darauf reagiert. Der Kunde sollte sich nicht um das Recycling von Anwendungen oder Anwendungspools oder den gesamten Server kümmern (der Server selbst kann Anwendungspools wiederverwenden, z. B. abhängig von den geänderten Konfigurationseinstellungen).

Verwaltung der Einstellungen

Innerhalb einer Konfigurationsdatei (d. h. für eine bestimmte Hierarchieebene) werden die Einstellungen strukturiert und nicht als flache Liste organisiert. Die Grundlegende Einheit für Bereitstellung, Registrierung und Erweiterbarkeit ist der Konfigurationsabschnitt. Ein Abschnitt ist in einer Abschnittsgruppe enthalten, die wiederum in einer übergeordneten Abschnittsgruppe enthalten sein kann. Abschnitte sind nicht ineinander verschachtelt. Abschnittsgruppen sind.

Hier ist ein Beispiel aus 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>

Konfigurationseinstellungen gehören immer zu einem bestimmten Abschnitt.

Abschnittsgruppen existieren ausschließlich zur besseren Strukturierung; sie enthalten keine Einstellungen, sondern nur Abschnitte.

Innerhalb eines Abschnitts lautet die Struktur wie folgt:

  • Konfigurationselement: Enthält Konfigurationseinstellungen und potenziell andere Konfigurationselemente. Dargestellt als XML-Element. Abschnitte sind auch Elemente.
  • Konfigurationsauflistung: Ein privater Fall des Konfigurationselements, das eine Liste von Konfigurationselementen enthält, in Form von Add/Remove/Clear (die als Sammlungsdirektiven bezeichnet werden). Dargestellt als XML-Element mit <Hinzufügen>, <Entfernen, <Löschen>> von Unterelementen.
  • Konfigurationseigenschaft: Dies ist eine [blatt]-Konfigurationseinstellung. Dargestellt als XML-Attribut.

Hier ist ein Beispiel aus 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>

Standardmäßig enthält applicationHost.config zwei Hauptabschnittsgruppen: system.applicationHost und system.webServer. Es enthält auch einen Abschnitt namens <configSections>, der etwas speziell dafür ist, dass er intern vom Konfigurationssystem verwendet wird, um alle anderen Abschnitte zu registrieren.

Standardmäßig enthält machine.config mehrere Abschnittsgruppen. Die ASP.NET Einstellungen befinden sich in der Gruppe "system.web section".

Ort-Tags vs. Konfigurationsdateien

In vielen Fällen ist es erwünscht, web.config Dateien in den Inhaltsverzeichnissen zu vermeiden, aber dennoch über eine URL-Konfiguration verfügen, die die globalen Standardwerte außer Kraft setzt. Beispielsweise möchte der Administrator angeben, dass eine bestimmte Website ein Authentifizierungsschema verwenden muss, und die Websiteadministratoren (und Anwendungsentwickler auf dieser Website) dürfen sie nicht deaktivieren.

Die einfachste Möglichkeit, dies zu erreichen, ist die Verwendung von Positionstags. Dies ist ein Mechanismus zum Angeben der Konfiguration für einen bestimmten Pfad, ohne dass ein web.config im Ordner dem virtuellen Pfad zugeordnet ist.

In diesem Beispiel wird gezeigt, wie ein Location-Tag in applicationHost.configverwendet wird:

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

Ortstags können verwendet werden, um die Konfiguration für die globale Ebene (path="."), für einen Standort oder für einen bestimmten Pfad innerhalb eines Standorts anzugeben. Es können mehrere Speicherorttags in einer Datei vorhanden sein. Ortstags können sich in einer beliebigen .config Datei befinden, nicht nur applicationHost.config oder machine.config.

Positionstags können auch zum Sperren und Entsperren von Abschnitten verwendet werden. Weitere Details hierzu finden Sie im Konfigurationssperr-Workshop.

In einigen Fällen gibt es keine Alternative zur Verwendung von Standorttags:

  • Zwei oder mehr virtuelle Pfade, die demselben physischen Ordner zugeordnet sind. Offensichtlich kann die unterschiedliche Konfiguration der beiden virtuellen Pfade in einer web.config-Datei nicht angegeben werden, da diese gemeinsam genutzt wird.
  • Dateispezifische Konfiguration. Es gibt keine web.config Datei für Dateien; nur für den gesamten Ordner.

Zusammenfassung

Dieses Dokument hat eine anfängliche allgemeine Übersicht über das Konfigurationssystem in IIS 7.0 und höher bereitgestellt. Es hat das übersichtlichere Schemaformat hervorgehoben; die verteilte Art des Konfigurationssystems und wie sie die Delegierung von Konfigurationseinstellungen an den Websitebesitzer oder Anwendungsentwickler ermöglicht; die strukturierte Organisation von Einstellungen in Konfigurationsdateien; und die Integration zwischen IIS und ASP.NET Konfigurationssystemen.

Für weitere Informationen empfiehlt es sich, die restlichen Konfigurationsdokumente und insbesondere das Systeminterne Konfigurationsdokument zu überprüfen, das ausführlichere Details zum System enthält, einschließlich des Designs und der Architektur.