Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

28Aug/132

Walk-Through: DHCP-Failover mit Windows Server 2012

Der Windows Server 2012 bringt eine Funktion mit sich, auf die man bisher nur über die Umwege eines Clusters und den damit verbundenen höheren Anforderungen (Server 2008 Enterprise-Edition, shared Storage, …) nutzen konnte. Die Rede ist von DHCP-Failover, welches im Windows Server unabhängig von der verwendeten Edition und vollkommen ohne Cluster genutzt werden kann. Notwendig sind lediglich zwei Windows Server 2012 mit aktivierter DHCP-Server-Rolle. Auf einem der beiden Server sollte bereits ein Bereich (“Scope”) eingerichtet sein, beide Server müssen im AD autorisiert sein.

Im Folgenden möchte ich die Einrichtung des Failovers im Modus “Load-Sharing” erläutern und Schritt für Schritt mit Bildern darstellen. Neben diesem Modus, welcher sich insbesondere dann eignet, wenn die beiden Server in der selben physischen Lokation stehen, steht als zweite Option die Variante “Hot Standby” zur Verfügung. Dieser Modus eignet sich z.B. dann, wenn im Fehlerfall ein DHCP-Server von einem anderen Standort den Standort des ausgefallenen DHCP-Servers versorgen soll.

Eine potentielle Fehlerquelle beim Einrichten der Failover-Beziehung ist die Zeit. Diese muss auf beiden Partnern synchron sein. Eine Abweichung von mehr als 60 Sekunden sorgt beim Einrichten für einen kritischen Fehler. Diese Tolleranz darf auch im täglichen Betrieb nicht überschritten werden.

Nun zur eigentlichen Anleitung:

Bereits vorbereitet sind hier zwei installierte DHCP-Server “SRV1” und “SRV2”, welche beide bereits im AD autorisiert sind. Auf dem ersten Server “SRV1” wurde bereits ein Bereich für das Subnetz 192.168.200.0/24 angelegt:

dhcp1

Das Failover erfolgt immer Bereichs-weise und kann durch einen Rechtsklick auf den gewünschten Bereich eingerichtet werden:

dhcp2

Im ersten Schritt des sich nun öffnenden Assistenten werden nochmal die bzw. der DHCP-Bereich abgefragt, welcher im Failover-Betrieb verwendet werden soll:

dhcp3

Im zweiten Schritte muss der Partnerserver bestimmt werden. Dabei fällt auf, dass pro Bereich nur ein Partner-Server zulässig ist. Wenn es bereits früher eine Failover-Beziehung zwischen den beiden gewählten Servern gab, so könnte man diese wieder “reaktivieren”:

dhcp4

Im nächsten Schritt sind die weiteren Parameter der Failover-Beziehung festzulegen:

dhcp5

Hierbei können festgelegt werden:

  • Der Name der Beziehung – ist eigentlich klar
  • Die “Maximale Clientvorlaufzeit” (Maximum Client Lead Time)
    • Dieser Wert gibt die vorübergehende Lease-Dauer an, die für Leases gilt, welche im Failover-Fall (“Partner down”) vom Partner-Server vergeben werden; nach dem diese Zeit verstrichen ist, übernimmt der Partnerserver den Bereich vollständig. Standardwert ist eine Stunde, kann aber z.B. auch auf 0 gesetzt werden
  • Modus
    • “Lastenausgleich” oder “Hot Standby” wie bereits oben beschrieben
    • Beim Lastenausgleich-Modus kann die Verteilung der Last auf die beiden Server festgelegt werden; Standard ist 50/50
    • Beim Modus “Hot Standby” ist hier stattdessen festzulegen, welche Rolle der Partnerserver übernimmt (“Aktiv” oder “Standby”) sowie der Anteil der für den Standby-Server reservierten Adressen (Standard: 5%). Dieser Anteil wird während der “Maximalen Clientvorlaufzeit” verwendet, bis der Standby-Server die volle Kontrolle übernommen hat
  • Intervall für Zustands-Switchover
    • Hier kann man festlegen, wie viel Zeit nach einem Wechsel in den Zustand “Communication interrupted” (Verbindung zwischen den beiden Partnern unterbrochen) vergehen soll, ehe zum Zustand “Partner down” übergegangen werden soll; standardmäßig ist dieser automatische Übergange abgeschalten, so dass der Administrator den Zustand “Partner down” händisch einleiten muss
  • Nachrichtenauthentifizierung aktivieren
    • Wenn diese Option eingeschalten ist, werden die Kommunikationen zwischen den beiden Partnern mit Hilfe von SHA-256 verschlüsselt. Zusätzlich wird eine Authentifizierung auf Basis von SHA-2 durchgeführt, um sicherzustellen, das kein unberechtigter Dritter Daten abfängt oder einschleust.
    • Wenn diese Option aktiviert ist, muss in der untersten Eingabezeile ein “Gemeinsamer geheimer Schlüssel” festgelegt werden, welcher vom Assistenten an beide Server gesendet wird und später nirgendwo erneut eingegeben werden muss

