Sharepoint mit ISA Server 2006
Arbeitsteilung
Der Microsoft Internet Security and Acceleration (ISA) Server 2006 kann als Frontend für Sharepoint dienen und ist dann in der Lage, Load Balancing, das Management von Wildcard-Zertifikaten oder Authentifizierung über Formulare zur Verfügung zu stellen.
Der Microsoft ISA Server 2006 umfasst eine Reihe neuer oder überarbeiteter Funktionen, sodass die Fähigkeiten der Software auf den Einsatz als Frontend für Sharepoint ausgeweitet worden sind. Auch ist es nun einfacher, den Server in dieser Rolle zu administrieren. Zu diesen Möglichkeiten gehört eine verbesserte Lastverteilung, einfacheres Server-Publishing, einfacheres Aufdecken von Redundanzen und anderes mehr.
Load Balancing für Web-Frontend-Server
Die Lastverteilung ermöglicht es einer Gruppe von Servern in einer Web-Farm, Anfragen für denselben Inhalt zu bearbeiten, sodass die Arbeitslast unter den Servern der Farm gleichmäßig verteilt wird. Unabhängig davon, ob eine Hardware- oder Softwarelösung eingesetzt wird, ist Load Balancing aus zwei Gründen in der Farmtopologie von grundlegender Bedeutung. Erstens verbessert diese Fähigkeit der Lastverteilung auf alle Server die allgemeine Performance und sorgt für Redundanz. Zweitens ist es dadurch einfacher möglich, die Farm zu skalieren, wenn die Arbeitslast steigt. Bei einer Sharepoint-Farm lässt sich dies durch das einfache Hinzufügen eines weiteren Web-Frontend-Servers erreichen. Dieser wird dann zu der Server-Gruppe in ISA-Server hinzugefügt und erhält seinen Anteil an der Arbeitslast.
Doch stellt die Verteilung des Verkehrs zwischen den Web-Servern lediglich eine Anforderung dar. Um das Load Balancing optimal durchzuführen, muss die Lösung auch ausgefallene oder Offline-Server aufspüren können, damit ein konsistentes und vorhersagbares Failover zustande kommt. Hängt der Web-Service beispielsweise auf einem bestimmten Server, so muss die Load-Balancing-Lö-sung in der Lage sein, diesen Ausfall zu erkennen und den betroffenen Server aus der Gruppe auszuschließen, um die Last auf die verbleibenden Server in der Farm zu verteilen. Das Aufspüren ist nicht einfach durch einen Heartbeat oder ein Ping zwischen dem Load Balancer und den einzelnen Farm-Servern zu bewerkstelligen, denn der Web-Service könnte sich aufgehängt haben und nicht antworten, der Server jedoch trotzdem auf das Ping reagieren.
Außerdem müssen die Web-Frontend-Server, sobald sie Online sind, der mit Load Balancing verwalteten Farm hinzugefügt werden, ohne aktuelle Client-Verbindungen zu tangieren. Aus diesem Grund muss die Load-Balancing-Lösung den Server in die allgemeine Arbeitslast der Farm nahtlos und transparent integrieren, unabhängig davon, ob der ausgefallene Server wieder online gebracht wird oder ein anderer Server als Ersatz implementiert wird.
Der ISA Server behandelt die Web-Frontend-Server in einer Sharepoint-Farm als eine einzelne Einheit. Setzt ein Administrator eine Web-Farm in einem ISA Server auf, so spezifiziert er entweder die IP-Adressen oder die Host-Namen der Server in der Farm. Gibt der Administrator die Host-Namen an, so muss der ISA Server in der Lage sein, diese in IP-Adressen der Ziel-Server umzuwandeln. Zusätzlich gibt der Verwalter die Methode an, die der ISA Server für das Monitoring der Server-Verbindungen innerhalb der Farm verwenden soll. Bild 1 zeigt, wie eine HTTP/HTTPS-GET-Anfrage genutzt werden kann, eine Ping-Anfrage gesendet oder eine TCP-Verbindung für jeden Server aufgesetzt wird. Die gewählte Methode gilt für alle Server in der Farm. Der ISA Server führt alle 30 Sekunden eine Überprüfung jedes Servers durch, mit einer voreingestellten Antwortzeit von 5 ms.
Wer findet den "gesunden Server"?
Die wahrscheinlich beste Methode für das Aufspüren der Gesundheit eines Servers in einer Sharepoint-Farm ist die Methode über HTTP/HTTPS GET, denn sie kann auch mit Situationen umgehen, in denen der Web-Service auf einem Ziel-Server ausgefallen ist, der Server aber auf Ping antwortet und auch eine TCP-Verbindung herstellen kann. Antwortet der Server auf GET-Anfragen, so bestehen gute Aussichten, dass der Server noch verfügbar ist und der Web-Service läuft.
Um die GET-Methode zu nutzen, gibt der Administrator eine URL an, die der ISA Server überprüft, und setzt vor die URL ein Sternchen (*), das den Server-Host-Namen repräsentiert. Angenommen etwa, eine Farm umfasst Web-Frontend-Server namens MOSSWFE01 und MOSSWFE02, und der Administrator will auf der obersten Ebene der Site testen. In einem solchen Fall gibt er eine URL der Form */default.aspx für das Testen der Verbindung beim Aufsetzen der Farm im ISA Server an. Beim Verbindungscheck für die Server ersetzt der ISA Server die Sternchen durch die Host-Namen und leitet die URLs moss wfe01/default.aspx sowie http:// mosswfe02/default.aspx für die Tests ab. Falls die Sharepoint-Konfiguration es erfordert, kann ein abgeänderter Host-Header in der URL spezifiziert werden.
Das Publizieren einer Sharepoint-Farm ist dank des Sharepoint Site Publishing Rule Wizards recht einfach. Doch bevor der Administrator den Wizard startet, muss er einige vorbereitende Schritte unternehmen:
– Er legt die Kommunikationsmethode zwischen ISA Server und der Farm fest. Dabei kann er entweder HTTP oder HTTPS nutzen, je nach Situation und Infrastruktur.
? Er legt die Mitglieder der Server-Farm fest und erzeugt optional das Server-Farm-Objekt. Die Mitglieder sind die Server, die in der Web-Server-Rolle in der Sharepoint-Farm laufen. Der Administrator kann das Server-Farm-Objekt erzeugen, bevor der Wizard gestartet wird, oder auch innerhalb des Wizards.
? Danach legt er die Settings des Web-Listeners fest. Der Web-Listener spezifiziert die Netzwerke und IP-Adressen des ISA Servers auf den Netzwerken, die auf externe Verbindungsanfragen warten. Außerdem legt er die Authentifizierungsmethode und Formulare fest, die Anzahl der erlaubten Verbindungen, die zu verwendenden Zertifikate, Single-Sign-on-Settings sowie eine Reihe weiterer Konfigurationen.
? Im nächsten Schritt legt der Administrator den Authentifizierungsmechanismus fest, den ISA Server dazu verwendet, um sich bei den Web-Servern zu authentifizieren. Werden alle Nutzer über das Active Directory authentifiziert, so genügt meistens NTLM. Doch kann er auch Kerberos oder NTLM nehmen, die Authentifizierung auf ausschließlich Kerberos beschränken, Basic-Authentifizierung nutzen oder keine Delegierung. Jede Methode hat optimale Anwendungsszenarien, sodass es sich empfiehlt, die Methode für die Anforderungen der Farm voraus zu planen.
? Schließlich muss er Alternativ-Settings angeben. Sie müssen zwar in Sharepoint nicht vorhanden sein, bevor der Wizard läuft, doch sind sie zwingend bevor die Farm eingeführt wird. Der Administrator muss Alternativen für das Zugriffs-Mapping in Sharepoint Central Administration angeben.
Nach diesen Entscheidungen und dem Aufsetzen der Web-Server kann die Farm publiziert werden. Um den Wizard zu starten, öffnet der Administrator die ISA-Server-Management-Konsole, klickt den Firewall-Policy-Node an und wählt New, Sharepoint Site Publishing Rule. Nach der Angabe eines Namens für die Regel und einem Klick auf Next, stellt der Wizard drei Optionen zur Verfügung, die in Bild 2 zu sehen sind:
? "Publish a single web site or load balancer?: Diese Option dient dazu, einen einzigen Web-Server zu publizieren oder eine mit einem Load Balancer verwaltete Farm, die hinter einem weiteren Load Balancer sitzt.
? "Publish a server farm of load balanced web servers?: Mit dieser Option lässt sich die Last einer Farm mithilfe des ISA Servers austarieren.
? "Publish multiple web sites?: Damit können mehrere Websites publiziert werden. Der Wizard erzeugt eine Regel für jede Site.
Der Administrator sollte die zweite Option wählen, wenn er den ISA Server für das Load Balancing der Web-Frontend-Server der Sharepoint-Farm nutzen will. Im Verlauf der Ausführung des Wizards muss der Administrator folgende Informationen liefern:
? Interne Publizierungsdetails: Der Administrator muss den internen Site-Namen für die Web-Farm angeben, der typischerweise der Name ist, den die Benutzer verwenden, wenn sie intern auf die Farm zugreifen.
? Spezifizieren der Server-Farm: Der Administrator kann ein vorhandenes Farmobjekt wählen oder ein neues erzeugen. Wenn er eine neue Farm aufsetzt, muss er den Namen des Farmobjekts angeben, den Namen oder die IP-Adresse jedes Servers in der Farm und die Monitoring-Methode, die der ISA Server nutzen wird, um die Verfügbarkeit einzelner Server in der Farm zu überwachen.
? Details zum öffentlichen Namen: Er gibt an, ob der ISA Server Anfragen für alle Domänen oder lediglich für eine bestimmte Domäne annimmt. Gibt er eine einzige Domäne an, so muss er den Fully Qualified Domain Name (FQDN) für die Farm eintragen.
? Auswahl des Web Listeners: Der Administrator wählt einen vorhandene Web Listener oder erzeugt einen neuen. Unabhängig von der gewählten Option kann er im Listener oder danach die Properties editieren.
? Delegierung der Authentifizierung: Der Administrator wählt eine Authentifizierungsmethode, die der ISA Server verwenden wird, um die Web-Farm zu authentifizieren.
? Eine alternative Konfiguration des Zugriffs-Mappings: Er gibt an, ob alternative Zugriffs-Mappings in der Sharepoint-Farm bereits konfiguriert sind.
? Benutzer-Sets: Der Administrator spezifiziert, wie die Publikationsregel angewendet werden soll. Standardmäßig wird sie auf alle authentifizierten Benutzer angewendet, doch können Benutzer-Sets nach Bedarf hinzugefügt, geändert oder gelöscht werden.
Um die Regeleinstellungen nach dem Aufsetzen anzusehen, kann der Systemverwalter den Firewall-Policy-Node öffnen und ein Doppelklick auf die Regel setzen. Er kann die Einstellungen nach Bedarf überprüfen und editieren sowie die Standardeinstellungen für die Regeln, die nicht über den Wizard vorgenommen wurden, etwa Schedule und Link-Übersetzung, modifizieren.
In den Properties für die Regel ist auch festgelegt, wie diese mit Client-Affinität umgeht, um sicherzustellen, dass derselbe Web-Frontend-Server alle Anfragen für einen bestimmten Client abwickelt. Über den Web-Farm-Tab kann der Administrator zwischen auf Cookies basierter (Session-Affinität) und Quell-IP-basierter (IP-Adressenaffinität) wählen. Session-Affinität liefert zuverlässigere Client-Affinität und empfiehlt sich für Sharepoint-Farmen.
Die Verwendung von Wildcard-Zertifikaten
Hostet eine Sharepoint-Farm mehrere Websites und müssen diese Sites mit SSL gesichert werden, so hat sich der Administrator zu entscheiden, ob er einzelne SSL-Zertifikate oder ein einziges Wildcard-Zertifikat hernimmt.
Ein SSL-Zertifikat umfasst einen allgemeinen Namen als eine der Properties. Der Namen muss dem Host-Header entsprechen, der vom Browser des Clients geliefert wird, anderenfalls kommt es zu einem Fehler. Beispielsweise sollte der allgemeine Name in einem Zertifikat für die Site www.contoso.com dann auch www.contoso.com lauten. Wird support.contoso.com auf dieselbe Site gemappt und geht ein Benutzer auf diese URL, erhält er eine Fehlermeldung, weil der Host-Header support.com nicht dem allgemeinen Namen im Zertifikat entspricht. Je nachdem, wie der Client-Browser konfiguriert ist, kann es vorkommen, dass der Client auf diese Site nicht zugreifen kann.
Ein Wildcard-Zertifikat ermöglicht es, ein einziges Zertifikat für mehrere Sites in einer Domäne zu nutzen. Anstatt eines allgemeinen Namens, der dem Site-Namen entspricht, nutzt das Wildcard-Zertifikat ein Sternchen im allgemeinen Namen statt des Host-Namens. Im obigen Beispiel wäre der allgemeine Name im Zertifikat *.contoso.com. Jede Site in der Domäne kann mit diesem Zertifikat bedient werden.
Beide Zertifikatstypen haben ihre Vorteile. Wenn es sich um eine geringe Anzahl gehosteter Sites handelt, so sind individuelle Zertifikate wahrscheinlich weniger teuer als Wildcard-Zertifikate. Doch mit steigender Zahl der Sites sollten die Kosten gegen den Administrationsaufwand abgewogen werden: Es ist einfacher, ein einzelnes Zertifikat zu verwalten. Auch können beliebige Sites ohne zusätzliche Zertifikate aufgesetzt werden, doch sind die Kosten für diesen Vorteil und die damit verbundene Flexibilität höher.
Um festzustellen, ob ein Wildcard-Zertifikat die richtige Wahl ist, sollte der Administrator die Kostendifferenz zwischen der Anzahl der gehosteten Sites und die individuellen Zertifikate und eines Wildcard-Zertifikats berechnen. Wenn beispielsweise individuelle Ein-Jahres-Zertifikate 995 Dollar kosten und ein Wildcard-Zertifikat 15.995 Dollar, so lohnt es sich nur, wenn mindestens 16 Sites zu hosten sind. Aber bei dieser Überlegung sollten auch künftige Entwicklungen in Betracht gezogen werden, sowie der bereits erwähnte Arbeitsaufwand. Ein Zertifikat ist nicht auf die Nutzung auf einem ISA Server beschränkt. Falls der Anwender sicheren Verkehr zwischen dem ISA Server und den Web-Frontend-Servern in der Sharepoint-Farm wünscht, kann er auch Zertifikate auf den Frontend-Servern installieren.
Um ein Wildcard-Zertifikat für das Publizieren von mehreren Websites mit einem einzigen Web Listener zu nutzen, muss der Administrator zuerst das Wildcard-Zertifikat erwerben und im Machine Store auf jedem ISA Server im Array installieren. Danach muss er den neuen Web Listener erzeugen, den er für das Publizieren der Sites verwenden will. Wird er im New Web Listener Definition Wizard aufgefordert, die Zertifikate auszuwählen, so nimmt er die Option "Use a single certificate for this Web Listener" und wählt dann das Wildcard-Zertifikat.
Formularbasierende Authentifizierung
Diese Form der Authentifizierung nutzt HTML-Formulare, die ISA Server 2006 für publizierte Sharepoint-Server unterstützt. Er liefert drei Formular-Sets: HTML für Standard-Browser und Compact HTML (cHTML) sowie Extensible HTML (XHTML) für mobile Browser. Der ISA Server bringt das entsprechende Formular auf der Basis des User Agent Headers, den der Client schickt. Außerdem unterstützt der Server drei Arten von auf Formularen basierter Authentifizierung:
? Kennwörter: Der Nutzer gibt den Benutzernamen und das Kennwort ein. Diese Art unterstützt AD-, LDAP- und RADIUS-Authentifizierung (Remote Authentication Dial-In User Service).
? Passcode: Der Nutzer gibt den Benutzernamen und den Passcode ein, etwa ein Einmalkennwort, wie sie von Sicherheits-Token-Geräten generiert werden. Dieser Authentifizierungstyp unterstützt SecurID- und RADIUS-Authentifizierung mit Einmal-Kennwörtern.
? Passcode/Passwort: Der Nutzer gibt den Benutzernamen und das Kennwort sowie den Benutzernamen und den Passcode ein. Die Kombination Benutzername und Passcode wird für die Authentifizierung am ISA Server mit SecurID und RADIUS verwendet und Benutzername mit Kennwort für die Delegation.
Die Formulare für Sharepoint sind im Ordner \CookieAuthTemplates\ISA zu finden. Dieser enthält drei Unterordner, jeweils einen für HTML-, cHTML- und XHTML-Formulare. Der Administrator kann die Formulare nach der Corporate Identity anpassen oder ihnen Funktionalität wie etwa eine Benachrichtigung für das Logon-Formular hinzufügen. Sie beinhalten auch Input- und Formular-Tags sowie Platzhalter. Diese Elemente müssen intakt bleiben. Doch kann der Administrator die Datei logon_style.css so modifizieren, dass die Hintergrundfarbe der Seite und des Formulars sich ändert, der Font oder andere visuelle Charakteristiken. Auch lässt sich die Datei strings.txt modifizieren, um den Text im Formular zu ändern oder neuen hinzuzufügen. Um Text hinzu zu fügen, muss der Administrator einen neuen Platzhalter in die html-Datei des Formulars einfügen und dann einen entsprechenden Eintrag in strings.txt mit demselben Platzhalter vornehmen. Der ISA Server ersetzt den Platzhalter mit dem Text, wenn er das Formular anzeigt.
Einfaches Ändern von Grafiken
Auch lassen sich Grafiken ändern oder hinzufügen, etwa das Unternehmens-Logo in das Logon-Formular mit einbinden. Die Grafiken, die der ISA Server nutzt, sind standardmäßig in demselben Ordner wie die .htm-Dateien. Das Ändern der Grafiken ist genauso einfach wie das Ersetzen in den eigenen Dateien. Es müssen lediglich die .htm-Dateien modifiziert werden. Zusätzlich kann der Systemverwalter ein eigenes Formular-Set erzeugen, sodass einige Web-Listener das Standard-Set nutzen und andere das eigene. Im ersten Schritt erzeugt der Administrator dafür einen neuen Ordner in CookieAuthTemplates. Dann kopiert er alle Dateien aus dem entsprechenden Standard-Formularordner (etwa HTML) in den neuen Ordner. Schließlich ändert er die Formulare im neuen Ordner nach seinen Wünschen. Um das neue Formular-Set nutzen zu können, erzeugt er einen Web Listener, öffnet die Properties für den Web-Listener und klickt auf den Formular-Tab. Dann wählt er die Option für die Nutzung eigener HTML-Formulare und gibt das Verzeichnis dafür an. Nutzt er ein ISA Server Array, so muss der Ordner für das angepasste Set auf allen Servern des Arrays vorhanden sein. Auf dieser Property-Seite gibt es noch einige andere Optionen für die Authentifizierung mit Formularen. Aktiviert der Administrator die Option, die den Benutzern erlaubt, ihre Kennwörter zu ändern, so bietet der ISA Server diese Option beim Logon an. Zusätzlich könnte der ISA Server die Nutzer auch benachrichtigen, wenn ihre Kennwörter kurz vor dem Ablaufen stehen. Nach der Änderung der Formular-Dateien muss der Firewall-Service neu gestartet werden, damit die Änderungen in Kraft treten.
Die Authentifizierung über Formulare, wie sie hier für den ISA Server beschrieben ist, unterscheidet sich von der, die für Sharepoint als optionaler Authentifizierungs-Provider angeboten wird. Letztere liefert einen Mechanismus, um Credentials in einer SQL-Server-Datenbank zu speichern statt in AD. Außerdem präsentiert sie ein Formular, dass diese Credentials vom Nutzer während des Logons an Sharepoint fordert.
Fazit: Robuste Lösung für die Sharepoint-Farm
Das Verständnis darüber, wie der ISA Server als Frontend für Sharepoint fungieren kann, bietet die Möglichkeit einer robusten Lösung für das Load Balancing in einer Sharepoint-Farm. Unter anderem lässt sich darüber sicher stellen, dass der Server Ausfälle dann erkennt, wenn sie passieren, und auch eine entsprechende Reaktion bereit hat.
Lesen Sie mehr zum Thema
