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

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 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 (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1528-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 Anwendung
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
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
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


Galileo Computing - Zum Seitenanfang

17.6 Authentifizierung Zur nächsten ÜberschriftZur vorigen Überschrift

Falls Sie den IIS nicht ausschließlich für einen Internetauftritt benutzen, bei dem alle Daten für jeden Menschen dieser Welt frei zugänglich sein sollen, ist das Thema Authentifizierung sehr interessant. Bei der Authentifizierung geht es darum, festzustellen, welcher Benutzer hinter der Tastatur des Clients sitzt, von dem die Verbindung ausgeht.

Standardmäßig ist lediglich die anonyme Authentifizierung installiert, alle anderen Authentifizierungsmethoden müssen Sie zunächst als Rollendienst installieren. In Abbildung 17.44 sehen Sie den entsprechenden Dialog des Server-Managers.

In diesem Abschnitt möchte ich Ihnen die Authentifizierungsmethoden kurz vorstellen und insbesondere auf die im Intranet-Umfeld sehr wichtige Windows-Authentifizierung eingehen – wobei wir natürlich auch mein Lieblingsthema Kerberos nicht außer Acht lassen werden.

Abbildung 17.44 Die Authentifizierungsmethoden müssen gezielt installiert werden.


Galileo Computing - Zum Seitenanfang

17.6.1 Anonyme Authentifizierung Zur nächsten ÜberschriftZur vorigen Überschrift

Anonyme Authentifizierung bedeutet zunächst, dass die Identität des Benutzers nicht festgestellt wird. Das ist so weit klar, liegt auf der Hand und ist trivial. Bei der internen Verarbeitung im IIS ist es aber nicht ganz so simpel, denn auch wenn der Benutzer anonym bleibt, wird das Sicherheitssystem des Windows Server 2008-Betriebssystems ja nicht komplett außer Kraft gesetzt. Die Frage bei der anonymen Authentifizierung ist also in erster Linie, wie man damit »nach innen« umgeht.

Identität bei anonymer Authentifizierung mit ASP.NET

Vielleicht haben Sie sich schon mit dem Thema beschäftigt und erinnern sich an die Identität IUSR_servername – schon gar nicht schlecht, aber das hilft Ihnen bei der Beschäftigung mit dem IIS7 nicht wirklich weiter:

  • An die Stelle von IUSR_servername ist das eingebaute Konto IUSR getreten. Der Vorteil ist, dass es auf allen Windows Server 2008-Maschinen dieser Welt dieselbe SID hat. Beim Kopieren von Dateien zwischen Servern muss also nicht neu geACLt werden, das heißt, Sie brauchen keine Access Control List-Einträge zu ändern.
  • Wenn Sie mit ASP.NET- oder FastCGI-Anwendungen arbeiten, was auf IIS7-Maschinen durchaus häufig vorkommen wird, müssen Sie genau hingucken, denn dann stimmt die »alte Weisheit« Anonyme Authentifizierung = IUSR-Konto nur noch sehr bedingt.

Ich zeige Ihnen direkt die verwendeten Identitäten von zwei Konfigurationsvarianten der anonymen Authentifizierung für eine ASP.NET-Anwendung. Als Webapplikation dient meine kleine Kerberos-Testapplikation, die die Identität des aktuell ausgeführten Prozesses anzeigen kann.

Variante 1

In der ersten Variante ist die anonyme Authentifizierung wie folgt konfiguriert (Abbildung 17.45):

  • Als Identität des anonymen Benutzers soll das eingebaute Konto IUSR verwendet werden.
  • Der ASP.NET-Identitätswechsel ist deaktiviert.

Das vielleicht etwas überraschende Ergebnis ist in Abbildung 17.46 zu sehen: Der Prozess läuft durchaus nicht mit der IUSR-Identität, sondern mit der Identität des Anwendungspools. Weil die aufgerufene Website unter dem nicht veränderten DefaultAppPool ausgeführt wird, ist das Netzwerkdienst.

Abbildung 17.45 Der entscheidende Aspekt ist hier (neben der Verwendung des IUSR-Kontos), dass der ASP.NET-Identitätswechsel deaktiviert ist.

Abbildung 17.46 Wie man sieht, läuft die Anwendung mit der Pool-Identität.

Variante 2

Bei der zweiten Variante wird folgende Konfiguration gewählt:

  • Die Eigenschaften der anonymen Authentifizierung besagen weiterhin, dass das IUSR-Konto verwendet werden soll (siehe Abbildung 17.45).
  • Diesmal wird aber der ASP.NET-Identitätswechsel aktiviert. Als anzunehmende Identität wird Authentifizierter Benutzer gewählt (Abbildung 17.47).

Abbildung 17.47 »ASP.NET-Identitätswechsel« wird nun aktiviert. Es soll die Identität des authentifizierten Benutzers verwendet werden.

Nun erreichen Sie das erwartete Ergebnis: Der Prozess läuft mit der IUSR-Identität (Abbildung 17.48).

Abbildung 17.48 Nun wird der Prozess unter dem eingebauten IUSR-Konto ausgeführt.

Anmerkungen, Schlussfolgerungen, Hinweise

Das in den zuvor gezeigten Versuchen nachgewiesene Verhalten ist normal und von Microsoft dokumentiert. Man muss es nur wissen – wenn man mit der Identität IUSR rechnet, in Wahrheit aber der NETZWERKDIENST verwendet wird, kann einen das beim Setzen von Berechtigungen schier zur Verzweiflung treiben.

Beim Zugriff auf statische Inhalte wird bei der in Variante 1 gezeigten Konfiguration die IUSR-Identität verwendet.

Berechtigungen setzen

Die Identität zu kennen, mit der die Webanwendung läuft, macht eigentlich nur aus einem Grund Sinn, nämlich um die gewährten Berechtigungen möglichst minimal zu halten. Man spricht auch davon, nur den Mindestzugriff zu gewähren. Natürlich können sich die Konfigurationsarbeiten durchaus auch auf Datenbanken, Webdienste und dergleichen beziehen; in jedem Fall bearbeiten müssen Sie aber das Thema der NTFS-Berechtigungen. Schließlich muss jede Webanwendung Daten von der Festplatte lesen können.

Werfen wir einen Blick auf die standardmäßige NTFS-Konfiguration des Verzeichnisses c:\inetpub\wwwroot (Abbildung 17.49). Die »hohen« Berechtigungen für SYSTEM, Administratoren und die anderen hochprivilegierten Konten und Gruppen sind hier nicht weiter interessant. Das Augenmerk liegt auf den folgenden Konten:

  • Die Gruppe IIS_IUSRS ist sozusagen die Nachfolgegruppe von IIS_WPG. In IIS-WPG mussten bei den vorherigen IIS-Versionen alle Konten eingetragen werden, die als Anwendungsidentität verwendet wurden. Bei IIS7 ist das Leben ein kleines Stückchen einfacher, denn Konten, die als Anwendungspoolidentität verwendet werden, werden automatisch in IIS_IUSRS geführt, auch wenn diese dort nicht explizit eingetragen sind. Diese Gruppe und somit alle Anwendungsidentitäten haben Lese- und Ausführungsberechtigung.
  • Weiterhin ist konfiguriert, dass die Gruppe Benutzer ebenfalls Lese- und Ausführungsberechtigung hat. Das hat zur Folge, dass man in den Fällen, in denen die Anwendung unter der IUSR-Identität (oder einem anderen Konto) läuft, an die Dateien herankommt.

Abbildung 17.49 Diese Berechtigungen werden standardmäßig für »c:\inetpub\wwwroot« eingerichtet.


Galileo Computing - Zum Seitenanfang

17.6.2 Standardauthentifizierung Zur nächsten ÜberschriftZur vorigen Überschrift

Die simpelste und kompatibelste Authentifizierungsmethode ist die Standardauthentifizierung. Diese ist in RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt) definiert. Dieses Dokument hat schon ein biblisches Alter; es wurde im Juni 1999 verfasst. Sie werden in diesem Abschnitt sehen, dass die Standardauthentifizierung absolut primitiv ist, aber dafür wird sie von so ziemlich jedem Internet-Browser unterstützt.


Standardauthentifizierung

Die Standardauthentifizierung des IIS authentifiziert übrigens gegen das Active Directory bzw. die lokale Benutzerdatenbank des Servers.


Einrichten der Standardauthentifizierung

