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

1Okt/130

Problem bei der Installation des DHCP-Servers unter Windows Server 2012, Fehler 0x800f0922

Ein Kollege bat mich, mir ein Problem bei einem DHCP-Server anzusehen. Dieser ließ sich nicht mehr starten und auch ein Entfernen der Rolle brachte insofern keine Abhilfe, da sich die Rolle nicht mehr neu installieren ließ. Es wurde immer der Fehler 0x800f0922 gemeldet:

dhcp-error1

Der Fehler ließ sich auch nicht durch eine Reparatur des Komponentenspeichers mittels “dism /Online /Cleanup-Image /RestoreHealth” beheben.

Eine genauere Analyse zeigte schließlich, dass der Ordner “C:\Windows\System32\DHCP” einen Teil seiner NTFS-ACLs verloren hatte (Vollzugriff bestand nur für eine unbekannte SID statt für “DHCPServer”).

dhcp-error2

Nachdem dies korrigiert war, konnte der Ordner gelöscht werden und schlussendlich ließ sich dann auch die DHCP-Rolle wieder sauber installieren!

So sollten dann die ACLs für den DHCP-Folder aussehen:

dchp-error3

29Sep/130

Daten-Deduplizierung in Windows Server 2012

Eine unglaublich praktische und einfach zu nutzende Neuerung im Windows Server 2012 ist die Daten-Deduplizierung der Dateiserver-Rolle. Diese Funktion ermöglicht es, je nach Zusammensetzung der Dateien, sehr viel Speicherplatz auf einem Dateiserver zu sparen.

Die Deduplizierung arbeitet dabei nicht wie bei anderen Produkten auf Dateibasis, sondern blockbasiert. Alle Dateien eines Volumes, bei dem die Deduplizierung aktiviert ist, werden nach mehrfach vorkommenden “Chunks” durchsucht. Chunks sind variable Einheiten zwischen 32 und 128 Kilobyte (Dateien kleiner als 32kB werden nicht betrachtet). Die Chunks selber werden zusätzlich komprimiert. Kommt nun ein Chunk mehrfach vor, muss er nur einmal gespeichert werden.

Weitere Eigenschaften der Deduplizierung:

  • Transparent (Der Anwender sieht seine Files weiterhin wie bisher)
  • On-Schedule statt On-Access (Deduplizierung findet nicht beim Schreiben statt, sondern “später” laut Zeitplan)
  • Alters-basiert (Dateien werden erst ab einem gewissen Alter dedupliziert; Dateien, die sich jeden Tag ändern sind eher ungeeignet für die Deduplizierung)
  • Ressourcenschonend
  • Redundanz (Wenn ein Chunk von min. 100 Dateien referenziert wird, wird er mehrfach abgespeichert)

Was geht mit der Deduplizierung NICHT bzw. welche Einschränkungen gelten:

  • Lässt sich nicht auf dem Betriebssystem-Volume nutzen
  • Nur für NTFS-Volumes verfügbar (auch nicht für ReFS!)
  • Laufende VMs (bzw. deren VHDs) lassen sich nicht deduplizieren
  • Cluster Shared Volumes können nicht dedupliuziert werden

Wie lässt sich die Deuplizierung nun verwenden? Als erstes muss der Rollendienst installiert werden. Dies geht z.B. per Servermanager:

dedup1

Hinzufügen der Rollen & Features via Servermanager

dedup2

Rollenbasierte Installation

dedup3

Auswahl des gewünschten Zielservers

dedup4

Auswahl des Rollendienstes “Datendeduplizierung” in der Rolle “Datei- und Speicherdienste”

dedup5

Features werden keine benötigt

dedup6

Zusammenfassung der Auswahl, Start der Installation

dedup7

Abschluss der Installation

Nach Abschluss der Installation muss nun noch die Deduplizierung konfiguriert werden. Dies geschieht ebenfalls über den Servermanager, dort über die “Datei-/Speicherdienste”:

dedup8

Dann wird die Deduplizierung für das gewünschte Volume konfiguriert/aktiviert:

dedup9

Wichtig ist, dass hier einerseits die Deduplizierung aktiviert wird, das Mindestalter für zu deduplizierende Dateien festgelegt wird und der Zeitplan festgelegt wird.

