Verwenden von Sperren in der IIS 7.0-Konfiguration

  • Artikel

von Saad Ladki

Abstract

In diesem Dokument wird erläutert, wie Sie die Konfiguration auf dem Server sperren und entsperren. Sie erfahren, welche Einstellungen die Konfigurationsdateien auf Anwendungsebene außer Kraft setzen können und wie Sie das Element <location> verwenden, um ganze Abschnitte zu sperren.

Sie werden in Abschnitten mit detaillierterer Sperrung von Konfigurationseinstellungen experimentieren, z. B.:

  • Sperren bestimmter Elemente und Attribute
  • Sperren aller Elemente mit Ausnahme bestimmter Elemente oder Attribute
  • Sperren bestimmter Sammlungsanweisungen wie z. B. der Anweisungen <add>, <remove> und <clear>
  • Sperren bestimmter Elemente in Sammlungen

In diesem Dokument erfahren Sie, wie Sie verschiedene Features zur Konfigurationssperrung verwalten können, indem Sie XML-Elemente direkt in Konfigurationsdateien bearbeiten (die befehlsorientierte Benutzerschnittstelle zum Ausführen dieser Aufgaben folgt der XML-Struktur sehr genau).

Dieses Dokument konzentriert sich absichtlich nur auf die Bearbeitung von XML-Elementen in den Konfigurationsdateien, anstatt Möglichkeiten zum Ausführen derselben Aufgaben mithilfe der Verwaltungs-API, Skripts oder der Benutzeroberfläche (UI) zu zeigen.

Einführung

IIS 7.0 und höher ermöglichen das Sperren und Entsperren von Konfigurationseinstellungen in verschiedenen Ebenen und Umfängen. Eine Konfiguration zu sperren, bedeutet, dass sie nicht auf niedrigeren Ebenen in der Hierarchie überschrieben (oder überhaupt festgelegt) werden kann. Eine Konfiguration kann nur auf der Ebene entsperrt werden, auf der sie gesperrt wurde. Dies ist beispielsweise hilfreich, wenn Sie unterschiedliche Konfigurationen für verschiedene Sites oder Pfade erstellen, und nur einige Sites und Pfade diese außer Kraft setzen können sollen. Sie können auf Abschnittsebene oder bestimmte Elemente, Attribute, Sammlungselemente und Sammlungsanweisungen in Abschnitten sperren.

Aufgabe 1: Sperren eines Abschnitts mithilfe eines <location>-Tags

In dieser Aufgabe erfahren Sie, wie Sie mit dem <location>-Tag ganze Konfigurationsabschnitte auf globaler Ebene sperren (oder entsperren), sodass sie nicht auf Anwendungsebenen der Konfigurationshierarchie außer Kraft gesetzt werden können.

Hinweis

Standardmäßig sind die meisten IIS-Abschnitte in „applicationHost.config“ gesperrt, und keines der .NET-Frameworks ist gesperrt (einschließlich der ASP.NET-Abschnitte in der Abschnittsgruppe <system.web> in „machine.config“ und „root web.config“).

Öffnen Sie mithilfe eines Text-Editors wie dem Windows-Editor die Datei „applicationHost.config“ am folgenden Ort:

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

Überprüfen Sie den Abschnitt <configSections> ganz oben in der Datei: Er enthält Metadaten zu den Konfigurationsabschnitten in dieser Datei, z. B. Namen von Abschnitten, die Abschnittsgruppen enthalten, und ob sie gesperrt sind.

Gesperrte Abschnitte erkennen Sie anhand des Attributs „overrideModeDefault“, für das entweder „Allow“ (Zulassen) oder „Deny“ (Verweigern) angegeben ist. Sehr wenige Abschnitte sind, wie in dieser Zeile angegeben, standardmäßig nicht gesperrt, z. B.:

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

Hier befassen wir uns mit dem Abschnitt <windowsAuthentication>. Er ist standardmäßig gesperrt.

Um den gesamten Abschnitt für alle Anwendungen auf dem Server zu entsperren, verschieben Sie dessen Inhalt von seinem aktuellen Speicherort in der Datei an das untere Ende der Datei, und packen Sie ihn in ein <location overrideMode="Allow">-Element. Denken Sie auch daran, ihn mit den Abschnittsgruppen zu umgeben: <system.webServer>, dann <security> und dann <authentication>. Das Endergebnis sollte wie folgt aussehen:

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

Der Abschnitt ist jetzt für alle Anwendungen entsperrt. Sie können für das Speicherorttag einen Pfad angeben, sodass der Abschnitt nur für diesen Pfad entsperrt wird. Der Standardpfad, wenn (wie im vorherigen Schritt) keiner angegeben ist, ist path=“.“ (bzw. path=““) was „die aktuelle Ebene“ bedeutet. In diesem Fall bedeutet die aktuelle Ebene, da dies „applicationHost.config“ ist, die globale Ebene. Sie können Speicherorttags auch an einer beliebigen Stelle in der Namespacehierarchie verwenden, z. B. in einer web.config auf vdir-Ebene, um die Konfiguration von diesem Punkt an nach unten zu sperren.