Sie können die Authentifizierung auf Ebene des Servers, der Website oder der Anwendung konfigurieren. Auf Abbildung 17.50 sehen Sie die Konfiguration der Authentifizierungsmethoden:

  • Der erste Schritt ist, die Anonyme Authentifizierung zu deaktivieren. Falls die anonyme Authentifizierung aktiv ist, wird keine andere Authentifizierungsmethode versucht.
  • Außer dem Aktivieren der Standardauthentifizierung ist noch minimale Konfiguration möglich:
    • Die Standarddomäne wird verwendet, um Benutzernamen ohne Domänenkennung einer Domäne zuzuordnen. Das heißt: Wenn sich uboddenberg anmeldet, wird bei der in der Abbildung gezeigten Einstellung ubinf.intra\uboddenberg daraus.
    • Die Einstellung Bereich ist optional. Hier kann ein DNS-Name eingetragen werden, der dem sich anmeldenden Benutzer den Gültigkeitsbereich (die Realm) zeigt, für den (bzw. die) er die Anmeldeinformationen eintragen soll. Wird hier nichts eingetragen, erscheint im Anmeldedialog der Name des aufgerufenen Servers (vergleiche Abbildung 17.52).

Abbildung 17.50 Aktivieren der Standardauthentifizierung. Gleichzeitig wird die »Anonyme Authentifizierung« deaktiviert.

Woher weiß der Browser … – Teil 1

Vielleicht stellen Sie sich die Frage, woher der Browser »weiß«, dass er Anmeldeinformationen abfragen und an die aufgerufene Website senden muss. Klar, wenn der Benutzer auf geschützte Bereiche zugreifen möchte, aber es geht auch noch ein wenig exakter.

Ich habe den Aufruf einer Website, die eine Anmeldung per Standardauthentifizierung erfordert, mit dem Netzwerkmonitor mitgeschnitten. Das Ergebnis sehen Sie in Abbildung 17.51:

  • Pakete 79–85: Hier ermittelt der Client die Netzwerkadressen. Es sind sowohl ARP- als auch DNS-Vorgänge zu sehen.
  • Pakete 86–91: Hier wird die Sitzung mit dem Server aufgebaut.
  • Paket 92: Hier stellt der Client eine HTTP-GET-Anforderung, möchte also gern, dass der Inhalt der Seite checkkerberos.aspx gesendet wird.
  • Paket 99: Das ist jetzt der entscheidende Moment: Der Server weist die Anfrage mit dem Statuscode 401 zurück. »401« bedeutet unauthorized.
  • Durch die Antwort 401 des Servers »weiß« der Webbrowser, dass er Anmeldeinformationen abfragen muss. Der Internet Explorer tut das mit dem Dialog aus Abbildung 17.52.
  • Im Netzwerkmonitor ist zu sehen, dass ich nun über 20 Sekunden gebraucht habe, um das Kennwort einzugeben (vergleiche den Time Offset zwischen Paket 101 und Paket 356). Der Browser stellt (Paket 356) den HTTP-GET-Request ein weiteres Mal.
  • … und nun ist der Server zufrieden, quittiert die Anforderung mit Statuscode 200 (d. h. OK, Paket 359) und sendet die gewünschten Informationen.

Abbildung 17.51 Der Anmeldevorgang im Netzwerkmonitor. Ein großer Nachteil ist, dass Benutzername und Kennwort im Klartext gesendet werden.

Schauen wir das Paket 356 noch ein wenig genauer an. In Abbildung 17.51 sind auch die Frame Details zu erkennen:

  • Zunächst sieht das wie eine »normale« HTTP GET-Anforderung aus, was es ja auch ist.
  • Im unteren Bereich sehen Sie den Bereich Authorization, unterhalb dessen die Anmeldeinformationen im Klartext zu sehen sind. Das Kennwort ist hier zwar hinreichend verkürzt dargestellt, im Netzwerkpaket steht es aber vollständig drin.

Das ist auch ein deutliches Manko der Standardauthentifizierung, dass jemand, der in der Lage ist, die Kommunikation abzuhören, die Anmeldeinformationen in glasklarer Darstellung erhält – wie auf der Abbildung deutlich zu sehen ist.

