Überlegungen zum Aktualisieren auf Windows Server 2003

Servercluster: Bewährte Sicherheitsmethoden für
Windows 2000 und Windows Server 2003
(Engl. Originaltitel: Server Clusters: Security Best Practices for Windows 2000 and Windows
Server 2003)
Microsoft Corporation
Veröffentlicht: Januar 2003
Zusammenfassung
Dieses Dokument beschreibt bewährte Sicherheitsmethoden für Servercluster. Es enthält
Richtlinien und Best Practices für Windows 2000 und Windows Server 2003, die sich auf die
Verwaltung, den Betrieb und das Schreiben von Anwendungen für Servercluster beziehen.
Das Dokument ist in zwei Abschnitte unterteilt. Diese behandeln Sicherheitsmethoden für
Administratoren, die Servercluster bereitstellen und verwalten, sowie für Entwickler, die
clusterfähige Anwendungen erstellen, oder Anwendungen entwickeln, die auf einem Cluster
bereitgestellt werden sollen.
Allgemeine Voraussetzungen
Es gibt eine Vielzahl von allgemeinen Voraussetzungen und bewährten Betriebsmethoden,
die für die Infrastruktur vorhanden sein sollten, um eine sichere Umgebung zur Ausführung
der Servercluster zu gewährleisten.
1. Server und Speicher befinden sich an physikalisch sicheren Orten.
2. Praktische Sicherheitsimplementierungen zur Erkennung von unregelmäßigem
Datenverkehr sind vorhanden, wie z. B. Firewalls, Netzwerkuntersuchungen und
Verwaltungsprogramme.
3. Sinnvolle Verfahrensweisen/gesunder Menschenverstand im Hinblick auf Sicherheit
werden/wird in Bereichen wie Verwaltung, Protokollspeicherung, Sicherung und
Wiederherstellung usw. eingehalten.
4. Bewährte Sicherheitsmethoden auf Plattformebene werden im Hinblick auf die
Zuweisung administrativer Berechtigungen, die ACL-Erfassung von Ressourcen und
andere Verwaltungsfunktionen eingehalten.
5. Die Netzwerkinfrastrukturdienste, wie Active Directory™, DNS, DHCP, WINS usw.
müssen sicher sein. Jede Gefährdung dieser Infrastrukturdienste kann zu einer
Gefährdung des Clusterdienstes führen.
6. Der Clusteradministrator muss sicherstellen, dass Anwendungen zum Aufrufen der
Cluster-APIs (ClusAPI) auf vertrauenswürdigen Computern ausgeführt werden. Jede
Gefährdung der Computer, auf denen die (vom Clusteradministrator ausgeführten)
Anwendungen ausgeführt werden, kann auch den Cluster gefährden. Wenn
beispielsweise nicht vertrauenswürdige Benutzer mit erhöhten Berechtigungen an der
Arbeitsstation tätig sind, auf der die Verwaltungsprogramme ausgeführt werden, kann
der Clusteradministrator nicht vertrauenswürdigen oder bösartigen Code ausführen,
ohne dies zu bemerken.
7. Der Zugriff auf den vom Clusterdienst erstellten und verwalteten Satz von Objekten
darf nicht dadurch gefährdet werden, dass die Standardeinstellungen für diese Objekte
auf einen weniger restriktiven Wert geändert werden. Der Clusterdienst verwendet
einen Satz von Objekten des Betriebssystems, wie z. B. Dateien, Geräte,
Registrierungsschlüssel usw. Diese Objekte verfügen über eine
Standardsicherheitseinstellung, die dafür sorgt, dass unberechtigte Benutzer die
Clusterkonfiguration oder die auf dem Cluster ausgeführten Anwendungen nicht
beeinflussen können. Eine Änderung dieser Sicherheitseinstellungen auf weniger
restriktive Werte kann zu einer Gefährdung des Clusters und einer Beschädigung der
Anwendungsdaten führen.
Bereitstellung und Betriebsmanagement
Clusteradministratoren
Administratoren können Gruppen oder Einzelpersonen angeben, die den Cluster verwalten
dürfen. In aktuellen Versionen des Serverclusters gibt es keine granulare Steuerung; entweder
verfügt ein Benutzer über die Berechtigungen zum Verwalten des Clusters, oder er besitzt
diese Berechtigungen nicht. Um einem Benutzer oder einer Gruppe Berechtigungen zum
Verwalten des Clusters zu erteilen, muss dieser bzw. diese zur Clustersicherheitsbeschreibung
hinzugefügt werden. Dies kann entweder vom Clusteradministrator, oder mit Hilfe des
Befehlszeilentools cluster.exe ausgeführt werden.
Anmerkung: Abgesehen von der lokalen Gruppe Administratoren auf einem Knoten
MÜSSEN alle anderen Mitglieder der Clustersicherheitskonfiguration entweder
Domänenbenutzerkonten oder globale Gruppen sein. Auf diese Weise soll sichergestellt
werden, dass dasselbe, genau definierte und autorisierte Konto auf sämtlichen Knoten im
Cluster verwendet wird.
Standardmäßig wird die lokale Gruppe Administratoren zur Sicherheitsbeschreibung des
Clusterdienstes hinzugefügt.
Das Hinzufügen eines Benutzers oder einer Gruppe zur Clustersicherheitsbeschreibung
bedeutet, dass der Benutzer alle Aspekte der Clusterkonfiguration verwalten kann,
einschließlich (aber nicht beschränkt auf):




Offline- und Onlineschalten von Ressourcen
Beenden des Clusterdienstes auf Knoten
Hinzufügen von Knoten zum Cluster und Entfernen aus dem Cluster
Hinzufügen von Ressourcen zum Cluster und Entfernen aus dem Cluster
Wegen des Ausmaßes der Auswirkungen auf die im Cluster ausgeführten Anwendungen und
Dienste muss beim Hinzufügen eines Benutzers zur Clustersicherheitsbeschreibung besonders
vorsichtig vorgegangen werden.
Der Clusterdienst führt den einer Ressource zugeordneten Code unter seinem
Domänenbenutzerkonto aus (das nicht mit dem für die Verwaltung des Clusters verwendeten
Konto verwechselt werden sollte). Da ein Clusteradministrator neue Ressourcen zu einem
Cluster hinzufügen kann und diese Ressourcen als Clusterdienstkonto ausgeführt werden,
kann ein Clusteradministrator Code installieren, der mit lokalen Administratorrechten auf
dem Computer ausgeführt wird.
Sinnvolle Verfahrensweisen


Clusteradministratoren sollten ein anderes Konto als das Clusterdienstkonto zum
Verwalten des Clusters verwenden. Dies bietet die Möglichkeit, unterschiedliche
Richtlinien (z. B. zum Kennwortablauf) auf das Clusterdienstkonto und die zum
Verwalten des Clusters verwendeten Domänenkonten getrennt anzuwenden.
Sie sollten nur Benutzer mit lokalen Administratorrechten zur Sicherheitsbeschreibung
des Clusterdienstes hinzufügen.
Anmerkung: Wird ein Domänenbenutzer oder eine globale Gruppe zur
lokalen Gruppe Administratoren hinzugefügt, so wird diese Gruppe bzw.
dieses Konto automatisch zu einem Clusteradministrator.

Entfernen Sie die lokale Gruppe Administratoren nicht aus der
Sicherheitskonfiguration des Clusterdienstes.
Remoteverwaltung und -konfiguration von Clustern
Verwaltungsprogramme oder andere Anwendungen, welche die Servercluster-APIs (ClusAPI)
aufrufen, können auf Remotearbeitsstationen ausgeführt werden. Dabei muss der
Clusteradministrator sicherstellen, dass die Anwendungen auf vertrauenswürdigen Computern
ausgeführt werden. Jede Gefährdung der Computer, auf denen die (vom Clusteradministrator
ausgeführten) Anwendungen ausgeführt werden, kann auch den Cluster gefährden.
Wenn ein Cluster erstellt oder die Konfiguration geändert wird (z. B. durch Hinzufügen eines
neuen Clusterknotens), erstellt der Clusterkonfigurations-Assistent eine Protokolldatei auf
dem Computer, auf dem er ausgeführt wird. Damit kann der Administrator das Protokoll im
Fall von Fehlern zum Debuggen und für die Problembehandlung verwenden. Die
Protokolldatei kann Clusterkonfigurationsdaten enthalten, z. B. Cluster-IP-Adressen,
Netzwerknamen usw. Mit diesen Daten könnte die Angriffsfläche vergrößert werden, wenn
sie von nicht autorisierten Benutzern gelesen werden.
Clusterdienstkonto
Beim Clusterdienstkonto handelt es sich um das Konto, unter dem der Clusterdienst gestartet
wird. Die Anmeldeinformationen für dieses Konto werden im Dienststeuerungs-Manager
(Service Control Manager oder SCM) gespeichert. Hierbei handelt es sich um die Windows®Komponente, die beim Start der Clusterknoten für das Starten des Clusterdienstes
verantwortlich ist.
Auf allen Knoten eines Clusters muss dasselbe Clusterdienstkonto verwendet werden – ein
Konto auf Domänenebene, das außerdem über lokale Administratorrechte für jeden Knoten
im Cluster verfügt. Das Domänenkonto muss vor Erstellung des Clusters existieren; der
Clusterkonfigurations-Assistent fordert Sie zur Eingabe des Kontos auf, das verwendet
werden soll. Wenn das Konto nicht bereits ein Mitglied der lokalen Gruppe Administratoren
ist, wird es vom Clusterkonfigurations-Assistenten beim Erstellen des Clusters automatisch zu
dieser Gruppe hinzugefügt. Ebenso wird das Clusterdienstkonto beim Hinzufügen von Knoten
zum Cluster zur lokalen Gruppe Administratoren hinzugefügt. Wenn ein Knoten aus einem
Cluster entfernt wird, bleibt das Clusterdienstkonto in der lokalen Gruppe Administratoren
erhalten.
Sie müssen sich dieser Semantik bewusst sein, wenn Sie vermeiden möchten, dass einem
Domänenkonto unbeabsichtigt lokale Administratorrechte für einen bestimmten Knotensatz
erteilt werden.
Anmerkung: Durch das Entfernen eines Knotens aus einem Cluster wird das
Clusterdienstkonto NICHT aus der lokalen Gruppe Administratoren entfernt. Wenn Sie
einen Knoten aus dem Cluster entfernt haben, sollten Sie das Clusterdienstkonto manuell aus
der lokalen Gruppe Administratoren entfernen. Auf diese Weise vermeiden Sie veraltete
Konten mit lokalen Administratorrechten für einen Computer.
Die Knoten in einem Servercluster stellen über authentifizierte Kommunikationsmechanismen
sicher, dass nur gültige Mitglieder des Clusters die clusterinternen Protokolle verwenden
können. Es ist äußerst wichtig, dass jeder Knoten im Cluster über dasselbe Clusterdienstkonto
verfügt, um Authentifizierungskonsistenz zu ermöglichen. Das in Microsoft® Windows
Server 2003 eingeführte Hilfsprogramm für Clusterdienstkonto-Kennwörter erfordert
zwingend die Verwendung von gleichen Clusterdienstkonten.
Erforderliche Berechtigungen
Das Clusterdienstkonto muss sowohl ein Mitglied der lokalen Gruppe Administratoren sein,
als auch über einen Satz zusätzlicher, lokal erteilter Berechtigungen verfügen. Diese sind:








Einsetzen als Teil des Betriebssystems (erforderlich für Windows 2000 oder höher).
Sichern von Dateien und Verzeichnissen.
Anheben von Quoten.
Anheben der Zeitplanungspriorität.
Laden und Entfernen von Gerätetreibern.
Sperren von Seiten im Speicher.
Als Dienst anmelden.
Wiederherstellen von Dateien und Verzeichnissen.
Sie sollten KEINE dieser Berechtigungen aus dem Clusterdienstkonto entfernen. Wenn Sie
eine oder mehrere dieser erforderlichen Berechtigungen entfernen, kann der Clusterdienst
möglicherweise nicht mehr gestartet werden, oder er funktioniert nicht ordnungsgemäß.
Während des Installationsvorgangs für den Clusterserver werden diese Berechtigungen dem
Konto lokal erteilt. Wenn das Clusterdienstkonto zu irgendeinem Zeitpunkt erneut manuell
erstellt werden muss, müssen Sie auch diese zusätzlichen Berechtigungen erteilen. Im
englischsprachigen KB-Artikel 269229: How to Manually Re-Create the Cluster Service
Account (englischsprachig) werden die erforderlichen Schritte zum erneuten Erstellen des
Clusterdienstkontos beschrieben.
Kennwortrichtlinien
Das Clusterdienstkonto besitzt, genauso wie jedes anderes Domänenkonto, ein Kennwort,
dem Richtlinien zum Kennwortablauf zugeordnet sein können. Wenn dem Kennwort für das
Clusterdienstkonto Ablaufrichtlinien zugewiesen wurden, muss es vor Erreichen des
Ablaufdatums geändert werden. Wird diese Änderung nicht rechtzeitig vorgenommen,
funktioniert der Cluster nach dem Kennwortablauf nicht mehr, da die clusterinterne
Kommunikation nicht mehr erfolgreich authentifiziert werden kann.
Ändern des Kennworts
In den meisten Produktionsumgebungen besitzen Domänenkonten Richtlinien zum
Kennwortablauf, die eine relativ häufige Änderung des Kennworts (z. B. alle 30 Tage)
erzwingen. Die Änderung des Kennworts für das Clusterdienstkonto muss sorgfältig geplant
werden.
Windows 2000
Das Clusterdienstkonto auf ALLEN Knoten im Cluster muss übereinstimmen, um
sicherzustellen, dass die clusterinterne Kommunikation erfolgreich authentifiziert werden
kann. Der Clusterdienst selbst sendet Nachrichten zwischen Clusterknoten auf viele
verschiedene Arten. Wenn eine dieser Kommunikationen fehlschlägt, wird der Clusterknoten
aus dem Cluster entfernt (und damit der Clusterdienst beendet). Es lässt sich nicht ermitteln,
wann der Clusterdienst die Kommunikation einrichtet. Deshalb gibt es kein eindeutiges
Verfahren, mit dem das Clusterdienstkonto zuverlässig geändert und gleichzeitig
sichergestellt werden kann, dass der Cluster weiterhin ausgeführt wird.
Unter Windows 2000 kann das Kennwort für das Clusterkonto nur über die folgenden Schritte
zuverlässig geändert werden:
1. Beenden des Clusterdienstes auf ALLEN Clusterknoten
2. Ändern des Kennworts für das Clusterdienstkonto auf dem Domänencontroller
3. Aktualisieren des Kennworts für den Dienststeuerungs-Manager auf ALLEN
Clusterknoten
4. Erneutes Starten des Clusterdienstes auf ALLEN Clusterknoten
Windows Server 2003
Mit dem Tool cluster.exe unter Windows Server 2003 kann das Kennwort für das
Clusterkonto dynamisch geändert werden, ohne dass der Clusterdienst auf einem der Knoten
beendet werden muss. Cluster.exe ändert das Kennwort für das Domänenkonto und
aktualisiert die Kontoinformationen des Dienststeuerungs-Managers auf allen Knoten im
Cluster.
Anmerkung: Dieser Befehl funktioniert nur bei Windows Server 2003-Knoten. Wenn der
Cluster auch Windows 2000-Knoten enthält, wird das Kennwort für das Clusterdienstkonto
nicht geändert.
Cluster /cluster:Clustername1[,Clustername2,…]
/changepassword[:neues_Kennwort[,altes_Kennwort]] [/skipdc] [/force]
[/Optionen]
Die Befehlsargumente haben folgende Bedeutungen:
Argument
cluster:Clustername1
[,Clustername2,…]
/changepassword
[:neues_Kennwort
[,altes_Kennwort]]
Beschreibung
Identifiziert den/die Cluster für die Änderung des
Kontokennworts. Wenn mehrere Cluster angegeben werden,
müssen sie dasselbe Clusterdienstkonto verwenden. Falls
einige Knoten nicht verfügbar sind, wird das Kennwort auf
keinem der Knoten oder dem Domänencontroller geändert.
Ändert das Kennwort für das Clusterdienstkonto auf dem
Domänencontroller und allen Clusterknoten von
„altes_Kennwort“ in „neues_Kennwort“. Wenn Sie keine
Kennwörter in die Befehlszeile eingeben, werden Sie zur
Kennworteingabe aufgefordert.
Ändert das Kennwort für das Clusterdienstkonto nur auf den
Clusterknoten.
Erzwingt die Ausführung der Kennwortänderung auf den
verfügbaren Knoten sogar dann, wenn einige Knoten nicht
verfügbar sind.
Anmerkung: Das Kennwort auf nicht verfügbaren Knoten
wird nicht aktualisiert. Diese Knoten können dem Cluster erst
dann beitreten, wenn das Kennwort für das Clusterdienstkonto
über die Computerverwaltung manuell aktualisiert wurde.
/skipdc
/force
Die Details des Befehls sind in der Onlinehilfe dokumentiert. Auf diese kann
Clusterverwaltungsprogramm zugegriffen werden.
Sinnvolle Verfahrensweisen




Das Clusterdienstkonto sollte KEIN Domänenadministratorkonto sein.
 Allen Konten sollten die möglichen Mindestrechte und -berechtigungen erteilt
werden, um bei einer Gefährdung eines bestimmten Kontos potenzielle
Sicherheitsprobleme zu vermeiden.
 Verwenden Sie die Delegierung, um bestimmten Konten auf ALLEN Knoten
eines Clusters Administratorrechte zu erteilen.
Wenn eine einzelne Domäne mehrere Cluster enthält, erleichtert die Verwendung
desselben Clusterdienstkontos auf allen Knoten die Verwaltung.
 Sie müssen die vereinfachte Verwaltung gegen die potenziellen
Sicherheitsrisiken abwägen, die mit der Verwendung eines einzigen Kontos für
viele Cluster verbunden sind. Wenn das Konto gefährdet ist, hängt das
Ausmaß der Auswirkungen davon ab, wie viele Cluster dieses verwenden.
 Unter Windows Server 2003 kann das Kennwort für das Clusterdienstkonto
auf mehreren Clustern gleichzeitig geändert werden.
Wenn Sie Richtlinien für den Kennwortablauf bei den Clusterdienstkonten festgelegt
haben, sollten Sie dieses Konto NICHT für andere Dienste verwenden.
 Verwenden Sie das Clusterdienstkonto beispielsweise nicht für
SQL Server 2000 oder Exchange 2000, wenn Sie Richtlinien für den
Kennwortablauf festgelegt haben. Falls mehrere Dienste dasselbe Konto
verwenden, ist die Koordination der Kennwortänderung beim Clusterdienst
und bei anderen Diensten komplex und führt dazu, dass der komplette Cluster
und/oder Dienst während einer Kennwortrotation nicht verfügbar ist. Besser ist
es, über ein dediziertes Konto für jeden Dienst zu verfügen, das jeweils
unabhängig verwaltet werden kann.
 Unter Windows Server 2003 kann das Kennwort für das Clusterdienstkonto
nur dann online ohne Herunterfahren des Clusters geändert werden, wenn
keine Dienste dasselbe Konto verwenden.
Zum Ändern des Kennworts für das Clusterdienstkonto unter Windows 2000 muss der
Cluster vor der Änderung vollständig heruntergefahren werden. Das Herunterfahren
und erneute Starten des Clusters bedeutet möglicherweise, dass dieser die
Verfügbarkeitsanforderungen nicht erfüllen kann. Beispielsweise erfordert eine
Betriebszeit von 99,999 % weniger als fünf Minuten Ausfallzeit pro Jahr für die
Anwendungen und Dienste. Dieser Grad der Verfügbarkeit kann nicht erzielt werden,
wenn der Cluster zur Kennwortrotation heruntergefahren wird. In Umgebungen mit


