Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 17 Webserver (IIS)
Pfeil 17.1 Begriffsdefinitionen
Pfeil 17.1.1 Webapplikation vs. Webservice
Pfeil 17.1.2 Website vs. Webseite
Pfeil 17.2 ASP.NET
Pfeil 17.2.1 Die Entwicklungsumgebung
Pfeil 17.2.2 Clientseitig: JavaScript
Pfeil 17.2.3 Die web.config-Datei
Pfeil 17.2.4 Kompilierung und Vorkompilierung
Pfeil 17.2.5 Sicherheit und ASP.NET
Pfeil 17.3 Installation
Pfeil 17.4 Kurzer Überblick über die Architektur des Webservers
Pfeil 17.4.1 Architektur
Pfeil 17.4.2 Anforderungsverarbeitung
Pfeil 17.4.3 Anforderungsverarbeitung im Anwendungspool
Pfeil 17.4.4 Die »Modulbauweise«
Pfeil 17.5 Webserver, Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools
Pfeil 17.5.1 Die Zusammenhänge
Pfeil 17.5.2 Webserver
Pfeil 17.5.3 Anwendungspool
Pfeil 17.5.4 Website
Pfeil 17.5.5 Anwendungen
Pfeil 17.5.6 Virtuelles Verzeichnis
Pfeil 17.6 Authentifizierung
Pfeil 17.6.1 Anonyme Authentifizierung
Pfeil 17.6.2 Standardauthentifizierung
Pfeil 17.6.3 Digestauthentifizierung
Pfeil 17.6.4 Windows-Authentifizierung
Pfeil 17.6.5 Authentifizierungsdelegierung
Pfeil 17.6.6 Webanwendungen und Kerberos
Pfeil 17.6.7 Delegierung, eingeschränke Delegierung und Protokollübergang
Pfeil 17.6.8 Formularauthentifizierung
Pfeil 17.7 Autorisierung
Pfeil 17.7.1 NTFS-Berechtigungen
Pfeil 17.7.2 URL-Autorisierung
Pfeil 17.8 Sonstiges zum Thema »Sicherheit«
Pfeil 17.8.1 SSL-Verschlüsselung
Pfeil 17.8.2 .NET-Vertrauensebenen
Pfeil 17.8.3 IP- und Domäneneinschränkungen
Pfeil 17.9 Sitzungszustand & Co.
Pfeil 17.10 Load Balancing und Redundanz
Pfeil 17.10.1 Verwendung von Microsoft NLB
Pfeil 17.10.2 Remoteanforderungen
Pfeil 17.10.3 Freigegebene Konfiguration
Pfeil 17.10.4 Sitzungsstatus
Pfeil 17.10.5 Datenbankserver & Co.
Pfeil 17.11 Administration
Pfeil 17.11.1 Remote-Administration
Pfeil 17.11.2 Remote-Administration für Nicht-Server-Administratoren und IIS-Benutzer
Pfeil 17.11.3 Delegierung von Features
Pfeil 17.11.4 Protokollierung
Pfeil 17.12 Der Best Practice Analyzer (BPA)
Pfeil 17.13 IIS-Schlussbemerkung

Rheinwerk Computing - Zum Seitenanfang

17.4 Kurzer Überblick über die Architektur des WebserversZur nächsten Überschrift

Über die Architektur von komplexen Serversystemen kann man natürlich viele Seiten schreiben. Das möchte ich hier bewusst nicht tun, es gibt aber einige Fakten, die Sie einfach über den IIS wissen sollten. Weiterhin gibt es auch für diejenigen, die sich bereits mehr oder weniger intensiv mit dem Vorgänger-IIS beschäftigt haben, das ein oder andere Neue zu entdecken: Oder wissen Sie aus dem Stand, was der Windows-Prozessaktivierungsdienst tut?


Rheinwerk Computing - Zum Seitenanfang

17.4.1 Architektur Zur nächsten ÜberschriftZur vorigen Überschrift