Diese unverschlüsselte Übertragung lässt sich aber verhindern, wenn die HTTP-Kommunikation mit SSL-Verschlüsselung erfolgt (https://). Mit der Verschlüsselung auf HTTP-Ebene wird das wesentliche Manko der Standardauthentifizierung behoben, so dass diese Methode durchaus mit gutem Gewissen verwendet werden kann. Nach der Betrachtung von Abbildung 17.51 werden Sie aber bestimmt niemals mehr die Standardauthentifizierung ohne SSL-Verschlüsselung einrichten, oder?

Abbildung 17.52 Der Browser fragt die Anmeldeinformationen ab.

Resultat der Anmeldung

Interessant ist natürlich, mit welcher Identität die Webanwendung nach der Durchführung einer Standardauthentifizierung betrieben wird. Ist die Konfiguration so wie in Abbildung 17.50 vorgenommen worden, also mit deaktiviertem ASP.NET-Identitätswechsel, wird das Ergebnis so wie in Abbildung 17.53 gezeigt sein: Die Webanwendung wird mit der Identität des Anwendungspools ausgeführt.

Interessant ist das Verhalten, wenn auch der ASP.NET-Identitätswechsel aktiviert ist und als Identität diejenige des authentifizierten Benutzers konfiguriert wird (Abbildung 17.54). Das Ergebnis sehen Sie in Abbildung 17.55: Wie erwartet entspricht die angezeigte Identität dem angemeldeten Benutzer. Der eigentlich interessante Punkt ist das verwendete Authentifizierungsprotokoll, zumal wenn man weiß, dass ich mir zum Zeitpunkt des Screenshots keinerlei Gedanken über Service Principal Name & Co. gemacht habe und es durchaus etwas »kniffelig« sein kann, Kerberos in einer Webumgebung zum Laufen zu bringen (siehe Abschnitte 4.4.4, 4.4.5, 17.6.6). Die Lösung ist eigentlich simpel:

  • Bei der Windows-Authentifizierung, die Sie im weiteren Verlauf des Kapitels kennenlernen, wird die eigentliche Authentifizierung auf dem Client initiiert. Zum Zugriff auf den Webserver wird ein Zugriffsticket erstellt.
  • Bei der Standardauthentifizierung wird die Authentifizierung auf dem Webserver initiiert. Damit entfallen die Anforderungen an eine funktionierende Kerberos-Authentifizierung, wie Sie sie von der Windows-Authentifizierung her kennen. Das hört sich zunächst vielleicht sogar wie ein kleiner Vorteil an, es ist aber keiner, da eine zweite Authentifizierung durchgeführt wird und nicht nur ein Zugriffsticket erstellt wird (vergleiche Abschnitt 4.4.2 ff.). Außerdem werden bei der Standardauthentifizierung zwingend Anmeldeinformationen abgefragt. Der einzige Weg, das zu umgehen, ist, wenn der Browser die Anmeldeinformationen zwischenspeichert, was aber auch nicht so wirklich klasse ist.

Abbildung 17.53 Die Webapplikation wird mit der Identität des Pools ausgeführt.

Abbildung 17.54 Die Standardauthentifizierung kann mit dem ASP.NET-Identitätswechsel kombiniert werden.

Abbildung 17.55 Dieses Ergebnis gibt die Applikation zurück, wenn der ASP.NET-Identitätswechsel aktiviert ist.


Delegierung

Der Webserver kann im Fall des ASP.NET-Identitätswechsels mit der Identität des angemeldeten Benutzers auf Ressourcen einer anderen Maschine zugreifen, d. h., es ist eine Delegierung der Identität möglich. Dies gilt übrigens für alle Authentifizierungsverfahren, bei denen Benutzername und Kennwort auf dem Webserver verfügbar sind.

Die Delegierung geht standardmäßig aber nur über eine Station (1 Hop).


Woher weiß der Browser … – Teil 2

Kommen wir jetzt zu einem weiteren Teil von »Woher weiß der Browser…«: Wie Sie weiter vorn erfahren haben, antwortet der Webserver dem Browser mit der Statusmeldung 401, wenn ein unauthentifizierter Benutzer zugreifen möchte. Festzustellen wäre noch, wie der Browser weiß, dass er die Standardauthentifizierung verwenden soll und nicht etwa die Windows-Authentifizierung. Ein Blick in das Statusmeldung-401-Paket beantwortet die Frage (Abbildung 17.56): In der HTTP-Response wird im Abschnitt WWWAuthenticate angegeben, welches Authentifizierungsprotokoll unterstützt wird. In diesem Fall ist es Basic, also die Standardauthentifizierung.

Der Vollständigkeit halber möchte ich an dieser Stelle erwähnen, dass eine Website bzw. Webanwendung durchaus mehrere Authentifizierungsmethoden anbieten kann, was dann beispielsweise so wie in Abbildung 17.57 aussieht. Hier werden vier Methoden angeboten:

  • Standardauthentifizierung
  • Digestauthentifizierung: eine »etwas verbesserte« Standardauthentifizierung.
  • NTLM: Die Windows-Authentifizierung kann mit NTLM vorgenommen werden.
  • Negotiate: Dies ist ebenfalls Bestandteil der Windows-Authentifizierung. Client und Server handeln aus (englisch negotiate), ob Kerberos oder NTLM als Authentifizierungsprotokoll verwendet werden soll.

Abbildung 17.56 Die Antwort auf die Frage »Woher weiß der Browser, dass er die Standardauthentifizierung nutzen soll?«

Abbildung 17.57 Eine Website/Webanwendung kann durchaus mehrere Authentifizierungsmethoden anbieten.

Der Browser prüft, welches das stärkste von ihm unterstützte Protokoll ist, und führt damit die Authentifizierung aus.


Galileo Computing - Zum Seitenanfang

17.6.3 Digestauthentifizierung Zur nächsten ÜberschriftZur vorigen Überschrift

Wie Sie zuvor gesehen haben, ist ein wesentlicher Schwachpunkt bei der Windows-Anmeldung, dass das Kennwort unverschlüsselt übertragen wird – falls nicht die gesamte Verbindung mittels SSL verschlüsselt wird. RFC 2617, in der auch die Standardauthentifizierung definiert ist, enthält auch ein »verbessertes« Verfahren, bei dem nicht das eigentliche Kennwort, sondern ein Hash-Wert, der aus Benutzernamen und Kennwort gebildet wird, an den Server geschickt wird. Damit die Digestauthentifizierung verwendet wird, müssen Sie diese für die Website oder Webanwendung aktivieren – und vergessen Sie nicht, die anonyme Authentifizierung abzuschalten.

Der Ablauf im Detail:

  • Ebenso wie bei der Standardauthentifizierung weist der Webserver den anonymen Zugriff mit Statuscode 401 zurück. In Abbildung 17.58 zeige ich Ihnen die HTTP-Payload im Netzwerkmonitor. Der Webserver gibt eigentlich eine »normale« HTML-Seite zurück, die im Normalfall aber nie angezeigt wird, weil der Browser direkt die Anmeldeinformationen abfragt und einen authentifizierten Zugriff versucht.
  • Die Anmeldeinformationen werden mit dem Browserdialog aus Abbildung 17.59 abgefragt (hier: Internet Explorer). Im Vergleich zur Standardanmeldung fehlt hier die Warnung vor der unverschlüsselten Übertragung des Kennworts (vergleiche Abbildung 17.52).

Abbildung 17.58 Der Webserver weist die Anforderung mit Statuscode 401 zurück. Hier ein Blick auf die »Payload«.

Abbildung 17.59 Der Browserdialog zur Eingabe der Anmeldeinformationen

Die Behauptungen, die in einem Buch stehen, im Fernsehen verbreitet oder von der Schwiegermutter aufgestellt werden, kann man entweder ungefiltert glauben – oder man kann sich Beweise vorlegen lassen. Ich nehme an, dass Sie sich dieses Fachbuch gekauft oder geliehen haben, weil Sie genau auf diese Beweise hoffen. Also beweise ich Ihnen, dass bei der Digestauthentifizierung das Kennwort wirklich nicht im Klartext übertragen wird. Abbildung 17.60 zeigt das erste vom Client gesendete Paket nach der Authentifizierung, also das Paket mit den Authentifizierungsinformationen. In der Sektion Http/Request/Authorization sehen Sie den username im Klartext. Ansonsten findet sich dort ein Hash, aber kein Kennwort im Klartext.

Abbildung 17.60 Bei der Digestauthentifizierung wird das Kennwort nicht im Klartext übertragen. Stattdessen wird ein Kennwort-Hash übermittelt.

Die Digestauthentifizierung lässt sich natürlich auch mit dem ASP.NET-Identitätswechsel kombinieren, was dann zu dem in Abbildung 17.61 gezeigten Ergebnis führt.

Abbildung 17.61 Das Ergebnis einer Digest-Anmeldung mit aktiviertem ASP.NET-Identitätswechsel


Delegierung

In komplexen Nutzungsszenarien ist zu beachten, dass diese Authentifizierung nicht delegierbar ist, also nicht für den Zugriff auf einen weiteren Server unter der Identität des angemeldeten Benutzers verwendet werden kann. Für diesen Fall müssen Sie eine eingeschränkte Delegierung und einen Protokollübergang konfigurieren.



Galileo Computing - Zum Seitenanfang

17.6.4 Windows-Authentifizierung Zur nächsten ÜberschriftZur vorigen Überschrift

Hinter dem Thema der Windows-Authentifizierung verbergen sich letztendlich zwei hier zu diskutierende Aspekte:

  • Zum einen handelt es sich bei der Windows-Authentifizierung um eine weitere verwendbare Authentifizierungsmethode.
  • Zum anderen ist der Internet Explorer in der Lage, die Windows-Anmeldeinformationen des Benutzers auf dem Client-PC an den Webserver weiterzugeben und so eine Anmeldung ohne zusätzliche Eingabe von Benutzernamen und Passwort zu realisieren – sozusagen also Single Sign On.

Die Windows-Authentifizierung ist standardmäßig nicht installiert, muss also über den Server-Manager hinzugefügt werden (Rollendienste hinzufügen). Danach kann sie in der Konfigurationskategorie Authentifizierung auf der Ebene von Server, Website oder Webanwendung aktiviert werden (Abbildung 17.62). Zusätzliche Konfigurationsarbeiten sind nicht notwendig bzw. möglich.

Abbildung 17.62 Die Windows-Authentifizierung kann auf Server-, Website- oder Anwendungsebene aktiviert werden.

Im Zusammenhang mit der Windows-Authentifizierung gibt es allerdings noch zwei Einstellungen im Browser, die sich gegebenenfalls per Gruppenrichtlinie verteilen lassen:

  • Wenn Sie für Intranet-Websites die Funktion, dass die Anmeldung ohne nochmalige Eingabe der Anmeldeinformationen erfolgt, nutzen möchten, muss der Browser die Site entweder der Zone Lokales Intranet oder Vertrauenswürdige Sites zuordnen. In Abbildung 17.63 sehen Sie die entsprechenden Konfigurationsdialoge des Browsers. Wenn die Website über die Rechnernamen (also nicht über den FQDN) aufgerufen wird, funktioniert die automatische Ermittlung. Wenn zum Zugriff auf Intranet- oder Extranet-Websites die FQDN-Namen verwendet werden, müssen diese manuell hinzugefügt werden, wobei angenehmerweise Wildcards verwendet werden können.

Abbildung 17.63 Damit eine Website der Zone »Lokales Intranet« zugeordnet wird, müssen Sie gegebenenfalls Einstellungen vornehmen.

  • Weiterhin muss in der erweiterten Konfiguration des Internet Explorer die integrierte Windows-Authentifizierung aktiviert sein (Abbildung 17.64).

Abbildung 17.64 Aktivierung der integrierten Windows-Authentifizierung im Internet Explorer


Hinweis

Falls beim Zugriff auf eine Website eine oder beide der vorgenannten Bedingungen nicht erfüllt sind, funktioniert die Windows-Authentifizierung trotzdem. Der Browser wird allerdings nach dem Benutzernamen und dem Kennwort fragen – auch wenn der Benutzer eigentlich auf dem Client angemeldet ist.


Genau wie bei den anderen Authentifizierungsmethoden möchte ich Ihnen den Anmeldevorgang im Netzwerkmonitor zeigen (Abbildung 17.65):

  • Wenn der nicht angemeldete Benutzer auf die Website zugreift (Paket 81), …
  • … erhält er als Antwort den Statuscode 401, der dem Browser mitteilt, dass ein unauthentifizierter Zugriff nicht möglich ist (Paket 82).
  • In den Paketen 85 bis 87 sehen Sie die Durchführung der Windows-Authentifizierung.
  • Nach Abschluss der Authentifizierung ist der Webserver zufrieden und sendet die angeforderten Daten an den Client (ab Paket 88).

Sie sehen anhand der Zeitinformationen der Messung übrigens, dass der Browser sofort nach Erhalt des 401er-Statuscodes mit der Windows-Authentifizierung begonnen hat. Es gibt dort keine Zeitverzögerung durch einen Bediener, der 20 Sekunden braucht, um seinen Namen und Passwort einzutippen.


Webproxys

Zu beachten ist übrigens, dass die Windows-Authentifizierung nicht über Webproxys funktioniert. Den Grund sehen Sie in Abbildung 17.65: Die Pakete 85 bis 87, in denen die Authentifizierung durchgeführt wird, werden nicht über das HTTP-Protokoll abgewickelt.


Abbildung 17.65 Zunächst kommt der Statuscode 401 zurück, dann erfolgt die Windows-Authentifizierung (Pakete 85–87).

Die Windows-Authentifizierung lässt sich, wie alle anderen Authentifizierungsmethoden auch, mit dem ASP.NET-Identitätswechsel kombinieren. Zur Konfiguration ist nichts weiter zu sagen: einfach aktivieren (Abbildung 17.66).

Abbildung 17.66 Ein ASP.NET-Identitätswechsel kann mit der Windows-Authentifizierung kombiniert werden.

Das Ergebnis ist in Abbildung 17.67 zu sehen. Was ist an dieser Bildschirmanzeige nun so besonders, dass sie den Weg ins Buch gefunden hat? Zur Beantwortung dieser Frage gibt es zwei Stichwörter, nämlich NTLM und Kerberos. Das »alte«, bereits in Windows NT verwendete NTLM-Protokoll ist zwar nach wie vor eine der Säulen der Windows-Authentifizierung, wesentlich eleganter und leistungsfähiger ist allerdings das Kerberos-Protokoll, das ist Abschnitt 4.4.2 ff. kurz beschrieben ist. Insbesondere wenn Sie auf Authentifizierungsdelegierung angewiesen sind, ist es sehr viel eleganter, mit Kerberos zu arbeiten. Damit eine Kerberos-Authentifizierung zustande kommt, sind aber ein paar »Regeln« zu beachten.

Abbildung 17.67 Falls die Anmeldung »nur« mit NTLM erfolgt, Sie aber Kerberos benötigen, müssen Sie einige Aspekte überprüfen und beachten.


Delegierung

In komplexen Nutzungsszenarien ist zu beachten, dass diese Authentifizierung nicht delegierbar ist, also für den Zugriff auf einen weiteren Server unter der Identität des angemeldeten Benutzers verwendet werden kann. Für diesen Fall muss eine eingeschränkte Delegierung und gegebenenfalls ein Protokollübergang konfiguriert werden.



Galileo Computing - Zum Seitenanfang

17.6.5 Authentifizierungsdelegierung Zur nächsten ÜberschriftZur vorigen Überschrift

Ihre Benutzer werden die Windows-Authentifizierung lieben, denn sie bringt, wie bereits zuvor erläutert wurde, einen enormen Zugewinn an Komfort, weil die Zugangsdaten nicht nochmals eingetippt werden müssen. Ob die Windows-Authentifizierung dann letztendlich mit dem NTLM- oder dem Kerberos-Protokoll durchgeführt wird, macht für den Benutzer keinen Unterschied.

Administratoren und Entwickler verzweifeln allerdings regelmäßig daran, wenn ein Szenario wie aus Abbildung 17.68 zu implementieren ist:

  • Der Benutzer meldet sich mit seinem Windows-Konto an seinem PC an.
  • Mit seinem Browser meldet sich der Benutzer am Webserver an. Da dort ASP.NET-Identitätswechsel (Impersonation) aktiviert ist, nimmt die Webanwendung die Identität des angemeldeten Benutzers an.
  • Nun soll mit dieser Identität auf andere Ressourcen im Netz zugegriffen werden, beispielsweise einen SQL Server, Exchange Server, Domänencontroller, Webservice oder sonst etwas – Hauptsache, die Ressource akzeptiert Windows-Authentifizierung.

Abbildung 17.68 Ein Szenario mit Authentifizierungsdelegierung

Auf den ersten Blick sieht das Szenario auch nicht kompliziert aus, schließlich läuft der Prozess auf dem Webserver ja mit der Identität des Benutzers. Wenn aber der Zugriff auf den anderen Server durchgeführt wird, erfolgt der Zugriff mit der Poolidentität und nicht mit der des angemeldeten Benutzers – es sei denn, Sie unternehmen etwas!

Das Stichwort lautet Authentifizierungsdelegierung, im Allgemeinen kurz Delegierung genannt. Bei allen Authentifizierungsmethoden, bei denen der Webserver Benutzername und Passwort nicht kennt, ist zunächst keine Delegierung möglich. Dies kann aber konfiguriert werden. Tabelle 17.1 zeigt den Status der Authentifizierungsdelegierung bei den unterschiedlichen Authentifizierungsmethoden.


Tabelle 17.1 Die Authentifizierungsdelegierung bei den verschiedenen Authentifizierungsmethoden

Authentifizierungsmethoden Delegierung?

Standard

Delegierung möglich, da der Webserver Benutzername und Passwort kennt; allerdings nur 1 Hop.

Digest

Eingeschränkte Delegierung und Protokollübergang müssen konfiguriert werden.

Windows (NTLM)

Eingeschränkte Delegierung und Protokollübergang müssen konfiguriert werden.

Windows (Kerberos)

Delegierung muss konfiguiert werden.

Clientzertifikatzuordnung

Eingeschränkte Delegierung und Protokollübergang müssen konfiguriert werden.

IIS-Clientzertifikatzuordnung

Delegierung möglich, allerdings nur 1 Hop.

Anonyme

Delegierung über 1 Hop, wenn benutzerdefinierter anonymer Benutzer oder benutzerdefinierte Poolidentität verwendet wird.



Empfehlung

Auch wenn sich die Authentifizierungsdelegierung mit allen Methoden realisieren lässt, ist die Empfehlung ganz eindeutig, dies mit Kerberos durchzuführen.



Galileo Computing - Zum Seitenanfang

17.6.6 Webanwendungen und Kerberos Zur nächsten ÜberschriftZur vorigen Überschrift

Gleich zu Beginn dieses Abschnitts sei darauf hingewiesen, dass das Thema Kerberos in Abschnitt 4.4 recht ausführlich behandelt wird. Ich beschränke mich hier auf die Aspekte, die unmittelbar mit dem Webserver zusammenhängen.

Ich zeige Ihnen zu Beginn ein kleines Szenario:

  • Auf einem Server sind zwei Websites eingerichtet: die Default Web Site und eine zusätzliche, die über den Hostheader extranet.ubinf.intra zu erreichen ist (Abbildung 17.69).

Abbildung 17.69 Die Ausgangslage für die in gezeigte Situation

  • Wenn man auf beiden die CheckKerberos-Webanwendung aufruft, kommt es zu unterschiedlichen Ergebnissen bei der Authentifizierung (Abbildung 17.70):
    • Bei der Default Web Site erfolgt die Authentifizierung mit dem Kerberos-Protokoll.
    • Bei der zusätzlich eingerichteten Website wird »nur« mit NTLM authentifiziert.

Abbildung 17.70 Die Anwendungen laufen auf demselben Webserver auf unterschiedlichen Websites. Einmal erfolgt die Anmeldung mit Kerberos, das andere Mal »nur« mit NTLM.

Der Unterschied kommt dadurch zustande, dass im zweiten Szenario kein Service Principal Name (SPN) vorhanden ist – das schauen wir uns im nächsten Abschnitt genauer an.

Service Principal Names

Bei der Kerberos-Authentifizierung teilt der am Domänencontroller authentifizierte Client diesem mit, auf welchen Dienst er gern zugreifen würde, und der Domänencontroller (genauer: das Key Distribution Center, das auf einem Domänencontroller ausgeführt wird) erstellt das Zugriffsticket.

Dieser Vorgang basiert auf Namen, genauer gesagt auf den Service Principial Names (SPN):

  • Möchte der Client auf den HTTP-Dienst auf dem Server ubinfWebNlb1 zugreifen, lautet der Name des Diensts HTTP/ubinfwebnlb1.ubinf.intra. (Das ist in dem vorherigen Beispiel die Default Web Site.)
  • Die zusätzlich eingerichtete Website wird, da Hostheader konfiguriert sind, über extranet.ubinf.intra aufgerufen. Folglich lautet der Dienstname HTTP://extranet.ubinf.intra.

Die Service Principal Names sind, bis auf eine Ausnahme, nicht »einfach da«. Die eine Ausnahme (die eigentlich sogar aus zwei Ausnahmen besteht) bezieht sich auf die SPNs, die auf den eigentlichen Namen des Servers verweisen. Die SPNs sind im Attribut servicePrincipalName eines Computer- oder Benutzerkontos gespeichert. Standardmäßig ist bei einem Computerkonto der »kurze Name« und der FQDN mit der Dienstkennung HOST/ vorhanden. Einige Dienste registrieren automatisch einen zusätzlichen SPN. Dies ist in Abbildung 17.71 zu sehen.

Abbildung 17.71 Die Service Principal Names sind in einem Active Directory-Attribut gespeichert.

Wenn ein Client auf einen Dienst zugreifen möchte, beispielsweise auf den Webserver, erhält er ein entsprechendes Zugriffsticket. Diese Tickets können mit dem Werkzeug kerbtray.exe, das Bestandteil des Ressource-Kits ist, sichtbar gemacht werden. Kerbtray zeigt die auf den zugreifenden Clients vorhandenen Zugriffstickets. In Abbildung 17.72 sehen Sie, dass der hier betrachtete Client ein Zugriffsticket für den Dienst HTTP/ubinfwebnlb1.ubinf.intra hat. Wenn er mit diesem auf die Ressource zugreift, geschieht dies mit Kerberos-Authentifizierung (siehe Abbildung 17.70 oben).

Abbildung 17.72 Das Zugriffsticket basiert auf dem Service Principal Name.

Mehr zur Funktionsweise von Kerberos finden Sie auch in Abschnitt 4.4.2.

So, vermutlich ahnen Sie schon, warum im zweiten Beispiel keine Kerberos-Authentifizierung stattfindet: Es gibt keinen registrierten Service Principal Name für den Eintrag extranet.ubinf.intra. Die Vermutung stimmt, aber mit dem Netzwerkmonitor kann man das auch beweisen:

  • Es ist zwar nicht in der Abbildung zu sehen, aber der Client bekommt beim Zugriff auf den Server die Ihnen bereits wohlbekannte 401 präsentiert.
  • Im Paket 99 fordert der Client ein Zugriffsticket für HTTP/extranet.ubinf.intra an. Kurze Anmerkung: Ja, ich weiß, im Netzwerkmonitor steht nur HTTP/extranet.ub. Wenn man aber in Paket 100 hineinschaut, findet sich dort das fehlende inf.intra; es ist also alles in Ordnung, und ich schiebe Ihnen keine falschen Tatsachen unter.
  • In Paket 102 gibt es dann die Antwort: KDC_ERR_S_PRINCIPAL_UNKNOWN, das heißt, der Service Principal Name wurde nicht gefunden. Das war klar, denn den gibt es einfach nicht.
  • Daraufhin beginnt der Client als »Ausweichlösung« mit dem NTLM-Authentifizierungsvorgang. Die drei NTLMSSP-Pakete sind Ihnen ja weiter vorn bereits begegnet (104, 107, 108).
  • Nachdem die Authentifizierung abgeschlossen ist, beginnt ab Paket 110 die Übertragung des Inhalts.

Die Frage ist nun, wie man einen SPN registriert. Wie Sie bereits gesehen haben, »hängt« der SPN an einem Computer- oder Benutzerkonto. Die Kerberos-Zugriffstickets werden für das Konto verschlüsselt, mit dem die Zielressource (in diesem Fall der Webserver) die Anforderung verarbeitet. Solange der Anwendungspool der angesprochenen Webanwendung mit einem der eingebauten Konten (Netzwerkdienst, Lokales System, Lokaler Dienst) läuft, wird die Entschlüsselung mit dem Computerkonto vorgenommen. Für den Service Principal Name bedeutet das, dass er für das Computerkonto registriert werden muss.

Abbildung 17.73 Die Kerberos-Authentifizierung gelingt nicht, weil der Domänencontroller meldet, dass der Service Principal unbekannt ist.

Einen SPN könnte man mit ADSI-Editor oder dem Attribut-Editor des Active Directory-Benutzer und -Computer-Snap-Ins eintragen. Eleganter ist es aber, das Kommandozeilenwerkzeug setspn.exe zu verwenden. Unter Windows Server 2003 und Windows 2000 Server musste man es noch aus dem Ressource Kit installieren, mittlerweile ist es eine standardmäßig vorhandene Komponente.

Das Hinzufügen eines SPNs mit setspn.exe gestaltet sich einfach:

Setspn.exe –a HTTP/name computerkonto

Es empfiehlt sich, direkt sowohl den »kurzen« Computernamen als auch den FQDN zu registrieren. Im konkreten Beispiel sieht es dann bei der Eingabe wie in Abbildung 17.74 aus, und im Attribut-Editor ergibt sich die Situation aus Abbildung 17.75.

Abbildung 17.74 Das Hinzufügen der Service Principal Names zum Computerkonto mit setspn.exe …

Abbildung 17.75 … und das Ergebnis im Attribut-Editor

Testet man nach der Registrierung des SPNs nochmals, wird nun die Authentifizierung mit Kerberos vorgenommen. Falls Sie mit meiner Testapplikation arbeiten, können Sie das unmittelbar sehen; es gibt aber auch andere Wege:

  • Natürlich kann man mit dem Netzwerkmonitor beobachten. In Abbildung 17.76 sehen Sie den Vorgang:
    • Anforderung des Zugriffstickets mit Paket 103
    • Antwort des Domänencontrollers mit dem gewünschten Ticket: Paket 106
  • Deutlich bequemer als die Arbeit mit dem Netzwerkmonitor ist die Verwendung von kerbtray.exe. Auch hier ist das ausgestellte Ticket in voller Schönheit und in Farbe zu sehen (Abbildung 17.77).
  • Falls Sie auf dem Webserver die Anmeldevorgänge protokollieren lassen, wird in der Rubrik Sicherheit des Ereignisprotokolls ein Eintrag mit der Anmeldung erscheinen. Dort ist auch das Authentifizierungsprotokoll angegeben (Abbildung 17.78).

Abbildung 17.76 Hier war die Kerberos-Authentifizierung erfolgreich, und der Client erhält das erhoffte Zugriffsticket.

Abbildung 17.77 Mit »kerbtray.exe« geht es bequemer: Auch hier ist das Zugriffsticket für die Ressource zu sehen.

Abbildung 17.78 Auch in der »Ereignisanzeige« können Sie kontrollieren, ob ein Anmeldevorgang tatsächlich mit Kerberos durchgeführt wurde.

Identität des Anwendungspools und Kernelmodus-Authentifizierung, Teil I

Wenn Sie den vorherigen Abschnitt genau gelesen haben, sind Sie auf den Sachverhalt gestoßen, dass das Zugriffsticket für die Identität ausgestellt wird, mit der der Anwendungspool betrieben wird.

Mit dem IIS 6 (Windows Server 2003) würde ein Wechsel der Anwendungspool-Identität vom eingebauten Konto Netzwerkdienst zu einem Domänenbenutzerkonto dazu führen, dass die Authentifizierung misslingt: Der SPN ist beim Computerkonto gespeichert. Allerdings versucht ein Domänenkonto, das Zugriffsticket zu entschlüsseln – und das geht schief.

Die Kernelmodus-Authentifizierung von IIS7 sorgt allerdings (unter anderem) dafür, dass die Zugriffstickets mit dem Computerkonto entschlüsselt werden. Die Kernelmodus-Authentifizierung wird in den Eigenschaften der Windows-Authentifizierung konfiguriert und ist standardmäßig aktiv (Abbildung 17.79).

Abbildung 17.79 Die Kernelmodus-Authentifizierung ist im Normalfall aktiviert.

Die Kernelmodus-Authentifizierung sorgt also dafür, dass die Anwendungspools mit beliebigen Identitäten betrieben werden und die SPNs trotzdem für das Computerkonto registriert werden können. Das ist in der Praxis im Allgemeinen sehr angenehm.

Falls ein Kerberos-Ticket für das »falsche« Dienstkonto erstellt wird, werden Sie folgendes Fehlerbild erkennen:

  • Zunächst werden Sie nach den Anmeldeinformationen gefragt, obwohl aufgrund der integrierten Windows-Authentifizierung die Credentials eigentlich automatisch übermittelt werden sollten. Sie können Ihre Anmeldeinformationen dreimal eingeben (siehe Abbildung 17.80).

Abbildung 17.80 So sieht es aus, wenn das Kerberos-Zugriffsticket für das falsche Konto erstellt wird. Zuerst werden Sie dreimal nach den Anmeldeinformationen gefragt …

  • Und dann gibt es trotzdem die in Abbildung 17.81 gezeigte Fehlermeldung, dass der Zugriff verweigert wurde.

Sie sollten sich dieses Fehlerbild sehr gut einprägen und sofort hellhörig werden, wenn ein Anwender von einem solchen Effekt berichtet. Es könnte zwar durchaus auch andere Ursachen geben, ein Kerberos-Problem ist aber erfahrungsgemäß nicht unwahrscheinlich …

Abbildung 17.81 … und dann bekommen Sie ein »Zugriff verweigert« – trotz eigentlich korrekter Anmeldeinformationen.

Identität des Anwendungspools und Kernelmodus-Authentifizierung, Teil II

Es ist nun natürlich möglich, dass Sie nicht von dem Feature profitieren möchten, dass die Entschlüsselung des Zugriffstickets vom Computerkonto und nicht vom Dienstkonto des Anwendungspools durchgeführt wird – oder anders gesagt: Dieses Verhalten könnte für Ihre Aufgabenstellung kontraproduktiv sein. Ein Musterbeispiel ist die Verwendung von Network Load Balancing – die komplette Begründung nebst der genauen Beschreibung des Szenarios finden Sie in Abschnitt 20.3.4.

Die eine Möglichkeit wäre, die Kernelmodus-Authentifizierung zu deaktivieren. Das funktioniert, ist aber nicht die optimale Lösung, weil sie neben der »Kerberos-Entschlüsselungsthematik« durchaus noch andere Vorteile bietet – insbesondere bezüglich Leistung und Performance.

Es wäre also perfekt, wenn man die Kernelmodus-Authentifizierung nutzen könnte und trotzdem zur Entschlüsselung der Kerberos-Tickets die Identität des Anwendungspools verwendet würde. Die gute Nachricht ist, dass man das dementsprechend konfigurieren kann, die schlechte ist, dass das nicht im Internetinformationsdienste-Manager möglich ist, sondern in der .config-Datei erledigt werden muss.

Wenn Sie diese Einstellung auf der Ebene von Website oder Anwendung vornehmen möchten, ergänzen Sie die web.config im Abschnitt system.webServer/security/authentication um folgenden Eintrag:

<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />

Dieser Abschnitt wird in vielen Fällen nicht vorhanden sein, daher zeige ich Ihnen in Abbildung 17.82, wie das Ergebnis in etwa aussehen müsste.

Abbildung 17.82 Mit dieser Anpassung in der »web.config« (Website, Anwendung) können Sie die Kernelmodus-Authentifizierung aktiviert lassen, aber trotzdem zur Entschlüsselung des Kerberos-Tickets die Identität des Anwendungspools verwenden.

Probieren Sie einmal, die Authentifizierungskonfiguration der Website bzw. Webanwendung aufzurufen, deren web.config Sie geändert haben. Vermutlich wird die Warnung aus Abbildung 17.83 erscheinen, dass der Konfigurationsabschnitt nicht geändert werden kann, weil er auf übergeordneter Ebene gesperrt ist. Wenn Sie nun die Webanwendung aufrufen, wird es einen Fehler 500 (interner Serverfehler) geben – wir waren also noch nicht wirklich erfolgreich.

Abbildung 17.83 Hoppla! Das passiert, wenn der entsprechende Abschnitt der Konfiguration gesperrt ist.

Das Problem ist aber einfach zu lösen, indem Sie auf Serverebene den Konfigurationsabschnitt freigeben – leider auch etwas für den Texteditor: Suchen Sie in der applicationHost.config (C:\Windows\System32\inetsrv\config) die in Abbildung 17.84 markierte Zeile, und machen Sie aus dem Deny ein Allow. Jetzt können Sie noch einmal versuchen, auf die Authentifizierungskonfiguration zuzugreifen, was diesmal ohne Fehlermeldung klappen sollte. Außerdem wird nun die Kerberos-Authentifizierung für die Website funktionieren.

Abbildung 17.84 So wird der zu ändernde Abschnitt in der »applicationHost.config« entsperrt.


Galileo Computing - Zum Seitenanfang

17.6.7 Delegierung, eingeschränke Delegierung und Protokollübergang Zur nächsten ÜberschriftZur vorigen Überschrift

Das in Abbildung 17.68 gezeigte Szenario benötigt Authentifizierungsdelegierung, und ich habe weiter vorn empfohlen, hierfür Kerberos einzusetzen.

Falls Sie meine Mini-Webapplikation zur Überprüfung des Anmeldestatus verwenden (oder das auf eine andere Art tun), werden Sie feststellen, dass als Impersonation Level Impersonation angegeben ist – also wurde die Identität des Benutzers angenommen, kann aber nicht delegiert werden. Falls die Authentifizierungsdelegierung möglich ist, muss dort Delegation stehen.

Keine Sorge, Sie haben nichts falsch gemacht, es sind aber noch einige kleine weitere Konfigurationsschritte notwendig.

Die All-inclusive-Methode

Damit der Webserver eine Authentifizierungsdelegierung wie in Abbildung 17.68 gezeigt vornehmen kann, muss dem Computerkonto oder dem als Identität des Anwendungspools verwendeten Domänenbenutzerkonto für Delegierung vertraut werden:

  • Rufen Sie das Snap-In Active Directory-Benutzer und -Computer auf, und öffnen Sie die Eigenschaften des Computer- oder Benutzerkontos.
  • Wechseln Sie auf die Registerkarte Delegierung,
  • und wählen Sie dort die in Abbildung 17.85 gezeigte Einstellung.
  • Warten Sie eine Weile, bis die Active Directory-Replikation abgeschlossen ist, zumindest an Ihrem Standort.
  • Starten Sie den Webserver-Computer neu.

Abbildung 17.85 Diese Einstellung müssen Sie wählen, wenn einem Computer- oder Benutzerkonto für Delegierung vertraut werden soll.

Falls Sie kürzlich bereits eine Kerberos-Anmeldung an diesem System durchgeführt haben, müssen Sie sich entweder neu anmelden oder alle vorhandenen Kerberos-Tickets löschen. Letzteres geht beispielsweise mit kerbtray.exe.

Beachten Sie, dass der Server (in diesem Fall die Webanwendung) mit dieser Einstellung auf jede beliebige Ressource in Ihrem Netz mit der Identität des authentifizierten Benutzers zugreifen kann. Eine etwas selektivere Vorgehensweise wäre schön und ist mit der im folgenden Abschnitt vorgestellten Constrained Delegation bzw. eingeschränkten Delegierung möglich.

Constrained Delegation (eingeschränkte Delegierung)

Ein System, dessen Möglichkeiten nur sehr wenig eingeschränkt sind, ist den meisten Administratoren mit Recht ein Dorn im Auge. Ein Webserver, der Authentifizierungsdelegierung ohne jegliche Grenzen betreiben kann, ist folglich auch nicht das Optimum – genau das haben wir aber im vorherigen Abschnitt konfiguriert.

Seit Windows Server 2003 gibt es die Möglichkeit der eingeschränkten Delegierung oder Constrained Delegation. Simple Idee, große Wirkung: Dem Computerkonto oder Benutzerkonto wird nicht mehr pauschal die Möglichkeit gegeben, auf sämtliche Dienste mit der Identität des angemeldeten Benutzers zuzugreifen, sondern die erlaubten Dienste werden explizit angegeben.

Abbildung 17.86 Eingeschränkte Delegierung: Nur auf diese beiden hier angegebenen LDAP-Ressourcen kann mit der Identität des mit Kerberos angemeldeten Benutzers zugegriffen werden.

Dazu gibt es ein kleines Beispiel aus der Praxis: Ich habe in der letzten Zeit für etliche Kunden kleine Webanwendungen gebaut, mit denen ausgewählte Mitarbeiter aus den Fachabteilungen Pflegearbeiten im Active Directory erledigen können, beispielsweise Attribute wie Telefonnummern ändern, Gruppenmitgliedschaften anpassen und dergleichen mehr. Der Zugriff auf das AD soll natürlich mit der Identität des angemeldeten Benutzers erfolgen, um nicht eine zusätzliche Berechtigungssteuerung implementieren zu müssen. Da die Webapplikationen eigentlich nie auf dem Domänencontroller ausgeführt werden, liegt ein Szenario vor, das eine Authentifizierungsdelegierung notwendig macht. Da die Webapplikationen aber nur auf die Domänencontroller zurückgreifen müssen, kann die Delegierungsberechtigung so eingestellt werden, dass die Identität nur auf die LDAP-Dienste der vorgegebenen DCs delegiert werden kann. Abbildung 17.86 zeigt, wie dieses Szenario in meiner Testumgebung konfiguriert wird.

Protokollübergang (Protocol Transition)

Es ist durchaus denkbar, dass eine Kerberos-Authentifizierung einfach nicht durchgeführt werden kann. Dies ist beispielsweise dann der Fall, wenn der Benutzer sich im Internet befindet und über eine Firewall bzw. einen Proxy auf die Webanwendung zugreift. Auch in diesem Fall ist eine Authentifizierungsdelegierung möglich: Es wird dann ein Protokollübergang (Protocol Transition) durchgeführt.

Eine Authentifizierungsdelegierung mittels Protokollübergang kann nicht »pauschal« für alle Dienste im Netz freigeschaltet werden. Vielmehr müssen die Dienste einzeln angegeben werden, genau wie bei der zuvor vorgestellten eingeschränkten Delegierung.

Die Konfiguration erfolgt mit dem Dialog aus Abbildung 17.86, im Gegensatz zur Situation in der Abbildung wird die Option Beliebiges Authentifizierungsprotokoll verwenden ausgewählt.


Komplett Kerberos

Sie können sich mit dem Protokollübergang zwar behelfen, wenn die Authentifizierung mit Kerberos am Webserver nicht möglich ist. Sie sollten daraus aber nicht den Schluss ziehen, dass Sie grundsätzlich immer den Protokollübergang nutzen und sich um »die ganzen Kerberos-Themen«, allen voran die Service Principal Names, nicht mehr zu kümmern brauchen – Protokollübergang ist gut, aber »komplett Kerberos« ist besser.



Galileo Computing - Zum Seitenanfang

17.6.8 Formularauthentifizierung topZur vorigen Überschrift

Die bisher gezeigten Authentifizierungsmethoden hatten zwei wesentliche Gemeinsamkeiten:

  • Die Authentifizierung erfolgt letztendlich gegen das Active Directory (oder lokal angelegte Benutzer).
  • Der Browser »kennt« das Kennwort, weil er es abfragt und weitergibt. Wie in Abbildung 17.52 und Abbildung 17.59 zu sehen ist, kann der Browser diese Anmeldeinformationen auch zwischenspeichern.

So praktisch diese Verfahren – insbesondere natürlich die Windows-Authentifizierung mit automatischer Anmeldung – in einem Intranet-Szenario sind, haben sie auch durchaus Nachteile:

  • Sie können nicht verhindern, dass ein Browser die Anmeldeinformationen zwischenspeichert. Das ist insbesondere dann lästig, wenn die Benutzer sich beispielsweise in einem Internet-Café oder dergleichen anmelden: Der nachfolgende Benutzer freut sich über ganz neue Einblicke, weil jede Menge Credentials im Cache des Browsers sind.
  • Falls sich an einer Anwendung nicht nur interne Benutzer anmelden, wäre es sehr lästig, wenn Sie Tausende »Fremd-Anwender« in Ihrem Active Directory eintragen müssten, weil Sie diese sonst nicht authentifizieren können.
  • Beim Anmeldevorgang soll vielleicht eine Information angezeigt werden, in der die Anwender darauf hingewiesen werden, dass sie mit der Anmeldung die Nutzungsbedingungen akzeptieren oder dergleichen. Das ist natürlich nicht möglich, wenn einfach der Anmeldedialog des Browsers geöffnet wird.

Hinweis zum erstgenannten Punkt

Wenn Benutzer sich auf PCs anmelden, die nicht in Ihrem »Herrschaftsbereich« liegen, können Sie sich natürlich nie sicher sein, was da alles passieren könnte. Ein Internet-Café-Betreiber mit kriminellem Touch könnte auf die Idee kommen, auf sämtlichen PCs Keystroke-Logger zu installieren und so sämtliche eingegebenen Daten zu speichern. Trotzdem ist es ein Fortschritt, wenn der Browser die Zugangsinformationen nicht im Klartext annimmt und durch einen simplen Mausklick zwischenspeichert.


Abbildung 17.87 Ein bekanntes Beispiel für formularbasierte Authentifizierung ist Outlook Web Access (hier: Exchange Server 2007).

Gesucht wird also ein Anmeldeverfahren, das die zuvor beschriebenen Nachteile nicht hat. Diese Anforderung wird von der formularbasierten Authentifizierung erfüllt. »Formularbasiert« bedeutet, dass die Anmeldedaten auf einem Webformular eingegeben werden: Der Browser »weiß« letztendlich nicht, dass gerade Benutzername und Kennwort abgefragt und übertragen werden.

Ein geradezu klassisches Beispiel ist Outlook Web Access (OWA): Abbildung 17.87 zeigt den OWA-Anmeldedialog von Exchange Server 2007. Exchange unterstützt natürlich auch die Windows-Authentifizierung, aber aus Gründen der Sicherheit konfigurieren erfahrene Administratoren bei Verbindungen, die von außerhalb des Unternehmens aufgebaut werden, im Normalfall die formularbasierte Authentifizierung.

Funktionsweise und was die Applikation tun muss

Die Funktionsweise der formularbasierten Authentifizierung ist eigentlich recht simpel. Abbildung 17.88 zeigt eine schematische Darstellung:

  • Greift ein Benutzer auf die Webapplikation zu, die nur für authentifizierte Benutzer zugänglich ist, wird zunächst geprüft, ob der Benutzer über ein noch gültiges Cookie verfügt (das kann ein Sitzungs-Cookie oder ein permanentes Cookie sein).

Abbildung 17.88 Die Funktionsweise der formularbasierten Authentifizierung

  • Falls er kein Cookie besitzt, wird der Benutzer zunächst zu einer Anmeldeseite umgeleitet. Hier werden die Anmeldeinformationen entgegengenommen und überprüft. Sind diese gültig, wird der Benutzer zur eigentlichen Webanwendung weitergeleitet. Wie die Anmeldeseite die Benutzerinformationen überprüft, steht dem Entwickler frei; normalerweise werden die Informationen mit einer Datenbank oder einem Verzeichnisdienst abgeglichen.
  • Präsentiert der Benutzer ein gültiges Cookie, ist er authentifiziert und kann direkt auf die Webanwendung zugreifen.

Um die Funktionsweise der formularbasierten Authentifizierung im Rahmen dieses Buchs ein wenig genauer unter die Lupe nehmen zu können, habe ich eine kleine Demo-Applikation erstellt (Abbildung 17.89):

  • Die Webanwendung besteht einerseits aus einer default.aspx, die die Anmeldeinformationen, also den Anmeldenamen und die Art der Anmeldung, anzeigt. Letztere ist notwendigerweise immer »Forms«.
  • Weiterhin gibt es eine login.aspx, auf der der Benutzer seine Anmeldedaten eintragen kann.

Abbildung 17.89 Eine kleine Beispielapplikation zur Demonstration der formularbasierten Authentifizierung

Zu der kleinen Applikation möchte ich Ihnen noch einen Code-Schnipsel zeigen. In Listing 17.1 sehen Sie die Methode, die auf dem Server aufgerufen wird, wenn der Benutzer auf die Schaltfläche Anmelden klickt. Die wichtigste Zeile ist fett gedruckt: Sind die Anmeldeinformationen korrekt, wird die Methode RedirectFromLoginPage aufgerufen, und der nun authentifizierte Anwender gelangt zur eigentlichen Webanwendung. Die Prüfung der Anmeldeinformationen wird im Normalfall gegen einen Verzeichnisdienst (beispielsweise Active Directory) oder eine Datenbank erfolgen. In diesem Fall wird einfach geprüft, ob das Passwort dem eingegebenen Benutzernamen nebst angehängtem »123« entspricht – ist ja nur ein Testszenario.

protected void btnLogin_Click(object sender, EventArgs e)
{
    if (txtPassword.Text == txtUsername.Text + "123")
    {
        FormsAuthentication.RedirectFromLoginPage(txtUsername.Text,
          chkRememberMe.Checked);
    }
    else
    {
        lblWrongCredentials.Visible = true;
    }
}

Listing 17.1 Diese Methode wird aufgerufen, wenn der Benutzer auf den Button »Anmelden« des »Login.aspx«-Webforms klickt.

Interessant ist noch, was in der web.config der Webanwendung eingestellt werden kann bzw. muss. Listing 17.2 zeigt den »entscheidenden« Abschnitt:

  • Im Abschnitt <authentication> wird unter anderem definiert, dass die formularbasierte Authentifizierung durchgeführt werden soll und für die Anmeldung die login.aspx verwendet werden soll.
  • Im Abschnitt <authorization> wird festgelegt, dass keine anonymen Benutzer zugreifen dürfen, dass also eine Authentifizierung erzwungen werden muss.
<authentication mode="Forms">
    <forms loginUrl="login.aspx" name=".ASPXFORMSAUTH">
    </forms>
</authentication>
<authorization>
    <deny users="?"/>
</authorization>

Listing 17.2 Der »entscheidende Abschnitt« der »Web.config« der Webanwendung

Einrichten

Die Einrichtung einer Webanwendung mit formularbasierter Authentifizierung erfolgt zunächst wie die Einrichtung jeder anderen Webanwendung auch (siehe Abschnitt 17.5.5).

Da die formularbasierte Authentifizierung standardmäßig nicht installiert ist, muss zunächst der Rollendienst Formularauthentifizierung installiert werden, beispielsweise über den Server-Manager.

Nun kann die Formularauthentifizierung aktiviert und konfiguriert (Abbildung 17.90) werden. Die anderen Authentifizierungsmethoden müssen mit Ausnahme der anonymen Authentifizierung für diese Webanwendung abgeschaltet werden, sofern sie überhaupt installiert sind.

Noch einige Anmerkungen zu den Konfigurationsmöglichkeiten (Abbildung 17.90):

  • Der Timeout für das Authentifizierungscookie ist eine interessante Einstellung. Eine kurz gewählte Dauer ist in Hinblick auf die Sicherheit günstig: Falls ein Benutzer eine angemeldete Anwendung im Browser stehen lässt und sich entfernt, wird die Anmeldung von selbst ungültig – je schneller, desto besser. Im Allgemeinen aktiviert man die Option Cookieablauf bei jeder Anforderung verlängern – ansonsten wäre nach Ablauf des Timeouts eine neue Anmeldung notwendig, auch wenn der Benutzer mitten in der Arbeit mit der Webanwendung ist.
  • Es ist durchaus sinnvoll, bei formularbasierter Authentifizierung SSL zu erzwingen. Sie werden weiter unten sehen, dass der Benutzername und das Kennwort ansonsten unverschlüsselt durch das Netz reisen.

Abbildung 17.90 Konfiguration der formularbasierten Anmeldung

Analysieren

Noch offene Detailfragen zum Funktionieren der formularbasierten Authentifizierung lassen sich vermutlich am einfachsten beantworten, wenn wir einen Blick auf den Netzwerkverkehr werfen. Dabei gibt es zwei Szenarien:

  • Ein Benutzer meldet sich erstmalig an einer Webapplikation an.
  • Ein bereits zuvor angemeldeter Benutzer, der sich ein permanentes Cookie (»Angemeldet bleiben«, »Remember me«) hat ausstellen lassen, kehrt zurück.

Erstmalige Anmeldung

Abbildung 17.91 zeigt den Anmeldevorgang an einer Webanwendung mit formularbasierter Authentifizierung.

  • Die Frames 9 bis 53 erhalten die »üblichen Vorgänge« wie das Auflösen von Namen und IP-Adressen (DNS und ARP). Dies ist zuvor hinreichend ausführlich besprochen worden.

Abbildung 17.91 Den ersten Zugriffsversuch des nicht authentifizierten Clients quittiert der Server mit dem Statuscode 302 (»Moved temporarily«).

  • Mit Paket 54 möchte der Client auf die Seite default.aspx der Webanwendung zugreifen.
  • Da der Client bislang nicht authentifiziert ist, lehnt der Server dies ab. Im Gegensatz zu den anderen besprochenen Authentifizierungsmethoden (Standard-, Digest- und Windows-Authentifizierung) geschieht das aber nicht mit dem Statuscode 401 (unauthorized), sondern mit 302 (moved temporarily). Diese Rückmeldung veranlasst den Browser, die als location (siehe den Fensterbereich Frame Details) angegebene Seite aufzurufen.
  • In Paket 56 ruft der Browser also die Login.aspx-Seite auf, deren Inhalt in den Paketen 57 und 58 übermittelt wird.

Der Benutzer sieht nun das Anmeldeformular in seinem Browser und kann die notwendigen Eingaben vornehmen. Die Pakete 134 und 135 enthalten den HTTP POST-Request, in dem die Anmeldedaten an den Server gesendet werden. Wenn man genau in den Datenstrom hineinschaut, sieht man den Benutzernamen und das Kennwort im Klartext (Abbildung 17.92): Schauen Sie genau auf den markierten Bereich im Fenster Hex Details: Dort finden Sie mit uli und uli123 diese im Normalfall schützenswerten Angaben.

Fazit der Abbildung 17.92: Setzen Sie niemals formularbasierte Authentifizierung ohne SSL-Verschlüsselung ein!

Abbildung 17.92 In diesem POST-Request werden Benutzername und Passwort übertragen. Und die sind im Datenstrom im Klartext sichtbar. Benutzen Sie also niemals die formularbasierte Authentifizierung ohne SSL-Verschlüsselung!

In den Paketen 136 und 137 finden Sie die Antwort des Servers auf die Übermittlung der Anmeldedaten, die in diesem Fall »richtig« waren (Abbildung 17.93):

  • Der Server reagiert mit dem Statuscode 302 und fordert den Client auf, eine .aspx-Datei der Webanwendung zu öffnen (Location:… in den Frame Details).
  • Weiterhin erhält der Client ein Cookie (Set-Cookie in den Frame Details), mit dem er seine Identität nachweisen kann – jedenfalls während des Gültigkeitszeitraums des Cookies.

Abbildung 17.93 In der Antwort des Servers wird das Cookie gesetzt.

Zum Abschluss schauen wir noch den HTTP GET-Request des Browsers in Paket 140 an, also den Zugriff auf die Webanwendung (Abbildung 17.94): Der Browser sendet das zuvor erhaltene Cookie mit (markiert in den Frame Details), so dass der Server die Anforderung korrekt zuordnen kann.

Abbildung 17.94 Beim GET-Request wird das Cookie mitgesendet – und dann klappt’s auch mit dem Zugriff.

Anmeldung bei vorhandenem permanenten Cookie

Viele Anwendungen verfügen auf der Anmeldeseite über eine »Angemeldet bleiben«- oder »Remember Me«-Option, so auch die kleine Demo-Anwendung (siehe Abbildung 17.89 oben). Interessant ist nun, wie der Netzwerkverkehr aussieht, wenn der Browser zuvor ein permanentes Cookie erhalten hat (Abbildung 17.95):

  • In Paket 44 erfolgt der HTTP GET-Request. Wie man in den Frame Details erkennen kann, wird ein Cookie mitgesendet.
  • Der Server reagiert direkt mit dem Statuscode 200 (»OK«) und sendet die angeforderten Inhalte.

Abbildung 17.95 Bei der Anmeldung mit einem noch gültigen Cookie sendet der Browser dieses beim HTTP GET-Request mit und kann sofort zugreifen.

.NET-Benutzer

Im Zusammenhang mit der formularbasierten Authentifizierung ist noch zu erwähnen, dass Entwickler nicht notwendigerweise eine eigene Datenbank für die Benutzerdaten entwickeln müssen. ASP.NET bietet bereits einige Möglichkeiten, die ich hier zwar nicht im Detail besprechen möchte (da zu anwendungspezifisch), auf die ich aber zumindest hinweisen möchte. In Abbildung 17.96 sehen Sie den typischen Konfigurationsoptionen-Dialog einer Webanwendung bzw. Website. Zu beachten sind:

  • Anbieter: Hier können Sie einen oder mehrere Anbieter konfigurieren, die sozusagen als Schnittstelle zwischen der Anwendung und der Datenbank, die Benutzer-, Rollen- und Profilinformationen speichern.
  • Mit der Konfigurationsoption Verbindungszeichenfolgen werden die Connection Strings zu einer oder mehreren Datenbanken konfiguriert und verwaltet.
  • .NET-Benutzer: Wie der Name vermuten lässt, werden hier die Benutzer verwaltet, die mittels eines Anbieters in eine Datenbank geschrieben werden.
  • .NET-Rollen: dito, aber für Rollen (z. B. Website-Leser).
  • .NET-Profile: speichern zusätzliche Angaben zu Benutzern und Rollen.

Abbildung 17.96 Im Zusammenhang mit der formularbasierten Authentifizierung sind unter Umständen die Konfigurationsoptionen ».NET-Benutzer«, ».NET-Profil«, ».NET-Rollen«, »Anbieter« und »Verbindungszeichenfolgen« interessant.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2010
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.


[Rheinwerk Computing]

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