Ist dies ein empfohlener / gültiger Ansatz für Dateiserverberechtigungen?

Dateiserver sind eine Tatsache in der IT und ich bin gespannt, ob es allgemein anerkannte Methoden gibt (ich zögere, hier das Wort "am besten" zu verwenden), wie Sie Gruppen erstellen und Berechtigungen zum Verwalten des Clientzugriffs auf einen freigegebenen Ordner anwenden ein Dateiserver.

Bei meinem derzeitigen Job habe ich eine ganze Reihe verschiedener Methoden geerbt, die von Dutzenden von Gruppen in den ACLs bis hin zum direkten Einfügen einzelner Benutzer in das Dateisystem reichen. Meine Aufgabe war es, das Chaos zu beseitigen und eine standardisierte Vorgehensweise im gesamten Unternehmen zu finden (große Umgebung, 150.000 Mitarbeiter, 90.000 Client-Computer, Hunderte von Dateiservern).

Nach meinem Verständnis des Problems benötigen Sie mindestens eine Gruppe pro erforderlicher Zugriffsebene pro gesicherter Ressource. Dieses Modell scheint die größte Flexibilität zu bieten, da Sie die Dateisystemberechtigungen nicht erneut berühren müssen, es sei denn, Sie müssen eine andere Zugriffsebene unterstützen. Der Nachteil ist, dass Sie mehr Gruppen erstellen als bei der Wiederverwendung derselben Gruppe über mehrere gemeinsam genutzte Ressourcen hinweg.

Hier ist ein Beispiel, das zeigt, was ich meine:

Auf einem Dateiserver mit dem Namen FILE01 befindet sich eine Freigabe mit dem Namen "Testergebnisse", und Sie haben Mitarbeiter, die nur Lesezugriff, Lese- / Schreibzugriff und vollständige Kontrolle benötigen. 1 gesicherte Ressource * 3 Zugriffsebenen = 3 Sicherheitsgruppen. In unserer AD-Umgebung erstellen wir diese als universelle Gruppen, sodass wir problemlos Benutzer / Gruppen aus allen Domänen in der Gesamtstruktur hinzufügen können. Da sich jede Gruppe eindeutig auf einen freigegebenen Ordner und eine freigegebene Zugriffsebene bezieht, enthalten die Gruppennamen diese "Schlüssel" -Daten und die Berechtigungen lauten wie folgt:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

In der Regel umfassen wir auch das integrierte SYSTEM-Konto und integrierte Administratoren mit Vollzugriff. Alle Änderungen, wer tatsächlich welchen Zugriff auf diese Freigabe erhält, können jetzt mithilfe von Gruppenmitgliedschaften behandelt werden, anstatt die ACL berühren zu müssen (entweder durch Hinzufügen von "Rollen" -Gruppen, die bestimmte Geschäftsrollen wie Manager, Techniker, QS-Analysten usw. darstellen, oder nur durch Einzelpersonen Benutzer für einmaligen Zugriff).

Zwei Fragen:

1) Ist dies tatsächlich ein empfohlener oder gültiger Ansatz für den Umgang mit Berechtigungen oder fehlt mir eine einfachere, elegantere Lösung? Ich würde mich besonders für Lösungen interessieren, die Vererbung verwenden, aber dennoch die Flexibilität behalten, große Teile der Dateisysteme nicht erneut zu ACLen, wenn sich die Dinge ändern.

2) Wie gehen Sie mit Dateiserverberechtigungen und Gruppenstrukturen in Ihrer Umgebung um? Bonuspunkte für diejenigen, die auch in großen Umgebungen arbeiten.

Mein Ansatz besteht darin, keine Dateiberechtigungen auf Datei- / Verzeichnisebene zu verwenden. Verwenden Sie Berechtigungen auf Dateifreigabeebene und setzen Sie das gesamte Datenlaufwerk des Server-Dateisystems auf Jeder Vollzugriff (was nicht mehr möglich ist).