In Abbildung 17.18 ist die Architektur des Internet Information Servers zu sehen:

  • http.sys ist der im Kernelmodus ausgeführte Protokolllistener. Sämtliche HTTP-Anforderungen gehen hier ein. Dies gilt übrigens auch für HTTPS-Anforderungen.
  • Der WWW-Publishing-Dienst (W3SVC) verwaltet bzw. steuert die http.sys und ist für die Leistungsüberwachung zuständig.
  • Der Windows-Prozessaktivierungsdienst (WAS) verwaltet die Arbeitsprozesse. Er startet und beendet die Anwendungspools.
  • Im Konfigurationsspeicher werden die Einstellungen sowohl für den IIS als auch für ASP.NET gespeichert. Im Gegensatz zum IIS6 und dessen Metabase gibt es nicht eine zentrale Konfigurationsdatenbank, sondern es existiert eine Hierarchie aus verteilten XML-Dateien.
  • Arbeitsprozess (w3wp.exe): Dieser Prozess verarbeitet die Anforderungen und generiert Antworten. Es können mehrere Arbeitsprozesse pro Anwendungspool existieren.

Abbildung

Abbildung 17.18 Architektur des IIS7/8-Webservers


Rheinwerk Computing - Zum Seitenanfang

17.4.2 Anforderungsverarbeitung Zur nächsten ÜberschriftZur vorigen Überschrift

Die Funktion der einzelnen Bausteine ist natürlich nur sehr grob umrissen worden, etwas »mehr Leben« lässt sich dem Ganzen einhauchen, wenn man das Zusammenspiel anschaut oder – etwas wissenschaftlicher – gesprochen »die Anforderungsverarbeitung analysiert«. In Abbildung 17.19 sind die einzelnen Schritte eingetragen:

  • Schritt 1: Die vom Client eingehende HTTP-Anforderung wird von http.sys entgegengenommen.
  • Im Schritt 2 gibt es nun zwei Varianten:
    • Falls http.sys über die Konfigurationsinformationen für die Webanwendung verfügt, an die die Anforderung gerichtet ist, wird die Anforderung an den entsprechenden Arbeitsprozess weitergeleitet – und gelangt somit direkt zu Schritt 7.
    • Verfügt http.sys nicht über die Konfigurationsinformationen, wird der WWW-Publishing-Dienst kontaktiert, der wiederum den Windows-Prozessaktivierungsdienst (WAS) bemüht.
  • Schritt 3: Der WAS ruft die Konfiguration aus dem Konfigurationsspeicher ab (application-host.config).
  • Schritt 4: Der WAS prüft, ob innerhalb des für die Webanwendung zuständigen Anwendungspools bereits ein Arbeitsprozess läuft. Ist dieser nicht vorhanden, wird er gestartet.
  • Schritt 5: Der WAS übergibt die Konfiguration (Anwendungspool- und Anwendungskonfiguration) an den WWW-Publishing-Dienst.
  • Schritt 6: Der WWW-Publishing-Dienst passt, aufgrund der vom WAS übergebenen Konfigurationsinformationen, die Konfiguration von http.sys an.

    Abbildung

    Abbildung 17.19 Die HTTP-Anforderungsverarbeitung

  • Schritt 7: http.sys leitet die Anforderung an den Arbeitsprozess weiter.
  • Schritt 8: Die Anforderungsverarbeitungspipeline wird von http.sys initiiert. Das Ergebnis ist eine Antwort auf die Webanforderung.
  • Schritt 9: http.sys sendet das Ergebnis an den Client.

Man kann dem IIS übrigens recht komfortabel unter die Haube schauen, zumindest ein bisschen. Im Internetinformationsdienste-Manager steht ein Dialog zur Anzeige der aktiven Arbeitsprozesse zur Verfügung (Abbildung 17.20). Es gibt sogar noch eine detaillierte Anzeigemöglichkeit: Im Kontextmenü des jeweiligen Arbeitsprozesses existiert der Menüpunkt Aktuelle Anforderungen anzeigen. Sie werden beim »Selbst-Testen« erkennen, dass für jeden Anwendungspool, in dem eine Webanwendung gestartet wurde, ein oder mehrere Arbeitsprozesse gestartet worden sind. Wenn Sie die schematische Darstellung der HTTP-Anforderungsverarbeitung in Abbildung 17.19 konsultieren, ist das auch sofort verständlich.

Abbildung

Abbildung 17.20 Laufende Arbeitsprozesse können im Internetinformationsdienste-Manager angezeigt werden.


Rheinwerk Computing - Zum Seitenanfang

17.4.3 Anforderungsverarbeitung im Anwendungspool Zur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie den Vor-Vorgänger, also IIS6 einigermaßen gut kennen, wird Ihnen in den Grundeinstellungen der Anwendungspools aufgefallen sein, dass Sie einen Verwalteten Pipelinemodus auswählen können (Abbildung 17.21). Richtig, hier geht es um die Verarbeitung von ASP.NET-Anfragen, die naturgemäß im IIS-Umfeld eine besonders wichtige Rolle spielen.