dedup10

Zusätzlich könnte man hier noch Dateierweiterungen ausschließen oder sogar ganze Speicherorte (Ordner).

Beim Zeitplan ist grundsätzlich die Hintergrundoptimierung aktiv, die wirksam wird, wenn der Server gerade nichts zu tun hat. Dazu kann man dann bis zu 2 Zeitpläne für die Durchsatzoptimierung festlegen, bevorzugt zu Zeiten, in denen der Server regulär keine Last hat. (Hintergrundoptimierung kann bei VMs mitunter schwierig sein, weil sich der IO auf dem Storage nicht von einer einzelnen VM bewerten lässt).

dedup11

Nun noch eine kleine “Demo”: Ich habe auf einem Volume einige Beispieldaten vorbereitet:

dedup12

Hier liegen also 50 Dateien (Inhaltlich identisch, ist aber natürlich kein Muss). Diese belegen zusammen etwa 5GB.

Nach der Deduplizierung sieht es dann so aus:

dedup13

Hier ergibt sich also eine extrem hohe Einsparung: 200 Kilobyte statt 5 Gigabyte! Wäre die Blockgröße auf dem Volume noch kleiner, wäre noch weniger belegt, denn die 200kB ergeben sich aus 50 Files x 4kB Blocksize. Jedes der 50 Files belegt nur noch 4 Kilobyte, also insgesamt ist schon jedes File für sich kleiner als vorher!

(Dieses Beispiel ist etwas konstruiert. Die Dateien enthalten jede die Zeichenkette “0123456789” so oft, bis sich 100MB ergeben. Dadurch ist auch innerhalb der Dateien eine gute Deduplizierung möglich)

Im Servermanager wird dies nun auch noch entsprechend angezeigt:

dedup15

Interessant ist jetzt noch ein Blick in das Ereignisprotokoll:

dedup16

Hier sieht man u.a., dass der gesamte Vorgang in meinem Beispiel nur 54 Sekunden gedauert hat! (Und zwar auf einer einzelnen, klassischen (Nicht-SSD) Notebook-Festplatte, also weder schnelles RAID noch SAN oder so und in einer Hyper-V-VM)

17Sep/130

Walk-Through: Bereitstellen einer IPAM-Umgebung unter Windows Server 2012

Mit dem Windows Server 2012 hält auch ein neues Werkzeug Einzug in den Administrations-Alltag: Der IP-Adress-Verwaltungsserver, kurz IPAM. Dieses Werkzeug ist in der Lage, die gewachsenen IP-Address-Strukturen zu verwalten, zu analysieren und auch abzufragen. Dabei greift er auf folgende Quellen zu:

  • Domänen-Controller
  • DHCP-Server
  • DNS-Server
  • NPS-Server

Damit bietet er die Möglichkeit, die IP-Address-Verwaltung per Excel-Tabelle durch ein modernes, leistungsfähiges Werkzeug zu ersetzen.

Leider ist die Installation bzw. Einrichtung nicht ganz trivial, daher möchte ich diese hier Schritt für Schritt erläutern.

Bereits vorbereitet für dieses “Walk-through” ist eine kleine Demo-Umgebung bestehend aus einem Domänencontroller samt DNS (DC.hertes.lab), ein DHCP-Server samt Scope (DHCP.hertes.lab) sowie ein Member-Server für die künftig Aufgabe als IPAM (IPAM.hertes.lab).

WICHTIG: IPAM darf nicht auf einem Domänencontroller installiert werden. Das TechNet liefert hierfür zwar keine Erklärung, ich vermute aber, dass dies an der nötigen Datenbank (hier: Windows Internal Database, WID) liegt. Ab Server 2012 R2 ist auch ein “richtiger” SQL-Server möglich.

Als erstes muss der IPAM als Feature auf dem entsprechenden Server installiert werden. Dies geschieht über den Servermanager (alternativ per PowerShell):

ipam1

ipam2

ipam3

ipam4

ipam5

ipam6

Die benötigten, abhängigen Komponenten wie eben die WID oder auch die GPO-Verwaltung, werden automatisch mit installiert:

ipam7

ipam8

ipam9

ipam10

ipam11

Ein Neustart nach der Installation ist im Allgemeinen nicht erforderlich. Selbst wenn man den Haken für den automatischen Reboot gesetzt hat, wird nur neugestartet, wenn dies nötig ist.

Nach der Installation erfolgt die Einrichtung des IPAMs durch den entsprechenden Bereich im Servermanager (ein eigenständiges Werkzeug oder MMC-SnapIn existiert nicht). Die Administration inkl. Einrichtung kann auch remote erfolgen. Dazu ist über die Remoteserververwaltungstools (Feature) der IP-Adressverwaltungsclient zu installieren:

ipam_rsat

Die Einrichtung selber besteht aus 6 (bzw. eigentlich 7) Schritten, welche in einer Art Assistenten im Servermanager (links im Menü unter “IPAM”) abzuarbeiten sind:

  1. Verbindung mit IPAM-Server herstellen
  2. IPAM-Server bereitstellen
  3. Serverermittlung konfigurieren
  4. Serverermittlung starten
  5. Server zum Verwalten und Überprüfen des IPAM-Zugriffs auswählen oder hinzufügen
  6. Daten von verwalteten Servern abrufen

Nach dem Schritt 3 ist ein weiterer Schritt nötig, der hier nicht aufgeführt wird und nur per PowerShell erledigt werden kann. Darauf gehe ich später gesondert ein.

Die GUI zeigt die 6 Schritte. Der erste Schritt wird automatisch ausgeführt, wenn die IPAM-Konsole auf dem IPAM-Server selber gestartet wird.

ipam13

Ansonsten ist durch einen Klick auf den ersten Punkt eine Verbindung mit dem gewünschten IPAM-Server herzustellen:

ipam14

Als nächstes wird der IPAM-Server bereitgestellt. Dies kann manuell (nicht zu empfehlen) oder per GPO (sehr komfortabel) erfolgen. Bei der GPO-Variante ist nur ein Präfix anzugeben, der den künftigen drei GPOs namentlich vorangestellt wird:

ipam14-2

ipam15

ipam16

ipam17

ipam18

Nach diesem Schritt existieren die GPOs nur auf dem IPAM-Server, noch nicht auf dem Domänencontroller. Dazu kommen wir gleich…

In Schritt 3 werden die zu verwaltenden Domänen und Server ausgewählt:

ipam19

ipam20

Hier findet sich auch – etwas unglücklich platziert – der Hinweis auf den (zwingend nötigen) “siebten Schritt”: Das Schreiben der GPOs auf den DC mittels PowerShell-Cmdlet “Invoke-IpamGpoProvisioning”:

ipam20a

ipam20b

Schickt man den Befehl ohne Parameter ab, werden diese danach automatisch abgefragt.

Wichtig: Das Ausführen dieses Cmdlets muss (interaktiv) auf dem IPAM-Server erfolgen. Es funktioniert weder per Enter-PSSession noch per Invoke-Command!

Im Schritt 4 werden nun die Server der ausgewählten Umgebung ermittelt:

ipam21

Dabei wird eine “IP-Adress-Verwaltungsaufgabe” gestartet, deren Fertigstellung man abwarten muss:

ipam22

ipam23

Nun können im Schritt 5 die zu verwaltenden Server ausgewählten werden. Dabei werden diese jeweils in den Zustand “Verwaltet” gesetzt.

ipam24

ipam25

ipam26

ipam27

Dies muss für jeden Server separat erfolgen. Ist dies abgeschlossen, stehen die Server auf “Blockiert”. Die Blockierung wird aufgehoben, sobald die erzeugten und nun auch per Sicherheitsfilterung für die jeweiligen Server geltenden GPOs wirken. Am einfachsten kann man dies durch ein GPUpdate forcieren.

ipam-gpo

Sobald die GPOs wirken, kann man durch einen Rechtsklick den “Status des Serverzugriffs aktualisieren”. Dies muss wieder für alle Server einzeln und nacheinander erfolgen.

ipam-serverzugriff

Wenn diese Aufgabe erledigt ist, kann man die Ansicht aktualisieren (Kringel / Kreisel oben rechts). Nun sollten alle Server “grün” sein:

Falls nicht, hilft etwas warten bzw. müssen die jeweiligen Server evtl. noch einmal mit GPUpdate aktualisiert werden. Alternativ hilft “Invoke-GPUpdate SRVNAME –RandomDelayInMinutes 0 –Force”.

invoke-gpupdate

ipam28

Nun darf man den Schritt 6 nicht vergessen! Dieser ruft schließlich (einmalig manuell, später automatisch) die jeweiligen Daten von den verwalteten Servern ab.

ipam29

Auch hier muss man wieder auf Fertigstellung der IP-Adressverwaltungsaufgabe warten.

Ist der Schritt 6 fertiggestellt, kann man sich nun den verschiedenen Möglichkeiten im Baum auf der linken Seite widmen.

Unter IP-ADRESSRAUM / IP-Adressblöcke kann man z.B. den/die DHCP-Scope(s) sehen:

ipam30

Durch einen Rechtsklick auf diesen lässt sich die nächstfreie IP-Adresse suchen und zordnen:

ipam31

ipam32

Hier kann man beispielsweise einen Eintrag in DNS oder auch eine DHCP-Reservierung vornehmen. Allerdings werden diese Daten vorerst nur am IPAM-Server gespeichert. Möchte man die Informationen auch auf die jeweiligen Server übertragen, so ist dies unter “IP-Adressbestand” möglich:

ipam33

 

In der Rubrik “Überwachen und Verwalten” kann man u.a. den Zustand der involvierten Server und DHCP-Scopes sehen.

Im Ereigniskatalog werden einerseits Konfigurationsereignisse angezeigt, andererseits kann man gezielt nach IP-Adressen, MAC-Adressen, Hostnamen und Benutzernamen suchen, um damit verbundene Vorgänge (DHCP-Lese-Generation, –Renewal, DC-Authentifizierung, …) zu finden:

ipam34ipam35

Da der IPAM seine Daten in einer Datenbank ablegt, kann man hier auch Daten der Vergangenheit abrufen. Die Daten werden 3 Jahre lang in der Datenbank vorgehalten.

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.

10Jun/130

Windows Server 2012 R2 – Das kommt im neuen Hyper-V

Nachdem kürzlich für Windows Server 2012 ein R2 angekündigt wurde, gibt es nun auch einige Details zu den Änderungen in Hyper-V. Diese möchte ich hier kurz zusammentragen:

Generation-2-VMs

Es wird eine neue Generation für VMs geben, die verschiedene neue Szenarien unterstützen soll, so z.B. das Booten von iSCSI. Dies wird erreicht, indem hier nahezu vollständig auf Emulation von Hardware verzichtet werden soll. Dies funktioniert allerdings nur mit 64-Bit Client-Systemen und nur mit Windows 8 und dem Server 2012 als Gast.

VM Direct-Connect

Bisher ist für einen direkteren Zugriff auf die VM (inkl. Durchreichen von Laufwerken und Zwischenablage) eine RDP-Verbindung nötig, für die wiederum eine Netzwerkverbindung zwischen Gast und Host nötig ist, mit allen damit verbundenen Sicherheitsrisiken und Konfigurationsaufwänden. Mit Direct-Connect werden diese Möglichkeiten künftig auch mit der klassischen VM-Verbindung möglich sein.

Erweiterte Replikation einer VM

Es soll möglich sein, dass ein Host für eine VM nicht mehr nur Quelle ODER Ziel für die Replikation ist, sondern beides. Damit wird es möglich sein, ein Replikat innerhalb des Unternehmens, ein zweites außerhalb aufzubewahren. Vermutlich wird es auch möglich sein, eine VM direkt an 2 Ziele zu replizieren.

Die Replikation unter Server 2012 lässt lediglich ein Intervall von 5 Minuten zu. Im R2 wird es möglich sein, alternativ auch 30 Sekunden oder 15 Minuten zu wählen - je nach Notwendigkeit und Kapazität. Da nach 12 fehlerhaften Versuchen die Replikation unterbrochen wird, hätte man damit die Möglichkeit, 3 Stunden Downtime zu tolerieren.

Kompression & SMB Direct

Bei der Migration von VMs wird es 2 neue Optionen geben: Kompression der zu übertragenden Daten oder Übertragung via SMB Direct (setzt Netzwerkadapter auf beiden Seiten voraus, die RDMA unterstützen). Microsoft empfiehlt bei 10GBps-Links die Nutzung von RDMA, andernfalls die Kompression. Hierbei muss man natürlich den Einfluss der höheren CPU-Last auf die restlichen VMs beachten.

Online Export & Klonen

In Windows Server 2012 muss eine VM erst heruntergefahren/ausgeschaltet werden, bevor sie exportiert oder mittels SCVMM geklont werden kann. In R2 wird dies nun auch bei laufenden VMs möglich sein, wodurch es auch für Produktivumgebungen interessant wird.

Online-Größenänderung von VHDX

Es soll in Windows Server 2012 R2 möglich sein, eine VHDX während deren Nutzung durch eine laufende VM sowohl zu vergrößern, als auch sie zu verkleinern!

Storage-QoS

Der Windows Server 2012 R2 wird eine Möglichkeit bieten, die IOPS einer VM zu beschränken. Damit kann man eine IO-lastige VM begrenzen, um anderen VMs weiterhin eine akzeptable Datenrate auf dem Storage zu ermöglichen.

Dynamic Memory für Linux-VM

Für supportete Linux-Systeme wird es möglich sein, deren RAM-Zuweisung (wie bisher auch bereits bei Windows-Gast-Systemen möglich) dynamisch zu gestalten. Damit werden z.B. größere Ansammlungen von Linux-(Web-)Servern dynamischer.

Shared VHDX

Für Cluster-Szenarien wird es möglich sein, dass 2 VMs eine gemeinsame VHDX nutzen. Damit entfällt die Notwendigkeit, ein CSV auf iSCSI- oder FibreChannel-Basis einzusetzen.

 

2Feb/130

Server 2012: Unattend.xml für geklonte Maschinen

Will man einen Server 2012 klonen, ist es nötig, diesen vor dem Klonvorgang mit Hilfe von Sysprep vorzubereiten. Dabei gehen einige Informationen verloren, u.a. die SID, Hostname, IP-Adresse und co. Das ist hier auch gewollt. Allerdings gehen auch andere Informationen verloren, die dann nach dem Ausrollen des Images erneut eingegeben werden müssen, u.a. verschiedene Spracheinstellungen, Produkt-Key, das lokale Administratorpasswort und einiges mehr.

Um nun nicht auf vielen Klonen diese Informationen immer wieder neu eingeben zu müssen, kann man sich mit einer Unattend.xml, einer sogenannten "Antwortdatei", behelfen. In dieser kann man all diese Informationen vorab festlegen und sie werden dann automatisch verarbeitet.

Eine solche Unattend.xml muss entweder bereits vor dem Sysprep oder dann später mittels DISM in den Pfad %WINDIR%\Panther\Unattend gelegt werden.

Möchte man diese Aufgabe mit DISM für bereits existierende Images erledigen, ist der Ablauf in etwa der folgende:

1
2
3
4
dism /Mount-Wim /MountDir:C:\Mount /WimFile:C:\Image.wim /index:1
mkdir C:\Mount\Windows\Panther\Unattend
copy "C:\unattend.xml" C:\Mount\Windows\Panther\Unattend
dism /Unmount-Wim /MountDir:C:\Mount /commit

Damit wird das Image mittels DISM (schreibend) bereitgestellt, die Antwortdatei an den passenden Pfad kopiert und das Image zurückgeschrieben. Die Antwortdatei selber kann man mit Hilfe des "Windows System Image Manager" (SIM) erzeugen, welcher Bestandteil des WAIK und WADK ist. Nötig sind hierbei mindestens folgende Angaben im Teilbereich oobeSe

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <InputLocale>de-de</InputLocale>
            <SystemLocale>de-de</SystemLocale>
            <UILanguage>de-de</UILanguage>
            <UILanguageFallback>en-us</UILanguageFallback>
            <UserLocale>de-de</UserLocale>
</component>
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideLocalAccountScreen>true</HideLocalAccountScreen>
                <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
                <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>3</ProtectYourPC>
                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>
            </OOBE>
            <UserAccounts>
                <AdministratorPassword>
                    <Value>P@$$w0rd!</Value>
                    <PlainText>true</PlainText>
                </AdministratorPassword>
            </UserAccounts>
            <TimeZone>W. Europe Standard Time</TimeZone>
</component>

Damit werden die nötigen Eingaben vollständig automatisiert, der geklonte Server bootet nach dem Ausrollen des Images mehrfach durch, bis er abschliessend am Login steht. Das Administrator-Kennwort ist hier mit "P@$$w0rd!" festgelegt, kann aber geändert werden.

Wenn mann ohnehin eine Antwortdatei nutzt, kann man damit auch gleich noch weitere Einstellungen setzen, z.B.:

- Autologin
- Firewall abschalten
- Automatischen Start des Servermanagers abschalten
- Verstärkte Sicherheit im IE abschalten
- Remotedesktop einschalten
- Kennwort des lokalen Admin läuft nie ab
- uvm.

Die fertige Antwortdatei sieht dann in etwa so aus:

(Beispieldatei kann hier heruntergeladen werden)
4Apr/120

Windows Server 8 / 2012 – Wie man einen Domain Controller klont

Eine der Neuerungen in Windows Server 8 (oder  evtl. auch Windows Server 2012, offiziell gibt es wohl noch keinen endgültigen Namen) wird die Möglichkeit sein, Domänen-Controller klonen zu können (dies bezieht sich auf virtuelle Server). Das ganze möchte ich hier einmal kurz erläutern.

Bedingung:

  • Hypervisor muss "VM-Generation ID" unterstützen. Hyper-V 3.0 tut dies zum Beispiel
  • Der Inhaber der FSMO-Rolle "PDC-Emulator" muss unter Windows Server 8 laufen und erreichbar sein
  • Der zu klonende DC muss unter Server 8 laufen

Was ist zu tun?

  • Der zu klonende Domänen-Controller muss in die AD-Gruppe "Klonbare Doänen-Controller" ("Clonable Domain Controllers") aufgenommen werden
  • In dem Pfad, in dem die ntds.dit (Default: C:\Windows\NTDS) liegt, muss eine Datei mit dem Namen DCCloneConfig.xml liegen (Inhalt siehe unten)
  • Es müssen diejenigen Anwendungen auf dem DC identifiziert werden, die nicht kompatibel mit dem Klon-Vorgang sind (Get-ADDCCloningExcludedApplicationList)
  • Diese Anwendungen müssen in die Datei CustomDCCloneAllowList.xml eingetragen werden, welche ebenfalls im NTDS-Ordner abgelegt werden muss (Beispiel-Inhalt siehe unten)
  • Nun muss nur noch eine Kopie der virtuellen Festplatte erzeugt werden und diese mit einem neuen virtuellen Server verbunden werden (für Tests kann man auch zwei differenzierende VHDs erzeugen und diese auf VHD des Quell-DCs verweisen; der Quell-DC bekommt die eine, der neue DC die andere differenzierende VHD)
  • Zuerst den Quell-DC booten, danach den Klon
  • Nach der Installation von Treibern und Systemdiensten sollte der Klon nun beginnen, sich als DC-Klon zu erzeugen

Beispiel-Dateien:

DCCLoneConfig.xml

<?xml version="1.0"?>
<d3c:DCCloneConfig xmlns:d3c="uri:microsoft.com:schemas:DCCloneConfig">
    <ComputerName>VirtualDC3</ComputerName>
    <SiteName>Default-First-Site-Name</SiteName>
    <IPSettings>
        <IPv4Settings>
            <DynamicSettings>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <PreferredWINSServer></PreferredWINSServer>
                <AlternateWINSServer></AlternateWINSServer>
            </DynamicSettings>
        </IPv4Settings>
        <IPv6Settings>
            <DynamicSettings>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
            </DynamicSettings>
        </IPv6Settings>
    </IPSettings>
</d3c:DCCloneConfig>

 

CustomDCCloneAllowList.xml

<AllowList>
    <Allow>
      <Name></Name>
      <Type>Service</Type>
    </Allow>
    <Allow>
      <Name></Name>
      <Type>Program</Type>
    </Allow>
</AllowList>