Als letzter Schritt folgt eine Zusammenfassung der gesetzten Einstellungen:

dhcp6

Nach einem Klick auf “Fertig stellen” wird die Failover-Beziehung eingerichtet und zum Schluss erscheint eine Erfolgs-Meldung:

dhcp7

Wenn man nun die GUI des DHCP-Tools aktualisiert, kann man beim SRV2 ebenso den bereits auf dem SRV1 eingerichteten Bereich sehen, in dem auch alle bereits vergebenen Leases und Reservierungen vorhanden sind:

dhcp8

Die Eigenschaften der verschiedenen Failover-Beziehungen lassen sich nachträglich in den Eigenschaften des jeweiligen Protokolls (“IPv4” bzw. “IPv6”) einsehen und ändern:

dhcp9

dhcp10

Für die Failover-Konfiguration ist im DHCP-Standard ein Austausch der Leases vorgesehen – nicht aber eine stetige Synchronisierung der Konfigurationen. Da aber beide Server einer Failover-Beziehung identisch konfiguriert sein sollten, ist nach einer Konfigurationsänderung ein Abgleich nötig:

dhcp11

Dabei kann entweder nur der gewählte Bereich abgeglichen werden (“Bereich replizieren…”) oder aber alle Bereiche, die in dieser Failover-Beziehung existieren (“Beziehung replizieren…”)

Wenn nun einer der beiden Kommunikationspartner ausgefallen ist, so wird dies durch Symbolik im DHCP-Manager angezeigt und ist auch in den Eigenschaften des Protokolles zu sehen:

dhcp12

Außerdem wird ein Eintrag im Ereignisprotokoll mit der ID 20252 angelegt:

dhcp13

In den Eigenschaften der Failover-Beziehung kann nun der Zustand von “Datenübertragung unterbrochen” auf “Partner nicht verfügbar” manuell geändert werden:

dhcp14

dhcp15

Ist der ausgefallene Server wieder verfügbar, geht die Verbindung in den Zustand “Wiederherstellen (warten)” über:

dhcp16

20Aug/130

Walk-Through: Dynamic Access Control praktisch angewendet

 

Der Windows Server 2012 bringt eine neue Funktion mit, welche die Bereiche Active Directory und Fileserver betrifft. Die Rede ist von “Dynamic Access Control" (DAC) bzw. der “Dynamischen Zugriffssteuerung”.

 

Bisher wurden in der Praxis Zugriffsrechte auf Ressourcen eines Fileserver auf einzelne Benutzerkonten (schlecht) oder auf Active Directory Gruppen (besser) vergeben. Ist der Benutzer Mitglied der Gruppe, so hat er den Zugriff; andernfalls nicht. Diese Konstruktion ist aber sehr statisch und macht den Zugriff einzig vom Benutzer bzw. seiner Gruppenmitgliedschaft abhängig.

 

Dynamic Access Control hingegen ermöglicht es, den Zugriff auch von anderen Faktoren abhängig zu machen, z.B. von Eigenschaften der Dateien oder auch vom Computer, von dem aus der Zugriff erfolgt. Dadurch ist beispielsweise möglich, dem Benutzer den Zugriff von seiner Workstation zu gestatten, vom Notebook aus aber zu verbieten, um somit dem Datendiebstahl vorzubeugen.

 