Um es gleich vorwegzunehmen: Wenn es nicht irgendwelche mehr oder weniger mysteriösen Kompatibilitätsprobleme im integrierten Modus gibt, sollten Sie diesen auswählen. Trotzdem kann es sicherlich nicht schaden, die beiden Modi ein wenig genauer anzuschauen.

Abbildung

Abbildung 17.21 Für die ASP.NET-Anforderungsverarbeitung in einem Anwendungspool können Sie zwischen zwei Pipelinemodi wählen.

Der klassische Modus

Die Vorteile des integrierten Modus lassen sich besonders einfach vermitteln, wenn man mit der Abarbeitung im klassischen Modus beginnt. Der klassische Modus ist aus Gründen der Abwärtskompatibilität vorhanden, denn es könnte durchaus ASP.NET-Anwendungen geben, die in dem modernen integrierten Modus nicht lauffähig sind.

In Abbildung 17.22 sehen Sie die (etwas verkürzte) Darstellung der Anforderungsverarbeitung im klassischen Modus. Die wesentlichen Aspekte:

  • Im Arbeitsprozess wird eine Authentifizierung durchgeführt.
  • Bei der Handlerausführung wird bestimmt, ob die Anforderung durch ASP.NET verarbeitet werden muss. Dies ist beispielsweise bei dem Aufruf von *.aspx oder *.asmx der Fall.
  • Es wird dann die ASP.NET-ISAPI-Erweiterung aufgerufen, die sich unter anderem wieder um die Authentifizierung kümmern muss.
  • Nach Abschluss der ASP.NET-Verarbeitung in der ISAPI-Erweiterung wird die Weiterverarbeitung wieder an den Arbeitsprozess zurückgereicht.

Es ergeben sich folgende Einschränkungen bzw. Nachteile:

  • Von ASP.NET-Modulen bereitgestellte Funktionen sind für Nicht-ASP.NET-Anforderungen nicht verfügbar. Ein klassisches Beispiel ist die formularbasierte Authentifizierung.
  • Es werden Verarbeitungsschritte doppelt ausgeführt. Wie Sie in Abbildung 17.22 sehen, trifft dies beispielsweise für die Authentifizierung zu.
  • Die ASP.NET-Anwendungen können keinen Einfluss auf die sonstige IIS-Anforderungsverarbeitung nehmen. Das ist bei Betrachtung der Abbildung ebenfalls völlig einleuchtend, denn die ASP.NET-Verarbeitung erfolgt außerhalb der Verarbeitung im Arbeitsprozess.
  • Etliche Einstellungen müssen sowohl für den Arbeitsprozess als auch für die ASP.NET-ISAPI-Erweiterung gespeichert werden, beispielsweise die Authentifizierung.

Abbildung

Abbildung 17.22 Die Anforderungsverarbeitung im klassischen Modus

Der integrierte Modus

Wenn Sie jetzt, mit dem soeben erworbenen Wissen über den klassischen Modus im Hinterkopf, raten müssten, was der Unterschied zwischen dem klassischen und dem integrierten Modus ist, würden Sie ohne Schwierigkeiten einen Treffer landen: Die ASP.NET-Verarbeitung ist nun nicht mehr in einer ISAPI-Erweiterung »ausgelagert«, sondern findet im Arbeitsprozess statt. Dies ist in Abbildung 17.23 zu erkennen. Die Skizze zeigt aber noch einen weiteren Aspekt:

  • Bei der klassischen Anforderungsverarbeitung stehen im Arbeitsprozess bei der Authentifizierung lediglich die Standard-, die Windows- und die anonyme Authentifizierung zur Verfügung. Die in ASP.NET enthaltene Formular-Authentifizierung ist nicht vorhanden bzw. kann erst bei der ASP.NET-Verarbeitung in der ISAPI-Erweiterung angewendet werden.
  • Die integrierte Anforderungsverarbeitung ermöglicht hingegen, dass die Formular-Authentifizierung im Rahmen der IIS-Anforderungsverarbeitung genutzt werden kann. Sie wird sozusagen gleichberechtigt mit den nativen IIS-Modulen eingesetzt.

Anmerkung