hoher Verfügbarkeit sollte unter Windows 2000 eine Richtlinie für das
Clusterdienstkonto festlegen, dass das Kennwort niemals abläuft.
Unter Windows 2000 SP3 und Windows Server 2003 kann der Clusterdienst virtuelle
Server als Computerobjekte in Active Directory veröffentlichen. Zur Sicherstellung
des einwandfreien Betriebs sollte das Clusterdienstkonto über die entsprechenden
Rechte oder Berechtigungen verfügen, die notwendig sind um diese Objekte im
Container Active Directory Computers erstellen und bearbeiten zu können.
Weitere Informationen finden Sie im Abschnitt Verwenden der KerberosAuthentifizierung in einem Servercluster.
Wenn Sie mehrere Cluster unter Verwendung unterschiedlicher Clusterdienstkonten
bereitstellen möchten, sollten Sie eine globale oder universelle Gruppe erstellen, die
alle Richtlinien implementiert und über alle vorstehend beschriebenen Berechtigungen
verfügt. Jedes Clusterdienstkonto sollte dann in die Gruppe einbezogen werden.
 Dies vereinfacht die Verwaltung der Clusterdienstkonten, indem ein einziger
Container für alle diese Konten und eine einzige zentrale Stelle für die
Änderung der Kontorichtlinien bereitgestellt wird.
Verwenden der Kerberos-Authentifizierung in einem
Servercluster
Die Kerberos-Authentifizierung wurde als Teil der Windows-Plattform mit Windows 2000
eingeführt. Sie ist der primäre Standardsicherheitsmechanismus für die sich
weiterentwickelnde Windows-Plattform und bietet etliche Vorteile gegenüber den früheren
Authentifizierungsmechanismen (wie z. B. NTLM).



Sie ermöglicht gegenseitige Authentifizierung von Client und Server: Der Server
stellt sicher, dass der Client Zugriff auf die dort bereitgestellten Dienste oder
Anwendungen hat. Für den Client wird gewährleistet, dass er tatsächlich mit dem
erwarteten Server kommuniziert.
Sie erlaubt die Delegierung der Authentifizierung auf mehrere Computer: Sie
erlaubt den End-to-End-Identitätswechsel auf der Grundlage der
Anmeldeinformationen, die mit der ursprünglichen Anforderung in einer
Anwendungsbereitstellung auf mehreren Ebenen verbunden sind. So kann eine
Website beispielsweise ein IIS-Webserver-Front-End, Geschäftsobjekte der mittleren
Ebene sowie ein Datenbank-Back-End enthalten. Kerberos ermöglicht es, dass die
Original-Clientauthentifizierung über alle Ebenen vom Webserver bis zur Datenbank
als End-to-End-Authentifizierung und -Autorisierung erfolgt.
Sie stellt einen Industriestandard dar, der einen gemeinsamen
Authentifizierungsmechanismus über mehrere Plattformen hinweg ermöglicht.
Weitere Informationen zu Kerberos und dessen Funktionsweise finden Sie auf folgender
TechNet-Webseite:
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/tcevents/itevents/kerber
os.asp
In einem Servercluster werden Anwendungen auf virtuellen Servern bereitgestellt. Bei einem
virtuellen Server handelt es sich um eine Servercluster-Ressourcengruppe, die eine IPAdressressource und eine Netzwerknamenressource, sowie alle für einen bestimmten Dienst
oder eine bestimmte Anwendung erforderlichen Ressourcen enthält. Clients stellen eine
Verbindung zum Clusterdienst über die dem Dienst zugeordnete IP-Adresse, bzw. den ihm
zugeordneten Netzwerknamen her. Wenn eine Anwendung einen Failover von einem Knoten
auf einen anderen Knoten durchführt, führen auch die IP-Adress- und die
Netzwerknamenressource einen Failover durch. Folglich verwendet der Client weiterhin das
gleiche Ziel für einen Dienst oder eine Anwendung – unabhängig davon, auf welchem
Computer im Cluster er momentan gehostet wird.
Bei Serverclustern unter Windows 2000 (bis SP2) ist NTLM der einzige verfügbare
Mechanismus für die Authentifizierung eines Clients durch einen virtuellen Servernamen.
Deshalb stehen die Vorteile von Kerberos nicht zur Verfügung.
Unter Windows 2000 SP3 und Windows Server 2003 ist die Kerberos-Authentifizierung für
Clusterserveranwendungen verfügbar und ermöglicht so einen End-to-End-Identitätswechsel
bei einer hohen Verfügbarkeit.
Computerobjekte virtueller Server
Für die Kerberos-Authentifizierung ist ein Computerobjekt (CO) erforderlich, das in
Active Directory veröffentlicht werden muss. Unter Windows 2000 SP3 oder höher verfügt
die Netzwerknamenressource des Clusters über die Fähigkeit zur Veröffentlichung eines
Computerobjekts für virtuelle Server in Active Directory. Dies wird über die neue
Ressourceneigenschaft RequireKerberos mit folgenden Werten gesteuert:


RequireKerberos = 0
Die Netzwerknamenressource erstellt in Active Directory kein Objekt. Sie stellt die
gleiche Semantik wie unter Windows 2000 (bis SP2) bereit. Dieser Wert ist der
Standardwert für Abwärtskompatibilität, sowie für die Sicherstellung des
ordnungsgemäßen Verhaltens während paralleler Updates1.
RequireKerberos = 1
Die Netzwerknamenressource erstellt in Active Directory ein Objekt und ermöglicht
so die Kerberos-Authentifizierung durch den Namen des virtuellen Servercomputers.
Die vollständige Semantik für diese Eigenschaft wird weiter unten in diesem Abschnitt
beschrieben.
Anmerkung: Obwohl die Netzwerknamenressource ein Computerobjekt in Active Directory
veröffentlicht, sollte dieses Objekt NICHT für Verwaltungsaufgaben, z. B. das Anwenden
von Gruppenrichtlinien, verwendet werden. Die EINZIGE Rolle für das Computerobjekt
virtueller Server unter Windows 2000 und Windows Server 2003 besteht darin, der KerberosAuthentifizierung und -Delegierung sowie cluster- und Active Directory-fähigen Diensten
(z. B. MSMQ) das Veröffentlichen von Dienstanbieterinformationen zu ermöglichen.
Lebensdauer eines Computerobjekts
Die Netzwerknamenressource steuert das Erstellen und Löschen von Computerobjekten
aufgrund einer Reihe von Faktoren wie z. B. den Eigenschaftseinstellungen und der
Lebensdauer der Ressource.
Erstellen von Computerobjekten
Die Netzwerknamenressource erstellt ein Computerobjekt, wenn die Ressourceneigenschaft
RequireKerberos auf 1 festgelegt wird (der Standardwert lautet 0). Für die Festlegung dieses
Wertes auf 1 muss das Clusterdienstkonto auf Active Directory zugreifen können. Dazu muss
es entweder über die Berechtigung Hinzufügen von Arbeitsstationen zur Domäne
verfügen, oder ihm muss spezifischer Zugriff auf Active Directory erteilt werden. Wenn das
Konto über keinen Zugriff verfügt, kann die Netzwerknamenressource nicht online geschaltet
werden.
Domänenadministratoren können Computerobjekte für virtuelle Server vorbereiten (ggf. in
einer getrennten OU) und so das Erteilen der Berechtigung Hinzufügen von
Arbeitsstationen zur Domäne an das Clusterkonto vermeiden. In diesem Fall muss das
Computerobjekt über eine Zugriffssteuerungsliste (Access Control List oder ACL) verfügen,
die es dem Clusterdienstkonto ermöglicht, das Kennwort zurückzusetzen sowie in die
Attribute vom Typ DnsHostName und ServicePrincipalName zu schreiben (die individuelle
Zugriffsrechte besitzen).
Wenn ein „verwaistes“ Computerobjekt oder ein vom Domänenadministrator erstelltes
Computerobjekt in Active Directory mit dem Namen des virtuellen Computers vorhanden ist,
das Clusterdienstkonto über die erforderlichen Zugriffsrechte für das Objekt verfügt und das
Objekt nicht deaktiviert ist, verwendet die Netzwerknamenressource das bestehende
Computerobjekt. Das gleiche passiert zum Beispiel, wenn ein neuer Computer zu einer
Domäne hinzugefügt wird, die ein altes, nicht verwendetes Computerobjekt mit dem gleichen
Namen enthält.
Die Netzwerknamenressource legt das DnsHostName-Attribut des Computerobjekts auf den
vollqualifizierten DNS-Namen ihrer Name-Eigenschaft und das primäre DNS-Suffix des
Knotens2 fest.
Deaktivieren von Computerobjekten
Computerobjekte werden deaktiviert, wenn entweder die Kerberos-Authentifizierung nicht
mehr erforderlich ist (die RequireKerberos-Eigenschaft von 1 in 0 geändert wurde), oder
wenn die Ressource selbst gelöscht wurde. Wenn das Computerobjekt zwar weiterhin
vorhanden ist, aber die Netzwerknamenressource ohne aktivierte Kerberos-Authentifizierung
online geschaltet wird, schlägt die Clientauthentifizierung fehl. Beim Entfernen der KerberosAuthentifizierung von einer Netzwerknamenressource muss der Systemadministrator explizit
entscheiden, dass das entsprechende Computerobjekt gelöscht werden soll. Beachten Sie, dass
Active Directory-fähige Anwendungen, die auf dem virtuellen Server gehostet werden (wie
z. B. Exchange Server und MSMQ), möglicherweise eigene Informationen mit dem
Computerobjekt verknüpft haben. Wenn das Computerobjekt gelöscht wird, werden diese
Eigenschaften ebenfalls gelöscht, und die Anwendungen funktionieren eventuell nicht mehr
ordnungsgemäß. Daher sollte mit größter Vorsicht vorgegangen werden, wenn die KerberosAuthentifizierung von einem Netzwerknamen entfernt wird.
Wenn die Netzwerknamenressource gelöscht, oder die Kerberos-Authentifizierung entfernt
wurde, versucht diese Ressource ein einziges Mal, das Computerobjekt zu deaktivieren.
Sämtliche Vorgänge zur Deaktivierung werden zusammen mit dem letzten Status in den
Cluster- und Systemereignisprotokollen aufgezeichnet. Wenn die Deaktivierung des
Computerobjekts aus irgendeinem Grund fehlschlägt, wird kein weiterer
Deaktivierungsversuch unternommen.
Umbenennen von Computerobjekten
Das Computerobjekt ist mit dem von der Netzwerknamenressource veröffentlichten Namen
des virtuellen Netzwerks eng verbunden. Wenn die Name-Eigenschaft der
Netzwerknamenressource geändert wird, muss diese Änderung in das Computerobjekt
übernommen werden. Da diese Änderungen eng gekoppelt und synchronisiert sind, kann eine
Änderung der Name-Eigenschaft nur erfolgen, wenn die Netzwerknamenressource offline
geschaltet ist. Falls die Umbenennung des Computerobjekts aus irgendeinem Grund
fehlschlägt, schlägt die Änderung der Name-Eigenschaft ebenfalls fehl.
Hierzu gibt es eine Vorsichtsmaßnahme: Die Netzwerknamenressource ermöglicht eine
Änderung von Eigenschaftswerten, während sie online geschaltet ist; in diesem Fall wird die
Umbenennung so lange aufgeschoben, bis der Name offline geschaltet wird. Wenn der
Umbenennungsversuch fehlschlägt, wird der Vorgang im Rahmen des Onlineprozesses
wiederholt. Der Name wird erst wieder online geschaltet, nachdem der
Umbenennungsvorgang erfolgreich abgeschlossen wurde.
Anmerkung: Viele Anwendungen und Dienste, wie z. B. MSMQ und SQL Server,
unterstützen die Änderung der Name-Eigenschaft für die Netzwerknamenressource NICHT.
Kennwortrotation
Das Computerobjekt behält das Kennwort bei, das bei der Herausgabe von Kerberos-Tickets
zur Authentifizierung verwendet wurde. In der aktuellen Implementierung für
Windows 2000 SP3 und Windows Server 2003 wird das Kennwort für das Computerobjekt
nach dem Erstellen des Objekts nicht mehr geändert.
Vorsichtsmaßnahmen, Probleme und Überlegungen
Verwaiste Computerobjekte
Viele Betriebssystemdienste und -anwendungen verwenden eine Sicherheitsaushandlung.
Dabei handelt es sich um eine von der Windows-Plattform bereitgestellte Komponente, die
einem Client die Authentifizierung bei einem Dienst ermöglicht. Sie verbirgt die Einzelheiten
eines bestimmten Authentifizierungsschemas und ermöglicht einem Client den Versuch einer
Kerberos-Authentifizierung. Wenn sie nicht verfügbar ist, greift der Client auf die NTLMAuthentifizierung zurück. Wenn Active Directory ein Computerobjekt enthält, das dem vom
Client verwendeten Zielnamen entspricht, setzt die Sicherheitsaushandlung voraus, dass die
Kerberos-Authentifizierung erforderlich ist3. Enthält Active Directory ein virtuelles
Computerobjekt (deaktiviert oder nicht deaktiviert), greifen künftige Clientverbindungen mit
dem Namen dieses virtuellen Servers NICHT auf NTLM zurück.
Wenn die Authentifizierung bei einem virtuellen Server fehlschlägt und dieser Server NTLM
verwendet, sollten Sie überprüfen, ob Active Directory ein verwaistes oder altes
Computerobjekt enthält, das dem Namen des virtuellen Servers entspricht.
Cluster- und Active Directory-fähige Dienste
Es gibt einige Dienste, die sowohl cluster- als auch Active Directory-fähig sind. Hierzu
gehören vor allem SQL Server 2000, Exchange 2000 und MSMQ. Manche dieser Dienste
verknüpfen Dienstinformationen mit den Computerobjekten. MSMQ insbesondere verknüpft
Dienstinformationen mit dem Computerobjekt virtueller Server.
Beim Entfernen der Kerberos-Authentifizierung von einer Netzwerknamenressource wird das
Computerobjekt deaktiviert. Dann muss der Systemadministrator explizit entscheiden, dass
das Objekt gelöscht werden soll. Wenn das Computerobjekt gelöscht wird, werden die durch
Active Directory-fähige Anwendungen verwendeten Eigenschaften ebenfalls gelöscht, und
diese Anwendungen funktionieren möglicherweise nicht mehr ordnungsgemäß. Daher sollte
äußerst vorsichtig vorgegangen werden, wenn die Kerberos-Authentifizierung von einer
Netzwerknamenressource entfernt wird.
Verzögerungen bei der Active Directory-Replikation
Bis jetzt wurde bei Active Directory davon ausgegangen, dass es sich um eine einzelne, sehr
konsistente Infrastruktur handelte. In einer Produktionsumgebung werden mehrere
Domänencontroller bereitgestellt, um sicherzustellen, dass die Domäneninfrastruktur
kontinuierlich verfügbar ist. Änderungen an Active Directory werden über Knoten hinweg
repliziert, und in einigen Fällen kann die so entstehende Replikationsverzögerung sehr groß
sein. Dies kann einige anscheinend inkonsistente Effekte verursachen. Diese müssen Sie
berücksichtigen.

