Best Practice für die Berechtigungsvergabe auf Fileservern

Windows NTFS Berechtigungen optimal setzen

(Version vom 30.03.16, Autor: Thomas Gomell t.gomell(at)aikux.com)

Einleitung

Wir haben dieses Dokument als Einführung in die Berechtigungsvergabe auf Microsoft Windows Fileservern konzipiert. Es wird erläutert, welche Berechtigungen es gibt, wie man sie vergibt und welche Vor-Überlegungen dafür nötig sind.

Berechtigungen regeln den Zugriff auf die Verzeichnisse und Dateien, weshalb es wichtig ist, ihre Vergabe wohldurchdacht zu handhaben. Sind die Berechtigungen zu locker vergeben, kann unter Umständen jeder auf die Arbeitsverträge aller Mitarbeiter oder andere vertrauliche Daten zugreifen. Sind sie jedoch zu restriktiv vergeben, wird das Arbeiten erschwert, da eventuell Mitarbeiter nicht auf für sie relevante Daten zugreifen können, um sie zu bearbeiten.

Am wichtigsten ist wohl, die Rechtevergabe so transparent wie möglich zu gestalten, da es sonst fast unmöglich wird, die NTFS-Rechte zu administrieren. Die fehlende Übersicht ist auch aus unserer Erfahrung heraus eine wesentliche Ursache für die Probleme, die sich aus der Berechtigungsvergabe ergeben. Abhilfe schaffen hier gut angepasste Berechtigungskonzepte und spezielle Tools, die weit über die Möglichkeiten der Microsoft Bordmittel hinausgehen. Wir gehen sehr detailliert auf die Bordmittel von Microsoft ein, die allerdings gerade im Bereich Berechtigungsverwaltung eingeschränkt sind. Aus diesem Grund bringen wir auch Verweise zu eigenen und fremden Tools, die uns jeweils besser geeignet erscheinen.

Falls Fragen offen geblieben sind, können Sie sich auch direkt an mich wenden.

Doch widmen wir uns zunächst den Grundlagen:

1. Überblick – Fileserver-Berechtigungen allgemein

Berechtigungen sind auf jedem Fileserver notwendig, damit nur die Benutzer auf Dokumente zugreifen können, die es auch sollen. Es gibt verschiedene Varianten, das zu ermöglichen. Zum ersten sind es die Share-Berechtigungen, die man allerdings so offen wie möglich gestalten sollte (z.B. authentifizierte Benutzer –> Vollzugriff), um letztendlich den Zugriff über die NTFS-Berechtigungen (Berechtigungen im Filesystem) einzuschränken. Bei der Vergabe von Berechtigungen ist auch darauf zu achten, dass man diese möglichst flach hält (maximal bis zur 5. Verzeichnisebene ab Share), damit das System noch überschaubar bleibt und das Kerberos-Token (Anmeldetoken, weiter unten genauer erklärt) nicht zu groß wird. Auch sollte darauf geachtet werden, so wenig unterschiedliche Berechtigungen wie möglich zu setzen. Das bedeutet, dass man Verzeichnisse anlegt, auf welche die gesamte Abteilung „lesen und ausführen“ bekommt und nur diejenigen User „ändern“ bekommen, die es tatsächlich auch benötigen.

Zu beachten!

Bei der Neuinstallation eines Fileservers ist es empfehlenswert, als erstes den „Ersteller und Besitzer“ zu entfernen oder zumindest anzupassen. Denn dieser „Dummy-User“ bewirkt, dass derjenige, der ein Dokument erstellt, auch der Besitzer wird und Vollzugriffsrechte auf diese Dateien/Ordner erhält. In diesem Fall könnte der Ersteller auch Berechtigungen vergeben oder verweigern mit dem Ergebnis, dass Administratoren oder der Backup-User nicht mehr auf Dateien oder ganze Verzeichnisse zugreifen können.