Diese etwas abstrakte Technik möchte ich im Folgenden an einem praktischen Beispiel illustrieren. Dabei soll es darum gehen, den Zugriff auf Dateien und Ordner eines Fileservers so zu gestalten, dass es abhängig ist von der Abteilung des Benutzers (“department” ist eines der AD-Attribute, welches standardmäßig vorhanden ist).

Für die folgende Demonstration wird ein (virtueller) Windows Server 2012 verwendet, welcher bereits als Domänencontroller inkl. Verwaltungswerkzeugen konfiguriert ist. Eine separate Rolle oder ein Feature ist hierzu nicht notwendig, allerdings muss innerhalb der ohnehin vorhanden “Datei- und Speicherdienste”-Rolle der “Ressourcen-Manager für Dateiserver” aktiviert werden.

Zuerst werden sogenannte “Anspruchstypen” (“Claims”) benötigt. Das sind die Attribute, von denen wir später den Zugriff abhängig machen wollen. Das anlegen der Claims erfolgt wie auch ein Großteil der restlichen Konfiguration über das grafisch aufgewertete “Active Directory Verwaltungscenter” (ADAC):

dac1

Hier sind bereits die im AD bekannten Attribute der Benutzerklasse sowie der Computerklasse (nach Setzen der Checkbox) zu finden. In unserem konkreten Beispiel verwende ich das Attribut “department”:

dac2

Als nächstes sind nun Eigenschaften unserer späteren Ressourcen nötig. Hier werde ich eine Eigenschaft verwenden, die ebenfalls “department” heißt, um später eine Regel in der Form zu gestalten:

WENN Benutzer.Abteilung == Ressource.Abteilung DANN Zugriff_gewährt

Diese Eigenschaften heißen “Ressource Properties” (auch in der Deutschen GUI) und es sind bereits einige nützliche Eigenschaften vorhanden, die nur noch aktiviert werden müssen:

dac3

Diese Eigenschaft “department” hat bereits einige vorgeschlagene Werte eingetragen, die bei Bedarf geändert bzw. angepasst werden können:

dac4

Da ich eine bereits vorhandene Eigenschaft verwende, ist diese bereits auf der “Global Ressource Property List” – andernfalls müsste Sie dort noch hinzugefügt werden:

dac5