Damit die ASP.NET-Module ausgeführt werden können, muss zwingend das Modul Managed Engine auf dem IIS installiert sein. Dieses Modul ist Bestandteil des Rollendiensts .NET-Erweiterbarkeit, der zwingend bei der Installation von ASP.NET mitinstalliert wird.

Abbildung

Abbildung 17.23 Die Verarbeitungspipeline bei der integrierten Verarbeitung

Um nochmals auf die Vorteile des integrierten Modus zu sprechen zu kommen: Man kann sagen, dass die im vorherigen Abschnitt aufgeführten Nachteile des klassischen Modus allesamt behoben sind:

  • Alle Anfordungen – egal ob ASP.NET, statische Dateien, ASP oder CGI – können alle Features des IIS und der ASP.NET-Welt (»verwaltet«) nutzen.
  • Es gibt keine doppelt vorhandenen Features.
  • Die Verwaltung erfolgt an einem Ort.
  • Entwickler können den IIS mit ASP.NET-Modulen erweitern und mit diesen auch recht weitgehend in die Anforderungsverarbeitung eingreifen.

Reihenfolge der Verarbeitung

In den vorherigen Skizzen zur Anforderungsverarbeitung haben Sie gesehen, dass der Arbeitsprozess diverse Module in einer bestimmten Reihenfolge abarbeitet. Die Reihenfolge ist natürlich ganz entscheidend, denn es hätte beispielsweise wenig Sinn, zuerst die Module zur Autorisierung aufzurufen und erst danach die Authentifizierung durchzuführen: Was soll man autorisieren, wenn man gar nicht weiß, wer vor dem Browser sitzt?

Abbildung

Abbildung 17.24 In dieser Reihenfolge werden die Module in der Verarbeitungspipeline abgearbeitet. Bei Bedarf kann die Reihenfolge angepasst werden. Wenn Sie aber nicht ganz genau wissen, was Sie tun, ist das keine gute Idee!

Die Abarbeitungsreihenfolge können Sie einsehen, wenn Sie auf der Ebene des Servers den Konfigurationsdialog Module aufrufen und auf der Aktionen-Leiste (rechts) den Menüpunkt Sortierte Liste anzeigen wählen. Sie sehen dann die systemeigenen und verwalteten (d. h. ASP.NET-)Module in der Reihenfolge der Verarbeitung (Abbildung 17.24).

Es ist durchaus möglich, die Reihenfolge der Verarbeitung zu ändern – dabei sollten Sie aber ganz genau wissen, was Sie tun. Die Modifikation der Verarbeitungsreihenfolge ist insbesondere dann relevant, wenn eigene individuelle Module hinzugefügt werden.


Rheinwerk Computing - Zum Seitenanfang

17.4.4 Die »Modulbauweise« Zur vorigen Überschrift

Wenn Sie sich einige Minuten mit dem IIS7/8 beschäftigt haben, wird eines sofort klar: Es handelt sich um ein modulares System, bei dem die einzelnen Module genau den Anforderungen entsprechend hinzugefügt oder auch entfernt werden können.

Daraus ergeben sich drei Hauptvorteile, die jeder für sich und alle gemeinsam absolut signifikant sind:

  • Sicherheit: Dies ist einer der wesentlichen Aspekte, wenn nicht sogar der wesentlichste Aspekt.
    • Durch die Modulbauweise wird die Angriffsfläche signifikant verringert, denn was nicht installiert ist, kann auch nicht angegriffen werden.
    • Der Pflege- und der Wartungsaufwand werden reduziert. Dies ist auch eindeutig ein Sicherheitsthema, denn es hat sich in der Vergangenheit gezeigt, dass die angegriffenen Lücken häufig dadurch entstanden sind, dass Systeme schlecht gepflegt waren oder den Administratoren gar nicht klar war, wo es überall Pflegebedarf gibt.
    • Das vereinheitlichte Sicherheitsmodell von IIS und ASP.NET trägt ebenfalls zur Verbesserung der Situation bei.
  • Verbesserte Leistung: Je weniger Module geladen sind, desto weniger Schritte sind bei der Anforderungsverarbeitung zu durchlaufen (siehe Abbildung 17.22 und Abbildung 17.23). Weiterhin benötigen nicht geladene Module natürlich auch keinen Speicher etc.
  • Erweiterbarkeit: Verständlichweise trägt eine konsequente Modulbauweise dazu bei, dass IIS sehr weitgehend erweitert werden kann. Dies ist sowohl mit nativen, also in C++ geschriebenen Modulen, als auch mit verwalteten (d. h. .NET-)Modulen möglich.