Hier ist ein Beispiel dafür, wie Sie diesen Abschnitt nur für die Site „AdminSuperTrusted“ entsperren. Das bedeutet, dass web.config-Dateien auf dieser Site die Einstellungen in diesem Abschnitt außer Kraft setzen können. Für alle anderen Sites im Feld ist sie jedoch auf globaler Ebene gesperrt und kann nicht überschrieben werden.

In diesem Beispiel müssen Sie den Inhalt des Abschnitts an seiner ursprünglichen Stelle in applicationHost.config belassen, und dann den Abschnitt im Speicherorttag mit einem bestimmten Pfad angeben:

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

Im dritten Beispiel oben wird dadurch der Abschnitt für alle Anwendungen auf allen Sites entsperrt (location path=“.“). Überprüfen Sie, ob die primäre Abschnittsgruppe für die <Authentifizierung> (die außerhalb des Elements <location> oben in der Datei) keinen Abschnitt <windowsAuthenitcation> enthält. Ein Abschnitt kann in derselben Datei nicht sowohl außerhalb eines Speicherorttags als auch innerhalb eines Tags <location path=“.“> angezeigt werden. Dies gilt als ungültige Konfiguration.

Um zu testen, ob ein Abschnitt gesperrt ist, wechseln Sie im Browser zu http://localhost/app.

Wenn der Abschnitt gesperrt ist, zeigt der Browser einen Fehler an, da die web.config-Datei auf Anwendungsebene den Abschnitt <windowsAuthentication> enthält. Dies bedeutet, dass die web.config versucht, <windowsAuthentication> für ihre Ebene außer Kraft zu setzen. Da dieser Abschnitt nun jedoch auf globaler Ebene gesperrt ist, ist die Konfiguration in der web.config-Datei ungültig.

Ändern Sie das Speicherorttag zu overrideMode=„Deny“. Dadurch wird der Abschnitt erneut gesperrt. Experimentieren Sie mit anderen Abschnitten, z. B. den ASP.NET-Abschnitten in machine.config oder root web.config. Versuchen Sie, sie auf globaler Ebene zu sperren, und setzen Sie sie auf web.config-Ebene außer Kraft.

Aufgabe 2: Sperren bestimmter Elemente und Attribute

Suchen Sie auf Grundlage der vorherigen Aufgabe den Abschnitt <windowsAuthentication> innerhalb des Tags <location>. Legen Sie für das Location-Tag Folgendes fest, um den Abschnitt zu entsperren: overrideMode=„Allow“. Bestimmte Teile des Abschnitts werden nicht gesperrt.

Legen Sie das Attribut enabled auf „true“ fest, und sperren Sie es, indem Sie lockAttributes=„enabled“ festlegen.

Dadurch wird verhindert, dass eine Konfigurationsdatei auf Anwendungsebene den Wert des Attributs enabled des Abschnitts <windowsAuthentication> ändert.

Wenn Sie andere Attribute sperren möchten, fügen Sie diese, wie im folgenden Beispiel gezeigt, durch Komma getrennt dem Wert lockAttributes hinzu:

lockAttributes="enabled,attribute1,attribute2"

Sie können mit „*“ auch alle Attribute sperren, wie in diesem Beispiel:

lockAttributes="*"

Der Abschnitt sollte nun wie folgt aussehen:

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

Versuchen Sie in der web.config-Datei Ihrer Anwendung, Einstellungen im Abschnitt <windowsAuthentication> außer Kraft zu setzen.

Fordern Sie im Browser die Seite an, um zu überprüfen, ob Sie bis auf die gesperrten Einstellungen, in diesem Fall das Attribut enabled, alle Einstellungen außer Kraft setzen können.

Hinweis

Das Attribut einfach nur in der web.config-Datei anzugeben, führt zu einem Konfigurationsfehler, auch wenn das Attribut, das Sie in der web.config-Datei festgelegt haben, denselben Wert wie in der ApplicationHost.config-Datei aufweist. Ein gesperrtes Attribut auf einen beliebigen Wert festzulegen, wird als Versuch betrachtet, das Attribut außer Kraft zu setzen und schlägt daher fehl. (Beachten Sie außerdem, dass Attribute anders als Elemente sind. In der nächsten Aufgabe sperren Sie ein Element.)

Entfernen Sie das Attribut lockAttributes.

Legen Sie lockElements=„providers“ fest, um das Element <providers> innerhalb des Abschnitts zu sperren.

Wenn Sie andere Elemente sperren müssen, können Sie sie wie folgt durch Kommas getrennt hinzufügen:

lockElements="providers,element1,element2"

Der Abschnitt sollte nun wie folgt aussehen:

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