Im Laufe der Jahre (10+) habe ich festgestellt, dass NTFS-Berechtigungen komplexer sind und zu mehr Fehlern führen. Wenn die Berechtigungen falsch festgelegt sind oder die Vererbung beschädigt wird, legen Sie Daten offen und es ist schwierig, sie zu finden und zu sehen. Außerdem sind Sie dem Problem des Verschiebens / Kopierens ausgesetzt. Benutzer, die Dateien verschieben, verschieben auch die ACL der Datei, während copy die Ziel-ACL erbt.

Verwenden Sie Ihre Lese- / Schreibgruppen gleich, jedoch für die gesamte Dateifreigabe mit Comp Mgmt MMC. Nicht voll machen ... Benutzer werden sich mit Teilwissen / besten Absichten erschießen.

Dieser Ansatz ist nicht schlecht. Verwenden Sie in der Regel niemals einzelne Benutzer, um Berechtigungen hinzuzufügen. Verwenden Sie eine Gruppe. Gruppen können jedoch ressourcenübergreifend verwendet werden. Beispielsweise hat HR möglicherweise RW-Zugriff auf Dateien, während MANAGERS möglicherweise R hat. Sie können auch Access Based Enumeration einrichten. Schauen Sie sich den folgenden Webcast an:

TechNet Webcast: Windows Server 2003-Verwaltungsserie (Teil 4 von 12): Gruppenverwaltung (Stufe 200)

Zugriffsbasierte Aufzählung kann das Leben auch einfacher machen:

Zugriffsbasierte Aufzählung

ABE kann dazu beitragen, die Anzahl der verschiedenen Freigaben zu reduzieren, die Sie verwalten müssen.

Ihr Ansatz ist im Grunde so, wie ich ihn angehen würde.
Die einzigen Dinge, die ich hinzufügen würde, sind diese:

1) Ich würde Ihr "Rollen" -Schema ergänzen, indem ich bewerte, was sie auf Servern benötigen, nicht nur auf einem Server, auf den Sie wahrscheinlich stoßen werden, aber meine Theorie mit diesen ist, wenn Sie auf sie stoßen, erstellen Sie eine andere Gruppe. Nach meiner Erfahrung gibt es dort, wo es einen Ausreißer gibt, viele.

2) Ich würde die Notwendigkeit von Universal-Gruppen für alles STARK neu bewerten, wenn Sie einen Replikationstreffer mit ihnen machen, da die Mitglieder und Gruppen innerhalb der Universal-Gruppe auf die globalen Katalogserver repliziert werden, während bei Domain Local und Global nur die Gruppe vorhanden ist auf die globalen Katalogserver repliziert. Wenn Sie also eine Änderung in einer universellen Gruppe vornehmen, wird eine Replikation gestartet, bei global und lokal nicht.

Ihre Methode zur Verwendung der Ressourcengruppe für jede Zugriffsebene ist korrekt. Das einzige, was ich in Betracht ziehen würde, ist die Verwendung lokaler Domänengruppen für Ressourcen. Sie müssen nicht unbedingt universelle Gruppen verwenden, wenn Sie serverspezifische Ressourcengruppen erstellen.

Der Nachteil der Verwendung lokaler Domänengruppen für Ressourcen besteht darin, dass Sie am Ende mehr Gesamtgruppen haben. Der Vorteil ist, dass Sie weniger Probleme mit der Replikation haben, wie Zypher feststellte.

Der vorgeschlagene Ansatz scheint ziemlich solide zu sein. Eine Sache, auf die Sie achten sollten, ist die Art und Weise, wie Sie die Dateifreigaben ursprünglich eingerichtet haben. Es wird empfohlen, eine einzelne Freigabe der obersten Ebene zu haben, die Unterordner enthält, denen Sie dann die Gruppenberechtigungen zuweisen. NTFS kann dann den "Ordner durchlaufen / Datei ausführen" im Ordner der obersten Ebene umgehen und Zugriff auf den Unterordner gewähren.

Die Struktur würde dann wie folgt aussehen: \ Servername \ Freigabename \ Gruppenordner, wobei Freigabeberechtigungen nur für den Ordner "Freigabename" und die tatsächlichen NTFS-Berechtigungen für den Ordner "Gruppenordner" festgelegt werden müssen.

Ihr Dateiserver kann auch mit dieser Art von Einrichtung eine bessere Leistung erzielen.

Im Allgemeinen würde ich eine Namenskonvention für die Gruppen festlegen, sodass der Gruppenname mit dem Namen des Gruppenordners übereinstimmt (wobei FC / RW / RO angehängt wird, falls gewünscht), und die UNC in der Gruppenbeschreibung an den Ordner kleben (Damit Ihr Anmeldeskript es zurücklesen und auf diese Weise eine Laufwerkszuordnung festlegen kann und Sie leichter sehen können, welche freigegebenen Ordner für welche Gruppen gelten).

Die Standardpraxis, die ich seit Windows 2000 für Windows-Dateiserver verwende (beschrieben in Mark Minasis Mastering Windows Server-Serie, suchen Sie dort nach weiteren Informationen), besteht darin, Gruppen, die lokal auf dem Dateiserver selbst sind, zum Verschachteln zu verwenden.

Stellen Sie sich beispielsweise einen Dateiserver mit dem Namen KERMIT in einer Domäne mit dem Namen MUPPETS vor.

Angenommen, KERMIT hat einige Dateifreigaben:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Erstellen Sie für KERMIT lokale Gruppen für den Zugriff und erteilen Sie ihnen Berechtigungen für das Dateisystem genau so, wie Sie es angegeben haben (dh eine Gruppe pro Zugriffsebene pro Freigabe).

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Da es sich um lokale Gruppen handelt, können Sie beliebige andere Gruppen oder Benutzer in diese einfügen - lokale Domänengruppen, globale Gruppen, universelle Gruppen, Benutzerkonten aus einer beliebigen Domäne in Ihrer Gesamtstruktur. Die Rechteverwaltung erfolgt jetzt lokal für die Gruppen des Dateiservers und nicht mehr für das Dateisystem oder den AD.

Dies fügt Ihrer Gruppenverwaltung zwar eine zusätzliche Ebene hinzu, hat jedoch den Vorteil, dass beispielsweise standortlokale Administratoren ihre eigenen Dateiserver verwalten können, ohne dass mehr als Administratorrechte für diesen Dateiserver erforderlich sind. Wenn Sie eine föderierte Zweigstellenstruktur haben, in der jede Büroart ihre eigenen Aufgaben mit ihren Servern erledigt, kann dies ein echter Vorteil sein. Möglicherweise möchten Sie nicht ein paar Dutzend lokalen Site-Administratoren AD-Administratorrechte erteilen müssen.

Außerdem wird verhindert, dass Ihre AD mit vielen Gruppen überfüllt ist (eine Gruppe pro Zugriffsebene pro Freigabe pro Server kann sich sehr schnell summieren), und die Gruppenreplikation zwischen GCs wird minimiert. Sie können Ihre AD-Gruppen für Rollen anstelle von Berechtigungen reservieren.

Wenn Ihre Umgebung streng standardisiert ist und alle Dateiserver identisch und repliziert sind, ist dies offensichtlich eine weitere Gruppenebene, die Sie nicht benötigen. Wenn Sie wissen, dass Sie eine bestimmte AD-Gruppe benötigen, um dieselben Rechte für eine Freigabe zu haben, die auf jedem einzelnen Dateiserver vorhanden ist, benötigen Sie eine gewisse Automatisierung, um dies aufrechtzuerhalten.

Kurz gesagt, je unterschiedlicher Ihre Dateiserver voneinander sind, desto sinnvoller ist es, lokale Gruppen von Computern zu verwenden. Je ähnlicher sie sind, desto mehr möchten Sie das aktuell verwendete System verwenden.

Ich habe eine Migration von NetWare zu Windows Server 2008 in Betracht gezogen, daher habe ich in letzter Zeit viel darüber nachgedacht. Server 2008 (und in gewissem Maße auch Server 2003R2) verfügen über einige sehr nette Funktionen, die diesen Übergang wirklich erleichtern. Server 2008 wird standardmäßig mit Access Based Enumeration geliefert. Dies ist eine sehr nette Funktion, mit der Benutzer nur Verzeichnisse sehen können, für die sie Rechte haben. Wenn Sie einen Anteil haben wie ...

\\ user-home-srv \ Homes \

Ohne ABE würde der Endbenutzer Zehntausende / Hunderttausende von Verzeichnissen sehen. Mit ABE würde der Endbenutzer nur einen sehen. Gleiches gilt für Aktien. Mit ABE können Sie auf Wunsch ein einziges großes Volumen für alle Abteilungsverzeichnisse haben und Ihre Benutzer nicht mit Verzeichnissen spammen, in die sie nicht gelangen können. Obwohl es sich nicht um ein ACL-Problem handelt, ist es etwas verwandt, daher spreche ich es an.

Eine andere Sache, die Server 2008 besser zu machen scheint als seine früheren Versionen, ist die ACL-Vererbung. Es scheint nur schneller zu sein, eine ACL-Änderung oben auf einem großen Baum auf das Blatt zu übertragen.

Aufgrund unseres Netware-Erbes haben wir eine große Anzahl von Gruppen, die nach ihrer Person benannt werden. Einige Gruppen sind nach dem benannt, auf das sie Zugriff gewähren. Für Verzeichnisse mit reguliertem Zugriff verwenden wir auch die Nomenklatur "RO" "Voll".

Wir haben ein monolithisches "freigegebenes" Volume (immer noch unter NetWare, aber wir planen, es monolithisch zu haben, wenn wir zu Windows wechseln), das das einzige gemeinsam genutzte Volume für alle 4.400 Mitarbeiter ist und über 3,5 Millionen Dateien enthält. Die Verzeichnisse der obersten Ebene sind alle Abteilungsnamen, und jede Abteilung regelt, was in ihnen vor sich geht. Es gibt einige Ausnahmen für die wirklich großen Abteilungen, die eine zweite Ebene von Verzeichnissen mit ACLs haben.

Bei meinem letzten Job konnten wir sogar Berechtigungen einrichten, damit HR-Mitarbeiter, die sich für Jobs bewerben, ihre eigenen Anwendungsdaten nicht auf ihrem Server sehen können. Dazu waren einige Vererbungsrechtsfilter erforderlich, die dem Tag "Blockvererbung" unter Windows ähneln. Der schwierige Teil dort war, alles zu dokumentieren, aber es hat funktioniert .

Ein Best-Case-Szenario besteht darin, dass jeder Benutzer nur einer Sicherheitsgruppe für die Jobrolle des Benutzers hinzugefügt wird. Die Rolle wird dann bei Bedarf delegierter Zugriff.

Ebenso sollte einem freigegebenen Ordner der Zugriff mithilfe von "Ressourcen" -Sicherheitsgruppen gewährt werden, wie in Ihrem Beispiel "FILE01-Testergebnisse-RW". Dies enthält die Jobrollen, Abteilungsrollen oder andere zutreffende Gruppen.

Der Vorteil dieses Entwurfs besteht darin, dass Sie den Zugriff pro Gruppe (Team, Abteilung usw.) delegieren und keinen einmaligen Zugriff, der möglicherweise schwer nachzuverfolgen ist. Wenn ein Benutzer in eine andere Abteilung wechselt, müssen Sie den gesamten alten Zugriff bereinigen.

Der Nachteil ist, dass Gruppen missbraucht werden können. Machen Sie klare Unterscheidungen darüber, wofür die Gruppen verwendet werden, damit Ressourcengruppen, die einer Freigabe zugewiesen sind, nicht wiederverwendet werden, als wären sie Abteilungsgruppen, was zu einem Wirrwarr des Zugriffs führt.