Wie oben schon erwähnt, sollte man auch die Shares berechtigen. Hier empfiehlt es sich nicht, wie standardmäßig „Jeder“ zu berechtigen, sondern das Ganze auf „Authentifizierte Benutzer“ oder noch besser „Domänen-Benutzer“ oder Abteilungsgruppen einzuschränken. Hier ist auch zu empfehlen, dass nicht – wie früher üblich – Vollzugriff vergeben wird, sondern nur “Ändern”-Rechte. Dies verhindert, dass die Besitzer eines Verzeichnisses deren Rechte verändern können.

Auch sollte man dafür sorgen, die Shares so anzulegen, dass möglichst keine Shares innerhalb eines anderen Shares entstehen. Eine Verschachtelung der Shares hätte zur Folge, dass man eventuell in einer tieferen Ebene plötzlich Zugriffsrechte bekommt, die aber weiter oben in dem Share nicht ersichtlich sind –> Transparenz. Die Shares wählt man deshalb so, dass man schon dadurch einen Zugriff verhindern kann –> Denn wenn ein Share nur für eine Abteilung beziehungsweise deren AD-Gruppe zugänglich ist, können andere User gar nicht erst darauf zugreifen.

Das Kerberos-Token-Problem

Das Kerberos-Token dient zur Authentifizierung an Windows-Servern und beinhaltet neben der SID auch die Gruppenzugehörigkeiten. Es ist in der Größe beschränkt und wurde im Laufe der Jahre und über verschiedene Windows-Versionen in seiner Größe angepasst. Wenn ein User allerdings in zu vielen Gruppen Mitglied ist und die maximale Größe des Tokens überschritten wird, können sich die Benutzer nicht mehr an ihrem System anmelden. Darauf ist auch bei der Vergabe der Berechtigungen und Gruppen zu achten.

Lokale Gruppen (40byte) belegen mehr Speicher als globale (8byte) oder universelle (8byte in der eigenen Domäne, 40byte in einer fremden Domäne), die beiden letztgenannten werden bei der MS Formel mit einem Fünftel der Größe der lokalen Gruppen berechnet. Globale und universelle belegen denselben Speicher. Der Unterschied ist, dass globale Gruppen nur Benutzerkonten oder andere globale Gruppen aufnehmen können, die zur eigenen Domäne gehören. In universale Gruppen können dagegen Benutzerkonten oder globale Gruppen aller Domänen aufgenommen werden, zu denen eine Vertrauensstellung besteht. Wenn es sich um universelle Gruppen einer anderen Domäne handelt, belegen diese so viel Speicher wie Domänenlokale Gruppen.

2. ABE (Access Based Enumeration)

Als weiterer Punkt ist die ABE zu erwähnen. Access-based Enumeration, abgekürzt ABE, bedeutet übersetzt „zugriffsbasierte Auflistung“ oder besser „berechtigungsgesteuerte Auflistung“. Dem Anwender werden im Windows-Explorer nur noch diejenigen Verzeichnisse und Dateien aufgelistet, für die er auch Zugriffsrechte besitzt. Alle anderen Ordner und Dateien sind ausgeblendet. Die ABE kann man ab Windows 2008 Servern aktivieren, indem man im Servermanager unter „Freigabe- und Speicherverwaltung“ die entsprechende Freigabe auswählt, dort mit einem Rechtsklick die Eigenschaften aufruft, im ersten Reiter (Freigabe) auf „Erweitert“ klickt und dort dann „Zugriffsbasierte Aufzählung aktivieren“ auswählt.

ABE ist eine Funktion, die beim Novell Filesystem schon immer zum Standard gehört hat.

Dem ABE kommt eine extrem hohe Bedeutung zu. War es ohne ABE notwendig sehr tiefe Verzeichnisstrukturen zu bauen, damit die User eine gewisse Struktur finden, über die sie die Daten wiederfinden können, ist es mit ABE möglich, extrem flache Verzeichnisstrukturen aufzubauen. Jeder User sieht jetzt nur noch die Verzeichnisse, auf die er tatsächlich berechtigt ist.

Hier ein Beispiel für einen stark strukturierten Verzeichnisbaum:

image

Empfehlung: Der gleiche Verzeichnisbaum aber in flach mit ABE.

image

Ergebnis durch ABE

image

