EFS auf einem Cluster?

Kürzlich wurde ich gefragt, ob man denn EFS (Encrypting File System auf NTFS Datenträgern) auf einem Windows Cluster nutzen kann – Klar, seit Windows Server 2003 funktioniert das tadellos:

» Storage Features in Windows Server 2003 and Clustering

Damit die EFS Verschlüsselung klappt muss lediglich darauf geachtet werden, daß beim virtuellen Server Kerberos aktiviert ist, dazu setzt man in den Eigenschaften der Ressource des Netzwerknamens den Haken „Kerberos-Authentifizierung aktivieren“. Bevor man diesen Schritt unternimmt, sollten einige caveats beachtet werden:

» Applying Kerberos Authentication in a Clustered Environment

Einmal aktiviert, sollte man die Kerberos Authentifizierung nicht mehr leichtfertig deaktivieren…

Stay tuned,
N.Own

IPSec auf einem Windows Server 2003 Cluster?

IPSec war von Microsoft mit Erscheinen von Windows Server 2003 ursprünglich als not recomended für den Clusterbetrieb eingestuft:

» TechNet: IPSec in Cluster Networking
(Stand: January 01, 2003)

IPSec was not designed for failover situations and we recommend that you do NOT use IPSec for applications in a Server cluster.

Grund für diese Empfehlung ist die Art und Weise, wie die Sicherheitszuordnungen (SAs) des IPSec Internet Key Exchange (IKE) gespeichert werden – nämlich in einer lokalen und damit Nodes-pezifischen Datenbank.

Bei einem Failover müssen daher alle IPSec Verbindungen neu initiiert werden, um eine neue IKE SA auszuhandeln. Dieser Prozess dauert bei einem Windows 2000 Server Cluster per default 6 Minuten: 5 Minuten für den IPSec Idle Timeout, 1 Minute für das Re-initiieren durch den IKE (siehe » KB306677).
Das erhöht die Failoverzeit beträchtlich und senkt die potentielle Uptime…

Auf einem Windows Server 2003 Cluster kann diese Zeit per Registry immerhin auf 2 Minuten gedrückt werden, daher hat sich die ursprüngliche Empfehlung von Microsoft inzwischen wieder etwas relativiert.
Im Falle von Exchange 2003 ist ein Cluster Setup im Zusammenhang mit IPSec auch supported:

» How to Configure IPSec on an Exchange … Cluster

Mit der Hilfe des Registry-Keys NLBSFlags=1 kann in einer Multi-Tier Umgebung mit zB. NLB Frontendserver die IPSec idle time von 5 auf eine Minute gesenkt werden. Zusammen mit der IKE Re-initiierung (+1 Minute) kommt man dann auf die erwähnten 2 Minuten. Der Key ist in folgendem Zweig zu finden:
HKLM\SYSTEM\CurrentControlSet\Services
    \PolicyAgentOakley

Alles in allem muss abgewägt werden, ob man mit der zusätzlichen Verzögerung bei einem Failover leben kann bzw. ob dies die jeweiligen SLAs erlauben.

Für Windows Server 2008 Cluster hat sich das geändert, in Verbindung mit Windows Vista ist IPSec nicht mehr abhängig von Timeouts und kann bei einem Failover sofort eine neue SA aushandeln.

Stay tuned,
N.Own

Bitlocker auf Shared Disk?

Unterstützt Windows Server Failover Clustering die Verschlüsselung eines Shared Volumes mittels Bitlocker?

Nein, das ist mit Windows Server 2008 nicht möglich:
» http://support.microsoft.com/kb/947302/en-us

Da der Bitlocker Key an einen spezifischen Computeraccount gebunden ist sollte man die Bitlocker Drive Encryption nicht für Shared Disks aktivieren.

Stay tuned,
N.Own

Cluster Service Account (CSA) Rechte

Der Cluster Service Account (CSA) braucht gewisse Rechte, um alle Operationen des Cluster Dienstes ausführen zu können.

Voraussetzung für den ordentlichen Betrieb ist die Mitgliedschaft des Cluster Service Accounts in der Gruppe der Lokalen Administratoren sowie, daß der CSA Mitglied einer Domäne ist. Kein Cluster ohne DC und ohne Windows Domäne.

Weitergehende Rechte müssen in den Lokalen Sicherheitsrichtlinien auf jedem Nodes eines Clusters explizit vergeben werden:

Zum Vergrößern anklicken...

Klicken Sie den Screenshot zum Vergrößern an. Bei den grün markierten Rechten muss der CSA eingetragen werden, bei den orange markierten Rechten muss die lokale Administratorengruppe eingetragen sein (standard).

Das gilt für Windows Server 2003 Cluster – bei Windows Server 2000 müssen weiterhin folgende Rechte eingetragen sein:

  • Increase quotas
  • Load and unload device drivers
  • Lock pages in memory

Ein Fehlen dieser Rechte kann zu unvorhergesehenen Effekten und Fehlern führen, daher empfehle ich dringend die Einrichtung dieser Rechte, die man manuell vornehmen muss.

Wichtig: Keine Security Templates auf Cluster Nodes verteilen, typische Stolperfallen sind Security Templates wie die Highly Secure Predefined Security Templates (hisec*.inf). Die Predefined Templates müssen stark verändert werden für einen reibungslosen Betrieb des Cluster Dienstes.

KB Artikel zu den CSA Rechten:
» How to manually re-create the Cluster service account

Unter Windows Server 2008 wird der CSA obsolet, der Cluster Dienst läuft dort im Kontext des LocalSystem Accounts.

Stay tuned,
N.Own