Setzen Sie in der Web.config-Datei der Anwendung das Element <providers> außer Kraft, indem Sie es festlegen oder versuchen, zur Sammlung hinzuzufügen, daraus zu entfernen oder sie zu löschen.

Fordern Sie im Browser die Seite an, und Sie werden feststellen, dass ein Fehler angezeigt wird. Setzen Sie in der web.config-Datei andere Elemente oder Attribute wie das Attribut enabled außer Kraft. Rufen Sie die Seite auf, und Sie werden feststellen, dass kein Fehler angezeigt wird.

Entfernen Sie das Attribut lockElements.

Aufgabe 3: Sperren aller Elemente außer bestimmter Attribute

In dieser Aufgabe erfahren Sie, wie Sie mit Ausnahme von bestimmten, von Ihnen definierten Elementen und Attributen, alle Elemente oder Attribute in einem Abschnitt sperren. Dies ist in Fällen hilfreich, in denen Sie nicht sicher sind, welche Eigenschaften der Abschnitt hat oder in Zukunft haben wird, und Sie bis auf die Eigenschaften, die explizit entsperrt sein sollen, alles sperren möchten.

Suchen Sie auf Grundlage der vorherigen Aufgabe den Abschnitt <windowsAuthentication> innerhalb des Speicherorttags.

Setzen Sie die Attribute lockAllElementsExcept bzw. lockAllAttributesExcept mit Kommas als Trennzeichen auf eine Liste von Elementen oder Attributen, die gesperrt werden sollen. Der Abschnitt könnte z. B. wie folgt aussehen:

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

Oder so:

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

In diesem spezifischen Abschnitt gibt es derzeit keine anderen Attribute oder Elemente. Wenn Sie die Auswirkungen des Festlegens der Attribute lockAllElementsExcept bzw. lockAllAttributesExcept testen möchten, fügen Sie anderen Abschnitten, die einen umfangreicheren Satz von Attributen aufweisen, dieselben Attribute hinzu.

Aufgabe 4: Sperren einiger Sammlungsanweisungen

In dieser Aufgabe erfahren Sie, wie Sie die Anweisungen <add> und <remove> in einer Sammlung sperren, sodass Konfigurationsdateielemente auf Anwendungsebene hinzugefügt, aber nicht entfernt werden können.

Suchen Sie auf Grundlage der vorherigen Aufgabe den Abschnitt <windowsAuthentication> innerhalb des Speicherorttags.

Legen Sie das Attribut lockElements in der Sammlung <providers> auf remove,clear fest.

Wenn Sie fertig sind, sieht der Abschnitt wie folgt aus:

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

Erstellen Sie in der web.config-Datei der Anwendung ein Element <remove>, welches das NTLM-Element aus der Sammlung entfernt.

Wenn Sie fertig sind, sieht die web.config-Datei wie folgt aus:

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

Fordern Sie im Browser http://localhost/app an.

Aufgabe 5: Sperren bestimmter Elemente in einer Sammlung

In dieser Aufgabe erfahren Sie, wie Sie bestimmte Sammlungselemente sperren. Entwickler können der Sammlung weiterhin auf niedrigeren (Anwendungs-) Ebenen der Hierarchie Elemente hinzufügen, und weiterhin nicht gesperrte Elemente aus der Sammlung entfernen. Allerdings können Sie die Elemente, die Sie gesperrt haben, nicht entfernen. Die Sammlung kann nicht gelöscht werden, da das Löschen bedeutet, dass alle Elemente aus der Sammlung entfernt werden.

Suchen Sie auf Grundlage der vorherigen Aufgaben den Abschnitt <windowsAuthentication> innerhalb des Speicherorttags.

Legen Sie in der Sammlung <providers> im Element <add> für den NTLM-Anbieter das lockItem auf „true“ fest.

Wenn Sie fertig sind, sieht der Abschnitt wie folgt aus:

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

Erstellen Sie in der web.config-Datei der Anwendung ein Element <remove>, welches das NTLM-Element aus der Sammlung entfernt.

Wenn Sie fertig sind, sieht die web.config-Datei wie folgt aus:

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

Fordern Sie im Browser http://localhost/app an. Die Anforderung wird fehlschlagen.

Zusammenfassung

In diesem Dokument haben Sie erfahren, wie Sie Konfigurationseinstellungen sperren. Sie können einen gesamten Abschnitt sperren, indem Sie entweder ein Element <location> verwenden oder das Attribut lockItem eines Tags auf „true“ festlegen. Sie können das Sperren flexibler und präziser machen, indem Sie die Einstellungen für lockAttributes, lockElements, lockAllAttributesExcept, lockAllElementsExcept oder lockItem auf Sammlungselemente anwenden, und indem Sie die Einstellungen für lockElements auf Sammlungen anwenden, um bestimmte Sammlungsanweisungen (<add>, <remove>oder <clear>) anzugeben. Sie können auf jeder Ebene der Hierarchie sperren, nicht nur in ApplicationHost.config. Sperren sind von dieser Ebene an nach unten wirksam.