Nun müssen noch eine “Zentrale Zugriffsregel” (“Central Access Rule”) sowie eine “Zentrale Zugriffsrichtlinie” (“Central Access Policy”) angelegt werden. Als erstes legen wir hierzu eine Regel ("Rule”) an. Diese regelt später den Zugriff auf die Ressourcen.

Unter “Zielressourcen” ist hier default “Alle Ressourcen” eingetragen. Das könnte aber später dazu führen, dass NIEMAND auf eine Datei zugreifen kann, beispielsweise dann, wenn diese GAR KEINE Abteilung als Eigenschaft besitzt.Daher ändere ich diesen Eintrag dahingehend, dass diese Regel nur auf Ressourcen abzielt, die die Eigenschaft “department” haben:

dac6

Bei den Berechtigungen hat man zwei Möglichkeiten: Man kann die im Folgenden konfigurierten Berechtigungen als “vorgesehene Berechtigungen” oder als “aktuelle Berechtigungen” (“tatsächliche” trifft es besser) verwenden:

dac7

Die erste Option ist insbesondere für Erprobungs- und Protokollierungszwecke nütze, wohingegen die zweite Option die kommenden Einstellungen direkt “scharf schaltet”.

In den Berechtigungen kann man nun über “Bearbeiten” die eigentlichen Einstellungen festlegen:

dac8

“Prinzipal” ist die Benutzergruppe, auf die die kommenden EInstellungen wirken sollen, in meinem Fall die “Domänen-Benutzer”. Dann folgt die eigentliche Berechtigung, in meinem Beispiel wähle ich das “Ändern”-Recht, welches Lesen und Schreiben beinhaltet. Ganz unten folgen hier die Bedingungen, in meinem Fall eben “Benutzer.Department == Ressource.Department”. Diese kann man bequem per Dropdown-Liste wählen:

dac9

Man könnte hier auch mehrere Bedingungen kombinieren. So könnte man eben auch fordern, dass der Computer, von dem aus der Zugriff erfolgt, in einer bestimmten AD-Gruppe enthalten sein muss.

Am Ende sieht die Regel dann in etwa so aus:

dac10

Nun ist noch eine Policy nötig, welche die angelegte Regel enthält:

dac11

Damit sind die Schritte im “Active Directory Verwaltungscenter” abgeschlossen. Nun sind noch zwei Einstellungen nötig, die man am besten per Gruppenrichtlinie setzt. Da in meinem einfachen Beispiel der Domänencontroller gleichzeitig der Fileserver ist, genügt hier ein GPO:

dac12

Die nötigen Einstellungen sind:

  • Computerkonfigurationen / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Dateisystem / Zentrale Zugriffsrichtlinie
    • Hier muss die angelegte Policy aktiviert werden
    • Gilt für den Dateiserver
  • Computerkonfigurationen / Richtlinien / Administrative Vorlagen / System / KDC / Unterstützung des Kerberos-Domänencontrollers für  Ansprüche…
    • Muss aktiviert werden
    • Gilt für den/die Domänencontroller

Spätestens nach einem GPUpdate sollten die gesetzten Einstellungen auf die betreffenden Systeme wirken, vorausgesetzt, das GPO wurde korrekt verknüpft. Dabei sollte im “Ressourcenmanager für Dateiserver” geprüft werden, ob die “Ressource Property” dort unter “Klassifizierungsverwaltung / Klassifizierungseigenschaften” auftaucht. Notfalls muss rechts “Aktualisieren” gedrückt werden:

dac15

Nun lege ich 2 Test-Benutzer im Active Directory an. Karl Auer ist hierbei Mitarbeiter der Marketing-Abteilung, Franz Iskaner arbeitet für die Sales-Abteilung:

dac13

Weiterhin lege ich ein Verzeichnis “Abteilungen” und darin je einen Ordner für “Sales” und für “Marketing” an. Den Ordner “Abteilungen” gebe ich im Netzwerk frei. An der Freigabe bekommen “Authentifizierte Benutzer” das Recht “Ändern”. In den erweiterten Sicherheitseinstellungen des Abteilungs-Ordners aktiviere ich die Abteilungs-Policy:

dac14

Nun werden noch die beiden Unterordner entsprechend klassifiziert. Dies geschieht über die Eigenschaften des jeweiligen Ordners. Dabei stehen mir die vorgeschlagene Werte der “Ressource Proptery” zur Verfügung:

dac16

Legt man nun beispielsweise im Marketing-Ordner eine neue Datei an, wird diese automatisch als “department: Marketing” klassifiziert. Diese Klassifizierung bleibt auch dann erhalten, wenn man das Dokument später z.B. an einen anderen Ort verschiebt. Bei den klassischen NTFS-ACL-Konstrukten wäre dies ander: Da würde das Dokument u.U. am Zielort andere Berechtigungen erben. Dabei wäre es z.B. denkbar, dass ein Benutzer, der auf beide Abteilungs-Ordner Zugriff hat, eine Marketing-Datei in den Sales-Ordner verschiebt. Bei den klassischen ACLs hätten nun die Sales-Benutzer Zugriff auf dieses Marketing-Dokument, was allerdings gar nicht gewünscht ist. Da die Klassifizierung sich beim Verschieben nicht verändert, haben die Sales-Benutzer hier auch dann keinen Zugriff, selbst wenn das Marketing-Dokument in “ihrem” Abteilungsverzeichnis landet.

dac17

dac18

Wenn man sich nun die Berechtigungen auf diesem Marketing-Dokument (im Sales-Ordner) ansieht, dann erkennt man, dass Karl Auer als Marketing-Mitarbeiter Zugriff hat, Franz Iskaner als Sales-Mitarbeiter hingegen nicht:

dac19

dac20

Genau so soll es auch sein!

Dynamic Access Control lässt sich für viele weitere Szenarien einsetzen. So kann man beispielsweise auch den “Ressourcen Manager für Dateiserver” nutzen, um Dateien automatisch zu klassifizieren, z.B. abhängig vom Inhalt. Denkbar wäre, Dokumente als “geheim” einzustufen, wenn diese das Wort “geheim” mindestens drei mal enthalten und dann nur noch einer gewissen AD-Gruppe den Zugriff auf geheime Dokumente zu gewähren.