Die Mitglieder von Team 1 sehen nur das Verzeichnis “Team 1” und der Teamleiter sieht noch das “Team 1 Leiter” Verzeichnis. Und kann man sich dann auch noch fragen, ob es eigentlich flach genug ist. Vielleicht sollten man auch noch den Inhalt von “Team 1” nach oben packen.

Warum macht man das: Weil es für die User von Vorteil ist! Warum sollen die sich erst durch viele Ebenen kämpfen, wenn Sie auch direkt ran kommen könnten.

Dies ist natürlich nur ein stark vereinfachtes Beispiel zeigt aber sehr schön die Möglichkeiten auf. Neben der nachfolgend beschriebenen Aktivierung von ABE ist aber vor allem die saubere Berechtigungsvergabe von Listrechten auf den Verzeichnissen wichtig. Den richtigen Aufbau finden Sie in Artikel 7.


Best Practice für Berechtigungsvergabe auf Fileservern

Abbildung 1: Aktivieren der ABE auf 2008 Windows Servern

image

Abbildung 2: Aktivierung von ABE unter 2012 Server

image

Wenn gleichzeitig noch ein DFS eingesetzt wird, ist es wichtig auf dieser Seite das ABE zu aktivieren. Jeder Haken wirkt nur in seinem Bereich! Die Eintragung im DFS muss allerdings manuell gemacht werden.

2.1 Automatisches Restrukturieren des Verzeichnisbaumes

Strukturen flach gestalten –> wirklich eine schöne Aussage. Spätestens an dieser Stelle wird das Projekt meistens abgebrochen. Trauriges Smiley

Man braucht also ein Lösung für diesem komplexe Vorhaben, bei dem automatisch sauber alle neuen Berechtigungen aufgebaut werden, die neuen Verzeichnisstrukturen erzeugt werden und auch die Daten an genau an die richtige Stelle verschoben werden, ohne dass ein User unter dieser Maßnahme leidet.

Und genau an dieser Stelle kommt auch wieder migRaven.one zum Einsatz.

Im übersichtlichen Tabellenmodus werden Source Verzeichnis auf neue Ziel umgemappt gleichzeitig die neuen Rechte definiert.

image

 

Nach dem speichern dieser Tabelle werden automatisch alle Zielstrukturen automatisch aufgebaut: Alle neuen Gruppen werden sauber gebildet: Egal ob es für 20 oder 20.000 in einem Arbeitsgang ist.


image

Besondern spannend an migRaven.one ist, dass auch Copy Scripte automatisch gebildet werden.

Um bei diesem Beispiel zu bleiben:

Die Daten vom Verzeichnis “\Austausch” werden in das Zielsystem “\Austausch” kopiert, bis auf die drei Unterordner.

Die drei Unterordner werden an ihren neuen Bestimmungsort kopiert.

3. NTFS-Berechtigungen – welche gibt es, was bewirken sie?

Die NTFS-Berechtigungen sind die Berechtigungen, die im Filesystem ansetzen und dort den Zugriff der User regeln. Es gibt verschiedene NTFS-Berechtigungen, um Zugriffe zu erlauben oder diese zu verweigern. Folgende Berechtigungen stehen zur Auswahl:

  • Lesen – Lesen von Dateien, Anzeigen von Dateiattributen, Besitzern und Berechtigungen.
  • Schreiben – Überschreiben von Dateien, Ändern von Dateiattributen, Anzeigen von Dateibesitzern und Berechtigungen.
  • Lesen und Ausführen – Ausführen von Anwendungen und alle Aktionen, welche die Berechtigung „Lesen“ gestattet.
  • Ändern – Ändern und Löschen von Dateien, Ausführen von Aktionen, welche die Berechtigungen „Schreiben“, „Lesen und Ausführen“ gestatten.
  • Vollzugriff – Ändern von Berechtigungen, Besitzübernahme, Ausführen von Aktionen, die alle übrigen NTFS-Ordnerberechtigungen gestatten.

Es wird oft angenommen, dass man zum Erstellen, Öffnen, Bearbeiten und Löschen von Ordnern und Dateien auch die Berechtigung „Vollzugriff“ benötigt. Das ist falsch. Es wird lediglich das Recht „Ändern“ benötigt. „Ändern“ beinhaltet all das, was ein normaler User zum Arbeiten braucht. Das Recht „Vollzugriff“ gibt dem User das Recht, auch Berechtigungen zu ändern bzw. zu vergeben, was in einer Firma den Administratoren vorbehalten bleiben sollte, um ein Chaos in der Berechtigungsvergabe zu vermeiden. Zur Erläuterung: Durch ein Vollzugriffsrecht für User kann auch der Zugriff verweigert werden, was in der Praxis leider auch vorkommt und besonders problematisch ist, wenn beispielsweise der Administrator oder der Backup-User betroffen ist. Darüber hinaus gibt es noch die folgenden erweiterten Berechtigungen.

Best Practice für Berechtigungsvergabe

Abbildung 2: Zur Verfügung stehende Standardrechte

Best Practice für Berechtigungsvergabe

Abbildung 3: Erweiterte Berechtigungen

  • Vollzugriff – erteilt dem Benutzer oder der Gruppe alle Berechtigungen für eine Ressource.
  • Ordner durchsuchen/Datei ausführen – „Ordner durchsuchen“ gestattet oder verweigert das Durchsuchen von Ordnern, um auf andere Dateien oder Ordner zuzugreifen – selbst dann, wenn der Benutzer keine Berechtigungen für den durchsuchten Ordner besitzt. „Datei ausführen“ gestattet oder verweigert die Fähigkeit zum Ausführen von ausführbaren Dateien (Anwendungsdateien).
  • Ordner auflisten/Daten lesen – „Ordner auflisten“ gilt nur für Ordner, gestattet oder verweigert die Anzeige von Datei- und Unterordnernamen innerhalb eines Ordners. „Daten lesen“ gilt nur für Dateien, gestattet oder verweigert die Anzeige der Dateiinhalte.
  • Attribute lesen – gestattet oder verweigert die Anzeige der Datei- oder Ordnerattribute, die vom NTFS festgelegt werden.
  • Erweiterte Attribute lesen – gestattet oder verweigert die Anzeige der Datei- oder Ordnerattribute, die von Programmen festgelegt werden. Erweiterte Attribute werden durch Programme definiert und können sich von Programm zu Programm unterscheiden.
  • Dateien erstellen/Daten schreiben – Die Berechtigung „Dateien erstellen“ gilt nur für Ordner und gewährt oder verweigert dem Benutzer das Recht, Dateien in dem jeweiligen Ordner zu erstellen. Die Berechtigung „Daten schreiben“ gilt nur für Dateien und gewährt oder verweigert dem Benutzer das Recht, eine Datei zu ändern und deren Inhalt zu überschreiben.
  • Ordner erstellen/Daten anhängen – Die Berechtigung „Ordner erstellen“ gilt nur für Ordner und gewährt oder verweigert dem Benutzer das Recht, Ordner in dem jeweiligen Ordner zu erstellen. Die Berechtigung „Daten anhängen“ gilt nur für Dateien und gewährt oder verweigert dem Benutzer das Recht, Änderungen am Ende einer Datei vorzunehmen, nicht jedoch bereits existierende Inhalte zu ändern, zu löschen oder zu überschreiben.
  • Attribute schreiben – gestattet oder verweigert die Änderung der Datei- oder Ordnerattribute, die von NTFS festgelegt werden.
  • Erweiterte Attribute Schreiben – gestattet oder verweigert die Änderung der erweiterten Datei- oder Ordnerattribute. Erweiterte Attribute werden durch Programme definiert und können sich von Programm zu Programm unterscheiden.
  • Unterordner und Dateien löschen – gestattet und verweigert das Löschen von Unterordnern oder Dateien in einem Ordner – selbst dann, wenn für den betreffenden Unterordner oder eine jeweilige Datei nicht die Berechtigung „Löschen“ erteilt wurde
  • Löschen – gestattet oder verweigert das Löschen von Dateien und Ordnern
  • Berechtigungen lesen – ermöglicht dem Benutzer das Lesen der einer Datei oder einem Ordner zugewiesenen Berechtigungen
  • Berechtigungen ändern – ermöglicht dem Benutzer das Ändern der einer Datei oder einem Ordner zugewiesenen Berechtigungen (ohne Berechtigung „Vollzugriff“)
  • Besitzrechte übernehmen – gestattet oder verweigert die Übernahme der Besitzrechte für Dateien und Ordner. Der Besitzer einer Datei kann die Berechtigungen für eine Datei oder einen Ordner immer ändern, unabhängig von den für die Datei oder den Ordner festgelegten Berechtigungen

Die speziellen Berechtigungen sollte man allerdings, genau wie auch das Verweigern von Berechtigungen, nur in Sonderfällen benutzen. Ein Verweigern ist unter normalen Umständen nicht notwendig, da bei einer durchdachten Verzeichnisstruktur die User auch nur dort Zugriff haben, wo sie ihn benötigen. Wenn man in Versuchung gerät, auf ein Verzeichnis einem Benutzer oder einer Gruppe den Zugriff zu verweigern, sollte man darüber nachdenken, die Vererbung zu unterbrechen und die Berechtigungen für dieses spezielle Verzeichnis neu zu vergeben.

3.1 Analyse von NTFS Berechtigungen

Die Analyse der vergebenen NTFS Berechtigungen in der Microsoftwelt ist relativ aufwendig. Hier spielen die empfohlenen Best Practices sich gegenseitig aus:

  • Man soll nicht User direkt berechtigen, sondern nur über Gruppen: Dann sehe ich nur eine Gruppe in den ACLs und habe leider keinen Plan, wer tatsächlich auf einem Verzeichnis berechtigt ist. Gleichzeitig habe ich den Vorteil, dass bei einer Vergabe von Berechtigungen über Gruppen die Berechtigungserweiterung recht schnell geht, weil es nur eine Aktion im AD ist.
  • Wenn man User direkt berechtigt, dann sieht man sehr schön, wer genau berechtigt ist, aber hat z.B. Nachteile bei der Berechtigungsvergabe.

Irrglaube: Nun hält sich ja unter Administratoren hartnäckig der Irrglaube, dass man bei einer Berechtigungsvergabe über Gruppen aus dem AD wenigstens nachvollzogen werden kann, wo ein User alles berechtigt ist. Leider kann man davon ausgehen, dass:

  • Ein Großteil der Verzeichnisse nicht mehr vorhanden ist, es aber noch die Berechtigungsgruppe gibt
  • Der Name des Verzeichnisses vom Gruppennamen oder der Dokumentation abweicht.
  • Verzeichnisse in der Zwischenzeit verschoben wurden und die Berechtigungen beim Verschieben mit übertragen wurden. Aus diesem Grund existieren nun an Stellen Rechte, die sie niemals finden werden ohne ein spezialisiertes Tool.

Mit migRaven.one haben Sie die Möglichkeit über eine Datenbank gestützte View die effektiven jederzeit im Detail über alle Gruppenverschachtelungsebenen hinweg sehen zu können. Z.B. beim Recht “Modify Plus” sieht man sehr schön, dass dort die Gruppe “zz8_public_austausch_mx” berechtigt ist, die die Gruppe “aikux_team” enthält, die wiederum 18 User Accounts enthält.

Da vor dem Verzeichnis “Für André” im Gegensatz zum Verzeichnis “Für Bernd” kein blauer Pfeil ist, kann ich mir auch sicher sein, dass unterhalb keine abweichenden Rechte mehr existieren.



image
image

Die Visualisierung der Berechtigungen ist im Übrigen auch mit der Testversion von migRaven.one in vollem Umfang möglich. Dies war auch nur ein Ausschnitt aus den vielfältigen Möglichkeiten.

4. Die Vergabe von NTFS-Berechtigungen auf einem Share bzw. einer Freigabe

Ein Share ist wie eine Gartentür zu verstehen, die ein Haus mit einem eigenen Schließsystem umschließt. Dort kann man das Recht setzen, dass man überhaupt erstmal in den Garten kommt. Die NTFS-Rechte sind dann die einzelnen Türen in dem Gebäude, die wiederum mit Schlössern versehen sind. Hier empfiehlt sich mit differenzierten Rechten zu arbeiten. Z.B. Administratoren bekommen „Vollzugriff“ und Domänenbenutzer oder Authentifizierte Benutzer bekommen „Ändern“. Die Einschränkung der Rechte für bestimmte Benutzergruppen ist besonders wichtig, weil: Es ist möglich, dass man auf NTFS-Ebene mehr Rechte hat als gewünscht. Bildlich gesprochen ist die Tür über NTFS breiter als im Share. Wenn man jetzt aber durch die Gartentür will, ist diese zu eng und man kommt nicht mehr durch. Dies ist in folgendem Punkt besonders wichtig.

Wenn ein User ein Verzeichnis erstellt, wird er auf NTFS-Ebene automatisch zum „Besitzer“ des Ordners und erhält dadurch gleich erweiterte Berechtigungen auf diesen Ordner. Es ist nämlich das Recht genau für diesen Ordner die Berechtigungen ändern zu können. Aber genau das will man in den meisten Fällen nicht. Wenn ein User versucht die Rechte zu ändern, würde das das NTFS-Recht zulassen, aber die „Ändern“ Rechte auf dem Share würde dies verhindern. Durch diesen Trick erspart man sich lästige Änderungen.

 

5. Die Vergabe von NTFS-Berechtigungen im Filesystem

Wie eingangs erwähnt, sollte man die Berechtigungen so „flach“ wie möglich gestalten, um eine gewisse Transparenz zu ermöglichen. Man kann die Berechtigungen sowohl auf Ordner als auch auf Dateien vergeben, wodurch ein Filesystem beliebig komplex werden kann. Die Vergabe der Berechtigungen erfolgt in der Regel durch AD-Gruppen (Active Directory Gruppen), damit zentral administriert werden kann.

Vergabe auf Ordner oder auf Dateien?

Die Vergabe der Berechtigungen bis auf Dateiebene ist nicht empfehlenswert, wenn man die Komplexität des Filesystems betrachtet. Man sollte also so weit möglich nur auf Ordner Berechtigungen vergeben, da bei einer Berechtigungsvergabe auch auf Dateien das gesamte Filesystem unter Umständen so unüberschaubar wird, dass es am Ende nicht mehr administrierbar ist.

Das A-G/U-G-P Prinzip – Gruppen oder direkt berechtigen?

Berechtigungen „sollten“ in einer single Domänenstruktur immer nach dem A-G-G-P- oder dem A-G-P-Prinzip vergeben werden. Andere Varianten werden notwendig, wenn mehrere Domänen verknüpft sind, oder sich im Forrest befinden. A-G-G-P sorgt aber vor allem dafür, dass die Security-Token nicht zu stark anwachsen. Man sollte an der Stelle auch nicht zu sehr auf oft veraltete Informationen aus Büchern hören, sondern seinem eigenen Verstand folgen.

    • A = Account
    • G/U = Globale Domänen Gruppe/Universelle Domänengruppe -> hier werden die User drin geclustert; z.B. alle Mitarbeiter des Einkaufs
    • G = Globale Gruppe -> diese wird zur Vergabe der Berechtigungen im Filesystem genutzt; z.B. eine Gruppe für das Recht „Ändern“ mit dem Namen: „DL_V1_V2_V3_md“; „md“ steht dann für modify; diese Gruppe nimmt entweder die globale Gruppe oder im Ausnahmefall einzelne User auf.
    • P = Permission

Man sollte sich angewöhnen, pro Berechtigung auch eine Gruppe im AD (Active Directory) anzulegen, z.B. „Verzeichnis_XY_ändern“ oder „Verzeichnis_AB_lesen“, die auch nur für diese Berechtigung benutzt wird, was die Berechtigungsvergabe wesentlich vereinfacht.

Da man nun überwiegend – außer bei der Einrichtung des Ordners – über Gruppen aus dem AD arbeitet, geht die Vergabe der Berechtigungen schneller und außerdem kann man einen Überblick über Berechtigungen bekommen, wenn man sich die Mitglieder der G-Gruppe anschaut. Da sollten jetzt nur noch die drin sein, die Berechtigungen haben. Leider ist dies eins trügerische Annahme, da man sich unter Microsoft so nie sicher sein kann, wer tatsächlich berechtigt ist. Leider ist Microsoft an dieser Stelle extrem intransparent. Hier empfehlen wir die Nutzung von Drittanbieter Tools zur effektiven Darstellung von Berechtigungen.

HINWEIS: Leider hält sich noch stark eine Interpretation des A-G-G-P-Prinzips aus NT Zeit. Deswegen hier noch mal der Hinweis zur Verwendung der Globalen Domänen Gruppe. Diese sollte tatsächlich eine Gruppe zur Clusterung der User nach einem Aufgabengebiet oder Organigramm sein (Z.B. Einkauf). In der Vergangenheit wurde die Domänen lokale Gruppen oft gedoppelt: DL_V1_md wurde dann auch noch G_V1_md. Dies führt nur zur Verdoppelung der Gruppen und hat auch nach Microsoft eigener Aussage keinen praktischen Nutzen.

Man sollte also NIE einen User direkt auf einen Ordner berechtigen, da auch dadurch die Transparenz verloren geht und bei einer Löschung der User und dem Versäumnis, die Berechtigung zu entfernen, nur die SIDs der User auf dem Verzeichnis bleiben (tote SIDs). Außerdem dauert das setzen der Berechtigungen unnötig lang. Außerdem (;-)) sorgen zu viele Einträge (ACE) in der ACL dafür, dass Zugriffe verlangsamt werden. Es können theoretisch ca. 1820 ACEs in einer ACL stehen – was aber nicht praktikabel ist. Mehr als 20 macht den Zugriff langsam: http://support.microsoft.com/kb/166348

Best Practice für Berechtigungsvergabe Bild 4

Abbildung 4: „Tote SIDs“

Was sich allerdings empfiehlt, ist das Anlegen von AD-Gruppen (z.B. Abteilungs- oder Projektgruppen), die auf mehrere Verzeichnisse berechtigt werden sollen, um nicht jedes Mal alle Benutzer einzeln in die entsprechenden Berechtigungsgruppen hinzufügen zu müssen. Need to know-Prinzip: Es sollten immer nur so viel Berechtigungen vergeben sein, wie der Mitarbeiter tatsächlich für seine Arbeit benötigt.

 

6. Vererbung von Zugriffsrechten

Die Vererbung der Berechtigungen bedeutet, dass die Berechtigungen eines Ordners, wie sie dort gesetzt sind, auch auf untere Ebenen übertragen werden. Das schließt natürlich nicht aus, in einer weiter unten gelegenen Ebene zusätzliche Berechtigungen hinzuzufügen. Auch durch einen sinnvollen Einsatz der Vererbung kann erreicht werden, dass ein Kerberos-Token nicht übermäßig groß wird. Man sollte in der obersten Ebene die Berechtigungen so setzen, dass man sie gut nach unten hin durchvererben kann. Am besten nur Mindestberechtigungen(LIST) auf root und dann die Berechtigungen erweitern.
Die Vererbung zu unterbrechen ist ganz schlechter Stil, weswegen man das nur in ganz seltenen Ausnahmefällen machen sollte. Durch saubere Planung und evtl. einer Anpassung der Filestruktur bekommt man es hin, das man gänzlich ohne Unterbrechung auskommen kann.

Best Practice für Berechtigungsvergabe aikux Bild 5
Abbildung 5: So sehen gesetzte Berechtigungen aus
Best Practice für Berechtigungsvergabe aikux Bild 6
Abbildung 6: So sehen geerbte Berechtigungen aus

7. Das Setzen der Listberechtigungen

Listrechte sind Berechtigungen, die vergeben werden, um den Usern das Browsen durch die Verzeichnisse zu ermöglichen. Wenn ein User im Share einsteigt, möchte er sich auch bis in das für ihn relevante Verzeichnis „durchklicken“ können. Wenn man nun aber in der 4. Ebene eine Berechtigung setzt, kann er das nicht zwangsläufig. Hierzu vergibt man auf die darüber liegenden Verzeichnisse das Recht „Ordner auflisten“ nur für diesen Ordner:


image

Abbildung 7: Listrechte vergeben

Zum Festlegen der Listrechte sind verschiedene Dinge zu beachten:

  1. Wie viele Verzeichnisse mit geänderten Berechtigungen habe ich unterhalb des Shares und den darauf folgenden Ebenen?
  2. Wie sieht die Gruppenzugehörigkeitslage bei den Usern aus? (Sind die User schon so in vielen verschiedenen Gruppen?)

Anhand dieser Begebenheiten muss man sich entscheiden, in welchen Ebenen man Listgruppen erzeugt und in welchen Ebenen man die Berechtigungsgruppen für die Listrechte benutzt.

Best Practice bei einer maximalen Berechtigungsvergabe bis zur 5. Verzeichnisebene ist, wenn man in der ersten und zweiten Verzeichnisebene Listgruppen einsetzt und in der 3. und 4. Ebene die Berechtigungsgruppen nutzt.


Best Practice für Berechtigungsvergabe aikux Bild 8

Abbildung 8: Verzeichnisebenen

Sofern man zum Beispiel nur die Berechtigungsgruppen benutzt ist hier zu beachten, dass in den obersten Ebenen eine Vielzahl an Gruppen in den Berechtigungen auftauchen, welche die Übersichtlichkeit stark reduzieren. Im Umkehrschluss werden die Gruppenzugehörigkeiten der User stark erhöht, wenn man nur Listgruppen benutzt.

Merke: Die Listgruppenvergabe ist individuell an jedes Filesystem und AD anzupassen.

7.1 Automatischer Aufbau der korrekten Berechtigungen

Wenn man einen Neuanfang auf der Berechtigungsebene wagt, dann wird einem sehr schnell klar welchen Aufwand dies macht. Wenn es sich um 20 Verzeichnisse handelt, dann ist meist noch alles OK. Wenn es aber um hunderte oder gar tausende von neu zu berechtigende Verzeichnisse geht, dann wird dies schnell zum Problem.

Es müssen zu jedem Berechtigungsendpunkt(jedes Verzeichnis, dass explizite Rechte hat) die entsprechenden Berechtigungsgruppen gebildet werden. Hinzu kommt, dass natürlich auch die Listberechtigungen sauber gesetzt werden müssen.

Und genau für diese Aufgabe ist migRaven.one entwickelt worden. Man kann in eines Sandbox sauber alle Berechtigungen vorbereiten, dann die Gruppen im AD erstellen und verschachteln lassen und dann die neuen Gruppen ausrollen.

Wichtig war bei der Entwicklung, dass es keine Blackbox Scripte gibt, sondern ein völlig tranzparentes Verfahren existiert, bei dem erst Änderungen im Echtsystem vorgenommen werden, wenn die Sandbox abgenommen wurde.

Man kann den Algorithmus sehr fein an die Anforderungen der eigenen Umgebung anpassen:

Man kann den Algorithmus sehr fein an die Anforderungen der eigenen Umgebung anpassen:

image

(Gruppentyp)

image

(Bildungsregel für den Gruppennamen)

image

(Aufbau der Listberechtigungen)

8. Wie geht man also vor?

  1. Herausfinden, wie groß das Kerberos-Token ist beziehungsweise in wie vielen Gruppen die User bereits Mitglied sind.
  2. Herausfinden, wie viele Verzeichnisse mit geänderten Berechtigungen benötigt werden.
  3. Entscheidung fällen, wie die Listrechte gesetzt werden sollen/müssen.
  4. Setzen der Grundberechtigungen in der ersten Ebene und diese nach unten vererben.
  5. Setzen der abweichenden Berechtigungen in den unteren Ebenen (von oben nach unten) und diese wieder nach unten vererben.
  6. Setzen der Listgruppen bzw. Listberechtigungen.

 

Fazit & Empfehlungen

In kleineren Umgebungen können die Berechtigungen durchaus von Hand vergeben werden, in größeren ist dies nicht mehr sinnvoll umsetzbar, da eine komplexe Berechtigungsstruktur unweigerlich in einem nicht mehr überschaubaren Chaos endet. Wenn man die Berechtigungsstrukturen also mit Excel-Tabellen und dergleichen pflegt, werden diese erfahrungsgemäß immer von der tatsächlichen Struktur abweichen, da immer wieder vergessen wird, eine schnell gemachte Änderung zu dokumentieren.