Clients können das Computerobjekt für eine Netzwerknamenressource nicht
finden
Verschiedene Knoten können auf unterschiedliche Domänencontroller zugreifen.
Wenn ein Computerobjekt auf einem Domänencontroller erstellt wird, ist es für die
Clients möglicherweise erst dann sichtbar, nachdem es auf andere Domänencontroller
repliziert wurde.
Sinnvolle Verfahrensweisen


Planen Sie die Verwendung der Kerberos-Authentifizierung in einem Cluster
sorgfältig:
 Aktivieren Sie die Kerberos-Authentifizierung auf den virtuellen Servern, die
für Ihre Bereitstellung sinnvoll sind.
 Sie sollten die Kerberos-Authentifizierung auf einem virtuellen Server nur
dann deaktivieren, wenn Sie die Dienste, die diesen Server verwenden,
vollständig verstehen und genau wissen, wie sich eine Deaktivierung auf die
Dienste auswirken wird. Das Computerobjekt und alle damit verknüpften
Dienstinformationen werden gelöscht (vorausgesetzt, dass korrekte
Berechtigungen existieren). Dies kann dazu führen, dass ein Dienst nicht
verfügbar ist, oder nicht wiederhergestellt werden kann.
Das Clusterdienstkonto sollte die Berechtigung Hinzufügen von Arbeitsstationen
zur Domäne besitzen, um ihm das Erstellen von Computerobjekten in
Active Directory zu ermöglichen. Wenn Sie dem Clusterdienstkonto diese
Berechtigung nicht erteilen möchten, MÜSSEN Sie das Computerobjekt in
Active Directory manuell erstellen, bevor Sie die Kerberos-Authentifizierung
aktivieren.
Anmerkung: Die Berechtigung Hinzufügen von Arbeitsstationen zur Domäne erlaubt
das Erstellen von 10 Computerobjekten über dieses Konto. Diese Berechtigung erlaubt
jedoch NICHT, dass das Computerobjekt über das Konto gelöscht oder umbenannt
wird.



Das Clusterdienstkonto sollte über die Zugriffsrechte Alle Eigenschaften schreiben
verfügen, damit das Computerobjekt umbenannt werden kann.
Viele Dienste, darunter MSMQ und SQL Server 2000, unterstützen das Ändern der
Name-Eigenschaft der Netzwerknamenressource nicht. Deshalb sollten Sie diese
Eigenschaft nur dann ändern, wenn Sie die möglichen Auswirkungen vollständig
verstehen. In einigen Fällen kann eine Änderung der Name-Eigenschaft zum
Datenverlust oder zum Ausfall eines Dienstes führen.
Sie sollten sicherstellen, dass die Domänencontroller die Möglichkeit hatten, neu
erstellte und den Netzwerknamenressourcen zugeordnete Computerobjekte zu
replizieren, bevor Sie Clients den Zugriff auf die Objekte erlauben, oder bevor ein
Failover der Ressource auf einen anderen Knoten im Cluster durchgeführt wird. Bei
Nichtbeachtung dieser Empfehlung kann es zu unvorhersehbaren Ergebnissen
kommen (Weitere Informationen finden Sie im Abschnitt Verzögerungen bei der
Active Directory-Replikation).
Netzwerksicherheit
Netzwerküberflutung
Der Clusterdienst verwendet den UDP-Port 3343 für clusterinterne Kommunikation. Diese
Kommunikation umfasst Taktdatenverkehr zur Erkennung von Knotenfehler- und
Clustersteuervorgängen. Einige dieser Vorgänge (wie z. B. Takte) sind zeitkritisch. Wenn die
Anschlüsse infolge von Netzwerküberflutungsangriffen (Network Flooding) stark belastet
sind, kann dies zu einer falschen Knotenfehlererkennung führen und deshalb unnötige
Failover verursachen, die wiederum zu einer Ausfallzeit für die Anwendung führen.
Port-Squatting
Es ist möglich, dass eine bösartige Anwendung auf Port 3343 zugreift. Damit wird das Starten
des Clusterdienstes verhindert. In diesem Fall besteht die einzige Möglichkeit darin, Prozesse
die diesen Port verwenden zu beenden. Port 3343 ist ausschließlich für den Clusterdienst
registriert.
Rogue-Server
Der Clusterdienst stellt Remoteverwaltungsfunktionen über die Cluster-APIs bereit, so dass
ein Cluster von einer Arbeitsstation aus verwaltet werden kann. Die Cluster-APIs verwenden
NTLM zur Authentifizierung am Server. NTLM ermöglicht es dem Server, zu bestätigen,
dass der Client über ausreichende Rechte und Berechtigungen zum Verwalten des Clusters
verfügt, bietet jedoch keine gegenseitige Authentifizierung. Mit anderen Worten: Der Client
hat keine hundertprozentige Garantie, dass es sich bei dem mit ihm verbundenen Knoten oder
Cluster um den richtigen Cluster handelt. Wenn ein Rogue-Computer im Netzwerk mit
derselben IP-Adresse oder demselben Netzwerknamen (bei einer Kompromittierung der
DNS-Server) angezeigt wird, könnte sich dieser Computer als Cluster ausgeben. Wenn dieser
Rogue-Computer außerdem die Clusterdienst-APIs zur Verfügung stellt, würden alle an den
Cluster gesendeten Verwaltungsbefehle vom Rogue-Computer abgefangen. In vielen Fällen
stellt dies keine Bedrohung dar, weil der Administrator eine falsche Meldung zurückerhält. Es
gibt jedoch sicherheitsrelevante Vorgänge (z. B. das Ändern der Clusterkonfiguration), bei
denen ein nicht autorisierter Empfänger Clusterkonfigurationsdaten sammeln und und diese
für einen Angriff verwenden könnte.
Damit dieser Angriff überhaupt möglich wird, müssen die folgenden Bedingen gegeben sein:
1. Der Rogue-Computer muss im selben Subnetz wie der Zielcluster sein und auf
Datenverkehr an die Cluster-IP-Adresse reagieren (dies kann die IP-Adresse des
physischen Computers, oder die IP-Adresse der vom Computer gehosteten virtuellen
Server sein).
2. In einer Standartumgebung kann der Rogue-Computer die IP-Adresse nur
„übernehmen“, wenn der Clusterknoten oder der virtuelle Server nicht ausgeführt
wird.
3. Der Rogue-Computer muss den Anschein erwecken, als ob er die Cluster-APIs zur
Verfügung stelle. Bei einem typischen Verwaltungsvorgang führt die
Clientanwendung mehrere Aufrufe an den Server durch und gibt in einigen Fällen
Handles für nachfolgende Aufrufe zurück.
4. Der Administrator muss die Konfiguration sicherheitsrelevanter Daten ändern
(beispielsweise das Kennwort für das Clusterkonto).
Sinnvolle Verfahrensweisen
Angriffe, die den Cluster gefährden, erfolgen normalerweise in dem Subnetz, in dem sich der
Cluster befindet. Zum Schutz vor diesen Angriffen sollten die Subnetze gesichert werden.