Die Konfiguration bzw. Aktivierung der Module ist nun zwar nicht unbedingt ein Thema, das man acht Semester lang studiert haben müsste, aber ein paar Hintergründe sollte man schon parat haben. Die grundlegende Konfiguration erfolgt in der applicationHost.config-Datei, also der »Zentralkonfiguration« des IIS (Pfad: C:\Windows\System32\inetsrv\config).

  • Alle nativen (d. h. nicht auf .NET-Technologie basierenden) Module müssen im Abschnitt <globalModules> registiert werden. Dieser Abschnitt ist in Abbildung 17.25 gezeigt.
  • Weiterhin müssen auf Serverebene und/oder Anwendungsebene die nativen Module aktiviert werden. Dies geschieht dadurch, dass diese zusätzlich im Abschnitt <modules> aufgeführt werden, allerdings ohne Pfadangaben.

    Verwaltete Module (d. h. .NET-Code) können direkt im Abschnitt <modules> eingetragen werden.

  • Zu beachten ist noch der Abschnitt <handlers> (Abbildung 17.26), der sowohl in der applicationHost.config als auch auf Anwendungs- und URL-Ebene existieren kann. Dort wird festgelegt, welche Handler bei welchen Dateiextensionen und Verben (z. B. POST, GET) verwendet werden sollen.

Abbildung

Abbildung 17.25 Der Abschnitt <globalModules> der »applicationHost.config«-Datei

Ein Beispiel dafür, was auf Anwendungsebene, also in der web.config, so alles gemacht werden kann, sehen Sie auf Abbildung 17.27. Diese web.config wurde so ohne mein Zutun von Visual Studio 2012 (MVC4-Projekt) erstellt.

Abbildung

Abbildung 17.26 Der Abschnitt <handlers>

Abbildung

Abbildung 17.27 Eine von Visual Studio erzeugte »web.config«-Datei nimmt Modifikationen im Bereich der Module und Handler vor.

In dem durch die Pfeile markierten Bereich werden drei Handler entfernt und wieder hinzugefügt. Wenn Sie sich fragen, was das soll und ob Visual Studio irgendwie unter Drogen steht, ist hier die Antwort: Die Zielplattform des Projekts ist .NET Framework 4.5 gewesen. Durch das Entfernen und Wiederhinzufügen der »entscheidenden« Module und Handler wird sichergestellt, dass für diese Anwendung wirklich mit den Komponenten mit Versionsstand 4.5 gearbeitet wird. Es ist zwar auf der Abbildung nicht zu sehen, aber es wird genau diese Version referenziert.

Abbildung

Abbildung 17.28 Diese systemeigenen und verwalteten Module sind auf der Maschine installiert – das kann aber bei Ihnen durchaus anders aussehen.

Geschockt durch zu viel XML? Kein Problem, Sie können alles auch in der grafischen Oberfläche einstellen:

  • Abbildung 17.28 zeigt die systemeigenen und verwalteten Module in der Ansicht. Im Kontextmenü des Moduls gibt es jeweils minimale Konfigurationsmöglichkeiten, insbesondere beim Dateipfad (bei systemeigenen Modulen) und bei den Typen (bei verwalteten Modulen) – also nichts, an dem man etwas einstellen müsste. Der auf der Abbildung gezeigte Bildschirm entspricht übrigens dem Abschnitt <globalModules> der applicationHost.config-Datei (siehe Abbildung 17.25).
  • Der Dialog in Abbildung 17.29 zeigt die definierten Handlerzuordnungen auf Serverebene. Auch die hier gezeigten Einträge finden sich natürlich in der applicationHost.config-Datei. Der entsprechende Abschnitt heißt wenig überraschend <handlers>; in Abbildung 17.26 (oben) ist er in der Originalform zu sehen.

Abbildung

Abbildung 17.29 Die definierten Handlerzuordnungen

Die Abschnitte <handlers> und <modules> können, wie zuvor bereits erwähnt, sowohl auf Server- als auch auf Anwendungsebene definiert werden. Ein wenig weiter vorn in Abbildung 17.27 haben Sie gesehen, dass eine Anwendung mit »ihrer« web.config Handlerzuordnungen entfernen und hinzufügen kann (übrigens auch Module).



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo