Freigeben über

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

  • Artikel

von Tobin Titus

Abstract

Das Konfigurationssystem in IIS 7 und höher basiert auf verteilten Klartext-XML-Dateien, welche 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. an den Websiteadministrator oder Anwendungsentwickler. Sichere Standardeinstellungen und sofort einsatzbereite Sperrmodi beschränken schreibgeschützten Zugriff auf Konfigurationseinstellungen nur für den Computeradministrator. Komplexe und präzise Sperrfunktionen ermöglichen jedoch eine sichere Entsperrung und Delegierung der Verwaltung bestimmter Konfigurationseinstellungen für mehr Benutzer, für den Umfang des Webnamespaces. Das System ist rückwä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.

Einführung

Das Konfigurationssystem in IIS basiert auf verteilten Klartext-XML-Dateien, welche 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. an den Websiteadministrator oder Anwendungsentwickler. Sichere Standardeinstellungen und sofort einsatzbereite Sperrmodi beschränken schreibgeschützten Zugriff auf Konfigurationseinstellungen nur für den Computeradministrator. Komplexe und präzise Sperrfunktionen ermöglichen jedoch eine sichere Entsperrung und Delegierung der Verwaltung bestimmter Konfigurationseinstellungen für mehr Benutzer, für den Umfang des Webnamespaces. Das System ist rückwä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:

  • Einfach: Der gesamte Zustand befindet sich in Dateien. Es wird kein proprietärer Speicher verwendet. Es gibt 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: Die Konfiguration kann zusammen mit Webinhalten kopiert werden. Die optionale delegierte Verwaltung beseitigt die Einbindung des Computeradministrators in jede Konfigurationsänderung. Die Vereinheitlichung von Konfigurationseinstellungen und -modellen in IIS, ASP.NET und dem Rest der Webserverplattform bietet eine zentrale Anlaufstelle für die Verwaltung des Servers mit denselben Tools und APIs (z. B. können Web.config-Dateien sowohl IIS- als auch ASP.NET-Einstellungen enthalten, und es gibt einen Ort, um Features wie Authentifizierung, Autorisierung und 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, auf die nur der Computeradministrator Zugriff hat. 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, werden sie automatisch auf dem Datenträger verschlüsselt. Die Konfiguration pro Anwendung kann in einer dedizierten Datei (durch Dateisystem-ACL geschützt) in eine Sandbox gebracht 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 genannt „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 unkompliziert.

  • 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 entsprechen, manuell bearbeiten. Benutzer, die mit den Namen der IIS-Metabasiseigenschaften vertraut sind, finden dieselben Namen für Eigenschaften in den neuen Konfigurationsdateien von IIS 7.0 und höher.

Sauberes Schema

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

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

Hinweis

Leser, die mit den IIS 6.0-Konzepten nicht vertraut sind, können 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 für jeden enabled= „true|false“ 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 kann in unteren Ebenen der Hierarchie einfach das benötigte Element hinzugefügt (oder entfernt) werden, anstatt die gesamten Daten mit (oder ohne) dem genannten Element zu duplizieren. Außerdem bietet sie eine bessere Lesbarkeit der Datei (was bei der direkten Bearbeitung zu weniger menschlichen Fehlern führt).

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 verwendet benutzerfreundliche 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 Anzeigenamen, die Menschen sinnvoll erscheinen, und nicht nur Anwendungen.

Konfigurationsdateihierarchie

Der „Master“-Status für die Konfiguration ist immer die Konfigurationsdateien (im Gegensatz zu IIS 6.0, wo es die In-Memory-Konfigurationsdatenbank war, 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 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 (die restlichen befinden sich in der Web.config im selben Ordner, der manchmal als Stammweb.config bezeichnet wird)

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

In den Webinhaltsverzeichnissen können optionale Web.config-Dateien vorhanden sein, die das Verhalten für ihre Hierarchieebene und abwärts steuern. Sie können lokal oder remote 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.

In Bezug auf die Vererbungshierarchie ist die Stammdatei „machine.config“, dann „web.config“ im selben Verzeichnis (als „root web.config“ bezeichnet), dann „applicationHost.config“ und dann die optionalen „web.config“-Dateien entlang des Namespaces.

Konfiguration umfasst Dateien

In einigen Fällen ist es nützlich, dass die Datei „web.config“ eine 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.config zu haben.

Beachten Sie, dass der Server beim Ändern der Konfigurationseinstellungen in einer CONFIG-Datei 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).

Organisation 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 selbst sind nicht geschachtelt. Abschnittsgruppen sind es.

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 sind nur für eine bessere Strukturierung vorhanden. Sie beinhalten nicht direkt Einstellungen, 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.
  • Konfigurationssammlung: 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 [leaf]-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>

„applicationHost.config“ enthält standardmäßig zwei Hauptabschnittsgruppen: „system.applicationHost“ und „system.webServer“. Es enthält auch einen Abschnitt namens <configSections>, der 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“.

Ortstags 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, welche 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 es 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 eine „web.config“ im Ordner dem virtuellen Pfad zugeordnet ist.

In diesem Beispiel wird gezeigt, wie ein Location-Tag in applicationHost.config verwendet 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. Speicherorttags 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 im Konfigurationssperrlabor.

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

  • Zwei oder mehr virtuelle Pfade, die demselben physischen Ordner zugeordnet sind. Wenn die beiden virtuellen Pfade eine andere Konfiguration aufweisen, kann sie offensichtlich nicht in einer Web.config-Datei angegeben werden, da sie freigegeben ist.
  • Dateispezifische Konfiguration. Es gibt keine „web.config“-Datei für Dateien, sondern nur für den gesamten Ordner.

Zusammenfassung

Dieses Dokument beinhaltet eine anfängliche allgemeine Übersicht über das Konfigurationssystem in IIS 7.0 und höher. 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.