Netzwerke mit Clients
Das von den Clusterknoten verwendete Subnetz sollte nur Knoten enthalten, die
physikalisch gesichert wurden, oder denen vertraut werden kann. Sie müssen
sicherstellen, dass Rogue- oder potenziell unsichere Computer nicht an das Subnetz
der Cluster angeschlossen werden. Da dieses Netzwerk möglicherweise
Domänencontroller, DNS-Server, WINS-Server, DHCP-Server und eine andere
Netzwerkinfrastruktur enthält, müssen Sie mit entsprechenden Maßnahmen dafür
sorgen, dass diese Infrastrukturserver ebenfalls sicher sind.
Es sollten typische Netzwerksicherheitsverfahren implementiert werden, wie z. B.
Firewalls, die nur bestimmte Anwendungsanforderungen zulassen. Die Thematik des
Sicherns von Netzwerken und Infrastrukturservern würde den Umfang dieses
Dokuments jedoch sprengen.
Private Netzwerke
In einem privaten Netzwerk sollten nur Knoten im Cluster sichtbar sein (mehrere
Cluster können dasselbe private Netzwerk verwenden). Im privaten Subnetz sollten
sich keine anderen Netzwerk-Infrastrukturserver oder anderen Anwendungsserver
befinden. Dies kann auf zwei verschiedene Arten erreicht werden:
 Durch physikalisches Einschränken des Netzwerks (z. B. ist das private
Netzwerk ein nur mit den Clusterknoten verbundenes LAN).
 Durch Isolieren der privaten Clusternetzwerke mit Hilfe von VLAN-fähigen
Switches.
NTLM V1 und NTLM V2
Windows 2000
Windows 2000-Cluster (bis einschließlich SP2) müssen die NTLM V1-Authentifizierung
zwischen Clusterknoten verwenden. Es gibt mehrere Sicherungstools und Richtlinienvorlagen
(z. B. HiSecDC), die unterschiedliche Richtlinien auf die Knoten anwenden und so
NTLM V2 als Standardsicherheitsprofil erzwingen. Wenn diese Richtlinienvorlagen oder
Tools auf einen Windows 2000-Cluster angewendet werden, schlägt der Clusterdienst fehl.
Das Standardsicherheitsprofil muss auf LM- und NTLM-Antworten senden zurückgesetzt
werden. Dieser Vorgang wird in den KB-Artikeln 295091 und 272129 näher erläutert (beide
englischsprachig).
Windows Server 2003 und Windows 2000 SP3 (oder höher)
Unter Windows 2000 SP3 oder höher sowie unter Windows Server 2003 ist der Clusterdienst
zur Verwendung von NTLM V2 fähig. Sicherheitsrichtlinien, die NTLM V2 aktivieren,
gefährden den Cluster nicht.
NetBIOS
Die Sicherheit eines Systems ist abhängig von der Anzahl der Möglichkeiten, in das System
zu gelangen. Unter Windows Server 2003 ist für den Clusterdienst kein NetBIOS erforderlich.
Allerdings werden einige Dienste beeinträchtigt, wenn NetBIOS deaktiviert ist. Sie sollten
folgende Punkte berücksichtigen:





Bei der Konfiguration eines Clusters wird NetBIOS standardmäßig auf der Cluster-IPAdressressource aktiviert. Nach Erstellung des Clusters sollten Sie NetBIOS
deaktivieren, indem Sie das Kontrollkästchen auf der Eigenschaftsseite für die
Cluster-IP-Adressressource deaktivieren.
Wenn Sie weitere IP-Adressressourcen erstellen, sollten Sie das Kontrollkästchen
NetBIOS deaktivieren.
Bei deaktiviertem NetBIOS können Sie die Durchsuchen-Funktion in der
Clusterverwaltung nicht für die Verbindung mit einem Cluster verwenden. Die
Clusterverwaltung listet mit Hilfe von NetBIOS alle Cluster in einer Domäne auf.
Druck- und Dateidienste sind deaktiviert – es werden keine virtuellen Namen als
Umleitungsendpunkte hinzugefügt.
Die Clusterverwaltung funktioniert nicht, wenn ein Clustername angegeben wird. Die
Clusterverwaltung ruft GetNodeClusterState auf, das die Remoteregistrierungs-APIs
verwendet, die wiederum Named Pipes auf der Grundlage des virtuellen Namens
verwenden.
IPSec
Obwohl IPSec (Internet Protocol Security) bei Anwendungen einsetzbar ist, für die in einem
Servercluster ein Failover durchgeführt werden kann, wurde es nicht für Failover-Situationen
konzipiert. Deshalb sollten Sie IPSec bei Anwendungen in einem Servercluster NICHT
verwenden.
Das Hauptproblem besteht darin, dass IKE SAs (Internet Key Exchange Security
Associations) beim Auftreten eines Failovers nicht von einem Server zum anderen übertragen
werden, weil sie in einer lokalen Datenbank auf jedem Knoten gespeichert sind.
In einer durch IPSec geschützten Verbindung wird ein IKE SA in Aushandlungsphase-I
erstellt. Zwei IPSec SAs werden in Phase II erstellt. Den IKE- und IPSec-SAs ist ein
Zeitlimitwert zugeordnet. Wenn die Haupt-PFS (Perfect Forward Secrecy) nicht verwendet
wird, werden die IPSec SAs unter Verwendung von Schlüsseldaten aus den IKE SAs erstellt.
Falls dies zutrifft, muss der Client warten, bis die Standardzeitüberschreitung oder die
Lebensdauer für die eingehende IPSec SA abgelaufen ist. Anschließend wartet er auf die der
IKE SA zugeordnete Zeitüberschreitung oder Lebensdauer.
Die Standardzeitüberschreitung für den Security Association-Leerlauf-Timer beträgt
5 Minuten. Bei einem Failover können Clients Verbindungen erst dann wiederherstellen,
wenn mindestens 5 Minuten vergangen sind, nachdem alle Ressourcen mit Hilfe von IPSec
online geschaltet wurden.
Obwohl IPSec für eine Clusterumgebung nicht optimal ausgelegt ist, kann es verwendet
werden, wenn Ihre Unternehmensanforderung für eine sichere Konnektivität die entstehende
Clientausfallzeit bei einem Failover überwiegt.
Clusterdatenträger
Im Allgemeinen entsprechen Clusterdatenträger (d. h. Datenträger, die über eine
entsprechende Ressource in der Clusterkonfiguration verfügen) anderen von Windows
gehosteten Datenträgern. Es gibt jedoch einige zusätzliche Überlegungen, die Sie verstehen
müssen:
Allgemeine bewährte Methoden


Der Clusterserver unterstützt auf Clusterdatenträgern nur das NTFS-Dateisystem.
Damit wird sichergestellt, dass der Dateischutz für den Schutz der Daten auf den
Clusterdatenträgern verwendet werden kann. Da bei Clusterdatenträgern ein Failover
zwischen Knoten durchgeführt werden kann, dürfen Sie für den Schutz der Dateien
nur Domänenbenutzerkonten (oder aber das lokale Systemkonto, das
Netzwerkdienstkonto oder das lokale Dienstkonto) verwenden. Lokale
Benutzerkonten auf einem bestimmten Computer haben auf anderen Computern im
Cluster keine Bedeutung.
Clusterdatenträger werden regelmäßig überprüft, um ihren einwandfreien Zustand
sicherzustellen. Das Clusterdienstkonto MUSS über Schreibzugriff auf das
Verzeichnis der obersten Ebene aller Clusterdatenträger verfügen. Wenn das Konto
nicht über Schreibzugriff verfügt, wird der Datenträger möglicherweise als fehlerhaft
deklariert.
Quorumdatenträger



Die Fehlerfreiheit des Quorumdatenträgers ist entscheidend für die Fehlerfreiheit des
gesamten Clusters. Wenn der Quorumdatenträger ausfällt, steht der Clusterdienst auf
keinem der Clusterknoten mehr zur Verfügung. Der Clusterdienst überprüft die
Fehlerfreiheit des Quorumdatenträgers und handelt den exklusiven Zugriff auf das
physische Laufwerk mit Hilfe von Standard-E/A-Vorgängen aus. Diese Vorgänge
werden in der Warteschlange des Geräts eingereiht, zusammen mit allen anderen E/AVorgängen für das Gerät. Wenn die E/A-Vorgänge des Clusterdienstes durch
besonders starken Datenverkehr verzögert werden, deklariert der Dienst den
Quorumdatenträger als fehlerhaft und erzwingt eine Neugruppierung, um den
Datenträger an einer anderen Stelle im Cluster wieder online zu schalten. Zum Schutz
vor bösartigen Anwendungen, die den Quorumdatenträger mit E/A-Vorgängen
überfluten, sollte dieser gesichert werden. Der Zugriff auf den Quorumdatenträger
sollte auf die lokale Gruppe Administratoren und das Clusterdienstkonto beschränkt
werden.
Wenn der Quorumdatenträger voll wird, ist der Clusterdienst möglicherweise nicht
mehr in der Lage, die erforderlichen Daten zu protokollieren. In diesem Fall fällt der
Clusterdienst – eventuell auf allen Clusterknoten – aus. Zum Schutz vor bösartigen
Anwendungen, die den Quorumdatenträger füllen, sollte der Zugriff auf die lokale
Gruppe Administratoren und das Clusterdienstkonto beschränkt werden.
Aus diesen beiden Gründen sollte der Quorumdatenträger NICHT zum Speichern
anderer Anwendungsdaten verwendet werden.
Clusterdatenträger

Genauso wie der Quorumdatenträger werden andere Clusterdatenträger regelmäßig
mit derselben Technik überprüft. Wenn bösartige Anwendungen die Datenträger für
die Clusteranwendungen mit E/A-Vorgängen überfluten, kann der Clusterdienst
möglicherweise nicht auf Fehlerfreiheit überprüft werden. Dies führt dazu, dass für
den Datenträger (und alle davon abhängigen Anwendungen) ein Failover auf einen
anderen Clusterknoten durchgeführt wird. Zur Vermeidung eines solchen Denial-ofService-Angriffs sollte der Zugriff auf die Clusterdatenträger auf diejenigen
Anwendungen beschränkt werden, die Daten auf den spezifischen Datenträgern
speichern.
EFS und Servercluster
Unter Windows Server 2003 wird EFS (Encrypting File System oder verschlüsselndes
Dateisystem) auf Clusterdateifreigaben unterstützt. Zur Aktivierung von EFS auf einer
Clusterdateifreigabe müssen Sie eine Reihe von Aufgaben ausführen, um die Umgebung
korrekt zu konfigurieren:
1. EFS kann auf Dateifreigaben nur aktiviert werden, wenn Kerberos auf dem virtuellen
Server aktiviert ist. Standardmäßig ist Kerberos auf einem virtuellen Server nicht
aktiviert. Zum Aktivieren von Kerberos müssen Sie das Kontrollkästchen KerberosAuthentifizierung aktivieren derjenigen Netzwerknamenressource aktivieren, die
zum Herstellen der Verbindung mit der Clusterdateifreigabe verwendet wird.
Anmerkung: Die Aktivierung von Kerberos für einen Netzwerknamen hat
verschiedene Konsequenzen, die Sie vollständig verstehen müssen, bevor Sie das
Kontrollkästchen aktivieren.
2. Allen Computerkonten für den Clusterknoten und dem Computerkonto für den
virtuellen Server muss für Delegierungszwecke vertraut werden können. Das hierzu
erforderliche Verfahren wird in der Onlinehilfe beschrieben.
3. Um sicherzustellen, dass die privaten Schlüssel des Benutzers für alle Knoten im
Cluster verfügbar sind, müssen Sie servergespeicherte Profile für die Benutzer
aktivieren, die Daten mit Hilfe von EFS verschlüsseln möchten. Das erforderliche
Verfahren zum Aktivieren von servergespeicherten Profilen wird in der Onlinehilfe
beschrieben.
Nachdem die Clusterdateifreigaben erstellt und die vorstehend erläuterten
Konfigurationsschritte ausgeführt worden sind, können die Daten der Benutzer als zusätzliche
Sicherheitsmaßnahme verschlüsselt werden.
Verwalten von Dateifreigaben in einem Cluster
Normale Dateifreigaben
Normale Dateifreigaben sind im Hinblick auf Sicherheit am flexibelsten und am einfachsten
zu verstehen. Der einzige Unterschied besteht darin, dass die Sicherheit auf Freigabeebene
über die Benutzeroberfläche des Clusters statt über den Windows-Explorer verwaltet wird.
Die NTFS-Sicherheitseinstellungen für Dateien auf den Clusterdatenträgern werden mit Hilfe
der Windows-Standardprogramme wie dem Windows-Explorer verwaltet. Weitere
Informationen zum Verwalten von Clusterdateifreigaben finden Sie in der
Onlinedokumentation für Servercluster.
Dateifreigaben, die über die Clusterverwaltung erstellt wurden, weisen den gleichen
Standardschutz wie ein einzelner Knoten auf. Einziger Unterschied ist, dass die ACL mit
Hilfe der Clusterverwaltungsprogramme festgelegt wird. Eine Beschreibung der StandardACL für eine Dateifreigabe finden Sie in der Dokumentation zu den Dateidiensten.
Anmerkung: Verwenden Sie zum Ändern der Sicherheit bei einer Clusterdateifreigabe
immer die Clusterverwaltungsprogramme. Wenn Sie das Verwaltungsprogramm für
Dateifreigaben verwenden, geht eine vorhandene Konfiguration bei einem Failover der
Freigabe auf einen anderen Clusterknoten verloren.
Freigegebene Unterverzeichnisse
Freigegebene Unterverzeichnisse sind in aktuelleren Windows-Versionen als
Windows NT® 4.0 Service Pack 4 verfügbar. Sie ermöglichen Administratoren das schnelle
Erstellen von Verzeichnissen zum Hosten einer großen Anzahl von Freigaben, z. B.
Basisverzeichnissen, mit einer einzigen Clusterressource. Eine Stammfreigabe wird
angegeben, und sämtliche Unterverzeichnisse eine Ebene unter dem angegebenen Stamm
werden als reguläre Dateifreigaben erstellt.
Es gibt keine Möglichkeit zur Angabe unterschiedlicher Sicherheitsattribute für jedes
freigegebene Unterverzeichnis; deshalb erbt jede Freigabe die gleichen Berechtigungen auf
Freigabeebene wie die Stammfreigabe. Weil jede Freigabe normalerweise von einem
unterschiedlichen Benutzer verwendet wird, sollten die Berechtigungen auf Freigabeebene
jedem einzeln überlassen bleiben. Über dateibasierte Sicherheit auf Dateisystemebene sollte
gesteuert werden, wer auf welche Dateien zugreifen darf.
DFS-Stämme
DFS-Stämme sind seit Windows 2000 verfügbar. Servercluster unterstützen nur eigenständige
DFS-Stämme als Clusterressourcen4. Sie können Berechtigungen auf Freigabeebene für den
Stamm über die Benutzeroberfläche der Clusterverwaltung verwenden und jede Verknüpfung
über Dateifreigabeberechtigungen auf dem entsprechenden Server verwalten. Diese Methode
der Zugriffssteuerung kann jedoch bei DFS-Strukturen schwierig sein, die sich über
zahlreiche Server und Verknüpfungen erstrecken. Es wird daher empfohlen, für die
Verwaltung der DFS-Strukturen die Berechtigungen auf Dateifreigabeebene offen zu lassen
und den Zugriff mit Hilfe von NTFS-Dateisystemberechtigungen einzuschränken.
Clusterserverknoten als Domänencontroller
Für das ordnungsgemäße Funktionieren von Serverclustern (wobei der Clusterdienst auf
jedem Knoten gestartet wird) müssen die Knoten, aus denen der Cluster besteht, das
Domänenkonto des Clusterdienstes überprüfen können. Dabei handelt es sich um das Konto,
das bei der Konfiguration des Clusters konfiguriert wird. Zu diesem Zweck muss jeder
Knoten in der Lage sein, einen sicheren Kanal mit einem Domänencontroller zur Überprüfung
des Kontos einzurichten. Wenn das Konto nicht überprüft werden kann, wird der
Clusterdienst nicht gestartet. Dies gilt auch für andere Clusterprogramme, bei denen das
Konto überprüft werden muss, damit die Dienste, wie Microsoft SQL Server und
Microsoft Exchange, gestartet werden können.
Wenn es bei einer Clusterbereitstellung keine Verknüpfung mit einer Windows NT 4.0-,
Windows 2000- oder Windows Server 2003-Domäne gibt, müssen Sie die Clusterknoten als
Domänencontroller konfigurieren, damit das Clusterdienstkonto immer im Hinblick auf
einwandfreie Clusterfunktionalität überprüft werden kann.
Ist die Verknüpfung bei der Konnektivität zwischen Clusterknoten und Domänencontrollern
entweder langsam oder unzuverlässig, erwägen Sie die Zusammenlegung eines
Domänencontrollers mit dem Cluster, oder das Konfigurieren der Clusterknoten als
Domänencontroller. Microsoft rät allerdings davon ab, Clusterknoten als Domänencontroller
zu verwenden.
Wenn Sie die Clusterknoten als Domänencontroller konfigurieren müssen, berücksichtigen
Sie die folgenden wichtigen Hinweise:






Wenn ein Clusterknoten in einem Cluster mit zwei Knoten ein Domänencontroller ist,
müssen alle Knoten Domänencontroller sein. Es wird empfohlen, mindestens zwei der
Knoten in einem Datacenter-Cluster mit vier Knoten als Domänencontroller zu
konfigurieren.
Mit der Ausführung eines Domänencontrollers ist ein Overhead verbunden. Ein
Domänencontroller im Leerlauf kann zwischen 130 und 140 MB RAM verwenden,
unter anderem für die Durchführung von Serverclustering. Außerdem kommt es zu
Replikationsverkehr, wenn diese Domänencontroller eine Replikation mit anderen
Domänencontrollern innerhalb der Domäne und domänenübergreifend durchführen
müssen. Da die meisten Clustern Knoten in Unternehmen über Speicherkapazitäten im
GB-Bereich verfügen, ist dies normalerweise kein Problem.
Wenn die Windows 2000-Clusterknoten die einzigen Domänencontroller sind, müssen
sie jeweils auch DNS-Server sein. Für die primäre DNS-Auflösung sollten sie
aufeinander und für die sekundäre DNS-Auflösung auf sich selbst zeigen. Sie müssen
das Problem einer möglichen Nicht-Registrierung der privaten Schnittstelle im DNS
berücksichtigen – insbesondere, wenn deren Verbindung über ein Crossoverkabel
hergestellt wird (nur bei 2 Knoten). Informationen zum Konfigurieren der
Taktschnittstelle finden Sie im KB-Artikel 258750 (englischsprachig). Bevor Sie
jedoch Schritt 12 in diesem KB-Artikel ausführen können, müssen Sie zunächst
andere Konfigurationseinstellungen ändern. Diese werden im KB-Artikel 275554
(englischsprachig) beschrieben.
Wenn die Clusterknoten die einzigen Domänencontroller sind, müssen sie jeweils
globale Katalogserver sein, oder Sie müssen Domainlets implementieren. Weitere
Informationen zum Implementieren von Domainlets finden Sie auf der folgenden
englischsprachigen Microsoft-Webseite:
http://www.microsoft.com/windows2000/techinfo/administration/cluster/domainlets.a
sp
Der erste Domänencontroller in der Gesamtstruktur übernimmt alle FSMOFunktionen (Flexible Single Master Operations). Informationen hierzu finden Sie im
englischsprachigen KB-Artikel 192132. Sie können diese Funktionen an jeden Knoten
verteilen. Wenn ein Knoten jedoch einen Failover durchführt, sind die von ihm
übernommenen FSMO-Funktionen nicht mehr verfügbar. Sie können dann diesem
Knoten die Funktionen mit Hilfe des Tools Ntdsutil zwangsweise entziehen und dem
Knoten zuweisen, der weiterhin ausgeführt wird (Informationen hierzu finden Sie im
KB-Artikel 223787 - englischsprachig). Informationen zur Platzierung von FSMOFunktionen in der gesamten Domäne finden Sie im KB-Artikel 223346
(englischsprachig).
Wenn ein Domänencontroller so ausgelastet ist, dass der Clusterdienst nicht nach
Bedarf auf das Quorumlaufwerk zugreifen kann, interpretiert der Dienst dies



möglicherweise als Ressourcenfehler und bewirkt, dass die Clustergruppe einen
Failover auf den anderen Knoten durchführt. Falls sich das Quorumlaufwerk in einer
anderen Gruppe befindet (obwohl dies nicht so sein sollte) und so konfiguriert ist, dass
es sich auf die Gruppe auswirkt, werden bei einem Ausfall sämtliche
Gruppenressourcen auf den anderen Knoten verschoben. Dies ist nicht
wünschenswert. Weitere Informationen zu Quorumkonfigurationen finden Sie im
englischsprachigen KB-Artikel 280345 im Abschnitt Reference.
Das Clustering anderer Programme, wie SQL Server 2000 oder Exchange 2000, in
einem Szenario, in dem die Knoten auch Domänencontroller sind, erbringt aufgrund
von Ressourceneinschränkungen möglicherweise nicht die optimale Leistung. Daher
sollten Sie eine solche Konfiguration in einer Testumgebung gründlich prüfen, bevor
Sie diese bereitstellen.
Sie müssen einen Clusterknoten mit Hilfe des Tools Dcpromo zu einem
Domänencontroller hochstufen, bevor Sie einen Servercluster erstellen oder einen
Knoten zum Cluster hinzufügen (weitere Informationen hierzu finden Sie im
englischsprachigen KB-Artikel 247720).
Besonders vorsichtig müssen Sie beim Herabstufen eines Domänencontrollers zu
einem Mitgliedsserver sein, der auch ein Clusterknoten ist. Wenn ein Knoten von
einem Domänencontroller zu einem Mitgliedsserver herabgestuft wird, werden die
Sicherheitseinstellungen und die Benutzerkonten radikal geändert (Benutzerkonten
werden beispielsweise zu lokalen Konten herabgestuft). Informationen zum
Herabstufen eines Domänencontrollers, der auch ein Clusterknoten ist, finden Sie im
englischsprachigen KB-Artikel 247720.
Allgemeine Ressourcen
Die allgemeinen Ressourcentypen (Allgemeine Anwendung, Allgemeiner Dienst und
Allgemeines Skript5) ermöglichen es, dass nicht clusterfähige Anwendungen mit geringem
oder keinem Aufwand überwacht und ein Failover durchgeführt werden kann. Ein
Dateinamenpfad wird zur Identifizierung der Anwendung bzw. des Skripts verwendet. Der
Clusterdienst führt die Ressourcen-DLL unter dem Clusterdienstkonto aus; deshalb erfolgt die
Ausführung mit höheren Berechtigungen (lokalen Administratorberechtigungen).
Bei Verwendung einer allgemeinen Ressource sollten Sie sicherstellen, dass die Dateien, die
den Code/das Skript und alle von dem Skript, der Anwendung oder dem Dienst verwendeten
Registrierungsschlüssel enthalten, vor Angriffen geschützt sind.



Allgemeines Skript
 Sorgen Sie mit Hilfe der NTFS-Dateisystemberechtigungen dafür, dass
Skriptdateien sicher sind.
 Geben Sie den vollqualifizierten Pfad zum Skript an, um Spoofing-Probleme
zu vermeiden, die mit der PATH-Variablen verbunden sind.
Allgemeine Anwendung
 Stellen Sie sicher, dass der Anwendung vertraut wird und dass die Dateien, die
mit Prüfpunkten zu protokollierenden Registrierungsschlüssel und alle anderen
für die Ausführung der Anwendung erforderlichen Ressourcen sicher sind.
 Geben Sie den vollqualifizierten Pfad zur Anwendung an, um SpoofingProbleme zu vermeiden, die mit der PATH-Variablen verbunden sind.
Allgemeiner Dienst
 Stellen Sie sicher, dass dem Dienst vertraut wird und dass alle
Registrierungsschlüssel oder alle anderen für die Ausführung des Dienstes
erforderlichen Ressourcen sicher sind.
Anmerkung: Parameter und Konfigurationen für Windows-Dienste werden in
der Registrierung normalerweise unter HKEY_LOCAL_MACHINE
(HKLM) gespeichert. Im vorliegenden Dokument wird vorausgesetzt, dass
diese Registrierungsstruktur vor Angriffen geschützt ist. Die
Standardsicherheitsattribute der HKLM-Struktur sorgen für deren Sicherheit.
Zusammenfassung der Sicherheitsattribute
Dieser Abschnitt gibt einen Überblick über die verschiedenen Objekte und die zugehörigen
Sicherheitsattribute, mit denen die erfolgreiche Ausführung des Clusterdienstes sichergestellt
werden muss. Er führt die Mindestsicherheitsanforderungen auf. Wenn die
Sicherheitsattribute restriktiver sind, wird der Clusterdienst möglicherweise nicht ausgeführt.
Sind die Sicherheitsattribute weniger restriktiv, kann dies dazu führen, dass Angriffe den
Cluster gefährden oder Endbenutzerdaten beschädigen. Daher wird empfohlen, die
Sicherheitsattribute für die Objekte in den Standardeinstellungen nicht zu ändern.
Verzeichnis- und Dateischutz
Objekt
%windir%\help
Beschreibung
Hilfedateien zum
Cluster
Clusterverzeichnis
(und unterverzeichnisse)
Empfohlene Mindestsicherheitsattribute
BUILTIN\Users:R
BUILTIN\Administrators:F
%windir%\cluster
BUILTIN\Administrators:F
BUILTIN\Administrators:(OI)(CI)(IO)F
NT AUTHORITY\SYSTEM:F
NT
AUTHORITY\SYSTEM:(OI)(CI)(IO)F
CREATOR OWNER:(OI)(CI)(IO)F
%windir%\cluster\*
Dateien im
BUILTIN\Administrators:F
Clusterverzeichnis NT AUTHORITY\SYSTEM:F
<Quorumlaufwerk>
Datenträger mit
BUILTIN\Administrators:F
Quorumdaten
BUILTIN\Administrators:(OI)(CI)(IO)F
NT AUTHORITY\SYSTEM:F
NT
AUTHORITY\SYSTEM:(OI)(CI)(IO)F
<Quorumlaufwerk>:\MSCS Quorumverzeichnis BUILTIN\Administrators:F
(und BUILTIN\Administrators:(OI)(CI)(IO)F
unterverzeichnisse) CREATOR OWNER:(OI)(CI)(IO)F
<Quorumlaufwerk>:\MSCS\* Dateien im
BUILTIN\Administrators:F
Quorumverzeichnis
Datenträger auf
BUILTIN\Administrators:F
Clusterdatenträgern BUILTIN\Administrators:(OI)(CI)(IO)F
NT AUTHORITY\SYSTEM:F
NT
AUTHORITY\SYSTEM:(OI)(CI)(IO)F
Systemressourcen
Der Clusterdienst verwendet andere Systemressourcen, die standardmäßig geschützt sind.
Objekt
HKLM\*
Beschreibung
Empfohlene Mindestsicherheitsattribute
HKLMSYSTEM: Vollzugriff
Registrierungsstruktur BUILTIN\Administrators: Vollzugriff
Richtlinien für das Clusterdienstkonto


Sorgen Sie dafür, dass das Kennwort nicht abläuft. Unter Windows Server 2003
können Sie mit Hilfe des Kennwortänderungsmechanismus sicherstellen, dass das
Kennwort regelmäßig geändert wird.
Verwenden Sie für das Clusterdienstkonto sichere Kennwörter.
Active Directory

Um sicherzustellen, dass die Kerberos-Authentifizierung erwartungsgemäß
funktioniert, muss das Clusterdienstkonto Zugriff auf Active Directory haben. Dies
wird im Abschnitt Verwenden der Kerberos-Authentifizierung in einem Servercluster
behandelt.
DNS

Das Clusterdienstkonto muss Datensätze veröffentlichen können. In einer sicheren
DNS-Zone kann der DNS-Administrator wählen, dass die Zugriffsrechte für Benutzer
eingeschränkt werden sollen. Dem Clusterdienstkonto muss die Berechtigung zum
Erstellen von Datensätzen erteilt werden. Als Alternative können die Datensätze
vorbereitet werden. Wenn die Datensätze vorbereitet werden, sollten Sie für die Zone
keine dynamische Aktualisierung festlegen.
Überlegungen zum Hauptknotensatz
Windows Server 2003 stellt eine neue quorumfähige Ressource namens „Hauptknotensatz“
bereit. Das primäre Ziel dieser Ressource besteht darin, mehrere Kopien von Daten, die über
einen Cluster verteilt sind, ständig zu synchronisieren. Mit Hilfe des Hauptknotensatzes kann
eine Quorumressource in einem Cluster bereitgestellt werden, ohne einen freigegebenen
Datenträger für die Quorumdaten zu verwenden. Der Hauptknotensatz ist in erster Linie für
folgende Szenarien vorgesehen:


Geografisch verteilte Cluster – zum Bereitstellen eines einzelnen, allgemeinen
Quorummechanismus für Clusterkonfigurationen mit mehreren Standorten. Sie sollen
es Anbietern ermöglichen, Lösungen zu erstellen, ohne sich mit
Quorumanforderungen befassen zu müssen.
Cluster von Geräten – Gruppe von Standardcomputern, die über keine freigegebenen
Datenträger mit Bindung an einen einzigen Cluster verfügen, der eine andere
Replikationstechnik für Anwendungs- und/oder Benutzerdaten verwendet.
In einem Hauptknotensatz-Cluster gibt es eine einzige Hauptknotensatz-Ressource. Sie ist für
die Übertragung von Änderungen an die auf jedem Clusterknoten gespeicherten Quorumdaten
verantwortlich. Jeder Clusterknoten verfügt über eine eigene Kopie der Daten. Für den
Zugriff auf die Daten auf den anderen Knoten in einem Cluster (d. h. die Knoten außer
demjenigen, auf dem die Ressource gehostet wird) verwendet die Hauptknotensatz-Ressource
die Infrastruktur der Dateifreigabe. Beim Erstellen einer Hauptknotensatz-Ressource wird auf
jedem Clusterknoten (sowie auf Knoten, die zum Cluster hinzugefügt werden) eine
Dateifreigabe erstellt.
Dabei handelt es sich um eine versteckte Dateifreigabe mit einem Namen im folgenden
Format:
\\<Knotenname>\<Ressourcen_GUID>$
Die Standardsicherheitseinstellung für die Dateifreigabe lautet:
BUILTIN\Administrators:F (Diesen Ordner, Unterordner und Dateien)
CREATOR OWNER:F (Nur Unterordner und Dateien)
Um den einwandfreien Betrieb eines Hauptknotensatz-Clusters sicherzustellen,
berücksichtigen Sie folgende Punkte:
 Löschen Sie die Dateifreigabe NICHT.
 Entfernen Sie das Clusterdienstkonto NICHT aus der Gruppe der Konten, die Zugriff
auf die Freigabe haben.
 Ändern Sie die Standardzugriffssteuerungen für die Dateifreigabe NICHT.
 Das Dateifreigabeziel ist ein Ordner im Verzeichnis %windir%\Cluster\MSCS. Sie
sollten die Standardzugriffsberechtigungen für die Dateien oder Verzeichnisse nicht
ändern.
 Sie sollten niemals andere Dateien im MNS-Zielverzeichnis
%windir%\Cluster\MSCS\MNS speichern. Falls Sie in diesem Verzeichnis andere
Dateien speichern, werden diese beim Cleanup, dieser findet beim löschen der MNSRessource statt, gelöscht.
Überlegungen zum Aktualisieren auf Windows Server 2003
Windows 2000 und Windows NT4 verfügen über Standardsicherheitsattribute für das
Verzeichnis %windir%\Cluster und das Quorumverzeichnis, die jedem authentifizierten
Benutzer das Lesen der Inhalte erlauben. Die Sicherheit der Verzeichnisse wurde in Windows
Server 2003 verstärkt, um den Zugriff durch Nicht-Administratoren vollständig zu
unterbinden und sicherzustellen, dass nicht autorisierte Benutzer keine Informationen zur
Clusterkonfiguration erhalten können. Da diese Sicherheitsattribute bei einer Aktualisierung
auf Windows Server 2003 jedoch nicht geändert werden, verfügen alle authentifizierten
Benutzer eines aktualisierten Windows Server 2003-Computers möglicherweise weiterhin
über Lesezugriff auf diese Verzeichnisse. Sie sollten eine manuelle Festlegung der
Berechtigungen erwägen, damit diese den Mindestanforderungen entsprechen.
Entwickeln von clusterfähigen Anwendungen
Ressourcen-DLLs werden im Kontext des Clusterdienstkontos ausgeführt. Dieses Konto
besitzt eine Reihe von erhöhten Berechtigungen und ist außerdem auf jedem Knoten im
Cluster Mitglied der lokalen Gruppe Administratoren. Bei der Entwicklung einer
clusterfähigen Anwendung sollten Sie überlegen, wie diese zwischen der Ressourcen-DLL
und einem unabhängigen Dienst oder einer ausführbaren Datei am besten aufgeteilt werden
kann. So können Sie ihre Ausführung mit den erforderlichen Mindestberechtigungen und rechten sicherzustellen.
Wenn Anwendungen und Dienste mit nicht erforderlichen Berechtigungen ausgeführt werden,
entsteht bei einer Gefährdung der Anwendung und Dienste ein potenzielles Sicherheitsrisiko.
Aufrufen der Servercluster-APIs
Die Servercluster-APIs sind geschützt. Daher können nicht vertrauenswürdige Benutzer den
Status des Clusters oder die Verfügbarkeit von Anwendungen nicht beeinflussen. Der
Clusterdienst verwaltet eine Sicherheitsbeschreibung zum Steuern des Zugriffs. Nur Konten,
die in die Sicherheitsbeschreibung einbezogen sind, können Cluster-APIs aufrufen
(tatsächlich steuert die Sicherheitsbeschreibung, welche Konten einen Handle zum Cluster
öffnen können, da andere Clusterserver-APIs einen Handle erfordern. Auf diese Weise wird
der Zugriff wirksam eingeschränkt).
Bei diesem Mechanismus gibt es eine Vorsichtsmaßnahme. Der
Clusterkonfigurationsmechanismus in Windows Server 2003 erfordert es, dass ein Benutzer,
der einen Knoten zu einem Cluster hinzufügt, lokale Administratorrechte für jeden Knoten im
Cluster besitzt. Wenn er diese Rechte für die vorhandenen Clusterknoten nicht besitzt, kann
der Benutzer keinen neuen Knoten zum Cluster hinzufügen. Um einem Konto
Administratorrechte für einen Cluster zu erteilen, sollten Sie:
1. Das Konto zur Sicherheitsbeschreibung für den Clusterdienst hinzufügen.
2. Sicherstellen, dass das Konto der lokalen Gruppe Administratoren auf ALLEN
Computern im Cluster angehört.
Diese Vorgänge können mit Hilfe der Cluster- und Sicherheits-APIs programmgesteuert
erledigt werden. Weitere Einzelheiten hierzu finden Sie im Plattform SDK.
Sicherheitsprüfungen werden von der OpenCluster-API durchgeführt. Wenn der Aufruf
erfolgreich zurückgegeben wird, verfügt der Aufrufer über einen gültigen Handle und kann
beliebige Änderungen an der Clusterkonfiguration vornehmen oder diese auflisten. Es gibt
keine Anzeige für den „Lese-“ bzw. „Schreibzugriff“.
Sichern/Wiederherstellen von APIs
Der angegebene Sicherungspfad zur Sicherungs-API sollte geschützt werden. Die von der
API zurückgegebenen Daten enthalten Informationen zur Clusterkonfiguration, die für einen
Angriff verwendet werden können (z. B. Auflisten aller Cluster-IP-Adressen).
Während eines Wiederherstellungsvorgangs übernimmt die Sicherungs-API die
Clusterkonfiguration zum „Einfügen“ der Daten. Diese Daten müssen geschützt werden, da
sie zum Wiederherstellen des Clusters durch Überschreiben aller momentan vorhandenen
Konfigurationen verwendet werden.
Installieren von Ressourcen
Clusterfähige Anwendungen installieren möglicherweise Clusterressourcen. Beim Installieren
von Ressourcen sollte vorsichtig vorgegangen werden, da die Ressourcen mit erhöhter
Berechtigung ausgeführt werden. Deshalb müssen sie beim Installieren standardmäßig mit
folgenden Maßnahmen vor Angriffen geschützt werden:


Stellen Sie sicher, dass die Ressourcen-DLLs auf Dateisystemebene geschützt sind,
damit nur der lokale Administrator und das Clusterdienstkonto darauf zugreifen
können.
Seien Sie äußerst vorsichtig bei allen Pfadangaben. Es gibt verschiedene bekannte
Probleme bei Pfaden, insbesondere solchen, die Leerzeichen enthalten (folgen Sie
hierzu den Empfehlungen auf Seite 419 von Writing Secure Code). Geben Sie im
Zweifelsfall beim Erstellen des Ressourcentyps einen vollqualifizierten Pfad zur
Ressourcen-DLL an.
1
Bei einem für MSMQ erforderlichen Netzwerknamen wird RequireKerberos standardmäßig
aktiviert, um sicherzustellen, dass MSMQ nach Abschluss der Aktualisierung weiterhin in der
erwarteten Weise funktioniert.
2
Alle Knoten in einem Cluster müssen sich in derselben NT- und DNS-Domäne befinden.
3
In einer Nur-Windows Server 2003-Domäne funktioniert dies erwartungsgemäß.
4
Dies bedeutet NICHT, dass Sie keine Domänenstämme auf Clusterknoten erstellen können,
da ein Clusterknoten genauso wie jeder andere Server arbeitet; es handelt sich jedoch nicht
um Clusterressourcen.
5
Ein allgemeines Skript ist nur unter Windows Server 2003 verfügbar.
Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der
Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf
sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens
Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach
dem Zeitpunkt der Veröffentlichung nicht garantieren.
Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIE
INFORMATIONEN IN DIESEM DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE
AUSDRÜCKLICH ODER KONKLUDENT.
Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu
halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf
ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses
Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem
gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder
mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies
geschieht.
Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken,
Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt
dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen
Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es
sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft
eingeräumt.
© 2002. Microsoft Corporation. Alle Rechte vorbehalten. Microsoft, SQL Server, Windows
und Windows NT sind eingetragene Marken oder Marken der Microsoft Corporation in den
USA und/oder anderen Ländern.
Die in diesem Dokument aufgeführten Produkt- und Firmennamen können geschützte Marken
ihrer jeweiligen Inhaber sein.