Kategorie: Windows Server

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):

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”:

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:

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

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:

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:

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:

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:

“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:

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:

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

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:

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:

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:

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:

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:

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.

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:

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.