Hierachische Verzeichnisstruktur mit Berechtigung je nach Ebene "X", oder "M" (entspricht "Linux Home-Logik")
Komplexe Verzeichnisstruktur mit Berechtigung so gesetzt, das für Teil der Struktur Recht "eXecute" und weiter oben "Modify" gesetzt wird.
Hi all,
ich baue für einen Kunden eine komplexe Verzeichnisstruktur mit ca. 20.000 leeren Verzeichnissen auf. Der Grundgedanke der Rechtevergabe ist sehr einfach und entspricht der normalen Rechtesetzung von Linux Homedirectories mit einem geschützten Bereich und einem offenen Bereich:
In einfachen Worten gesagt: "L_Schreibende" darf ab der Verzeichnisebene .\Verzeichnis_B Verzeichnisse und Dateien anlegen, bearbeiten und löschen, oberhalb davon nur lesen (bzw. ausführen)
Hier ein Prinzipbild mit 2 Strukturästen. Rot ist geschützt, Grün ist offen, Gestreift ist die kritische Verzeichnisebene:
Verwaltet wird die Rechtesetzung unter Nutzung des im Resource Kit enthaltenen Tools "xcacls".
Die Schwierigkeit ist definitiv das Recht auf VerzeichnisB, denn die normale Vorgehensweise unter Windows, die für mein Projekt nicht nutzbar ist, wäre, einen Share anzulegen. Ich brauche aber eine normale Rechtesetzung.
Die Vorgehensweise zum Festlegen der korrekten Rechte wären mehrere Skripte, mit denen erst das Grundrecht auf die gesamte Struktur eingestellt wird und dann der geschützte Bereich "verschlossen" wird. Somit könnte im Endergebnis der angehängte Bereich beliebig wachsen, die Grundstruktur bliebe erhalten.
Wer Linux kennt, dem ist klar, dass dies exakt der Unix Home-Directory - Logik entspricht.
Restriktionen:
- kein Samba-Server möglich, es handelt sich um Windows Server mit NTFS, Umstellung auf Active Directory geplant für Ende 2005
- Verwendung von Skripten ist ein Muss, da sonst nie mehr die geschützte Ebene wieder hergestellt werden kann.
- Mittelfristiges Ziel = Einsatz Dokumentenverwaltungssystem, z.Z. jedoch noch nicht möglich!
Offenbar gibt es keine vernünftige Lösung unter Windows! Ich habe mich für folgenden Workaround entschieden:
Die Berechtigung wird via Skript so gesetzt:
<li> geschlossener Bereich (rot):
xcacls.vbs [DIR] /G "Domain Admins":F "[Server]\L_PRJ__Read":X "[Server]\L_PRJ__Change":X /server [Server]</li>
<li> offener Bereich (grün):
xcacls.vbs [DIR] /G "Domain Admins":F "[Server]\L_PRJ__Read":X "[Server]\L_PRJ__Change":M /server [Server]</li>
In Worten bedeutet das:
Die Verzeichnisse im grauen Bereich werden vom Administrator angelegt, erhalten aber das Recht Modify für Projektmitarbeiter. Damit können Unterverzeichnisse und Dateien erzeugt, bearbeitet und gelöscht werden. Löscht jemand ein Verzeichnis im grauen Bereich, dann ist es weg! Nur eine Administrator kann es dann wieder erzeugen.
Die Sache ist natürlich unschön und ärgerlich! Es zeigt doch ziemlich deutlich, das Windows (NTFS) noch nicht wirklich als Server-Betriebssystem für komplexe Verzeichnisstrukturen geeignet ist. Wobei dann meine Folgefrage ist: Läßt sich das Problem mit "Active Directory" lösen?
Gruß Martin
Hi all,
ich baue für einen Kunden eine komplexe Verzeichnisstruktur mit ca. 20.000 leeren Verzeichnissen auf. Der Grundgedanke der Rechtevergabe ist sehr einfach und entspricht der normalen Rechtesetzung von Linux Homedirectories mit einem geschützten Bereich und einem offenen Bereich:
\Verzeichnis_A\Verzeichnis_B\[Dateien]
- Auf Verzeichnis A hat eine definierte lokale Berechtigungsgruppe "L_Lesende" das Recht "eXecute"" und eine weitere Gruppe "L_Schreibende" das Recht "eXecute"" (Admins aussen vor gelassen)
- Auf Verzeichnis B hat die definierte lokale Berechtigungsgruppe "L_Lesende" das Recht "eXecute"" und eine weitere Gruppe "L_Schreibende" das Recht "Modify""
In einfachen Worten gesagt: "L_Schreibende" darf ab der Verzeichnisebene .\Verzeichnis_B Verzeichnisse und Dateien anlegen, bearbeiten und löschen, oberhalb davon nur lesen (bzw. ausführen)
Hier ein Prinzipbild mit 2 Strukturästen. Rot ist geschützt, Grün ist offen, Gestreift ist die kritische Verzeichnisebene:
Wichtige Ergänzung:
Schon im letzten Verzeichnis des geschlossenen Bereichs, also im Bild im Verzeichnis "Modul" muss es für "L_Schreibende" möglich sein, neue Unterverzeichnisse einzurichten. Das bedeutet, dass der "normale User" an dieser Stelle bereits mehr Rechte besitzt!
Einen anderen Weg gibt es nicht, denn, wenn man bereits Modul "grün" macht, dann kann jeder User dieses Teil wiederum löschen, was ausgeschlossen werden muss!
Verwaltet wird die Rechtesetzung unter Nutzung des im Resource Kit enthaltenen Tools "xcacls".
Die Schwierigkeit ist definitiv das Recht auf VerzeichnisB, denn die normale Vorgehensweise unter Windows, die für mein Projekt nicht nutzbar ist, wäre, einen Share anzulegen. Ich brauche aber eine normale Rechtesetzung.
Die Vorgehensweise zum Festlegen der korrekten Rechte wären mehrere Skripte, mit denen erst das Grundrecht auf die gesamte Struktur eingestellt wird und dann der geschützte Bereich "verschlossen" wird. Somit könnte im Endergebnis der angehängte Bereich beliebig wachsen, die Grundstruktur bliebe erhalten.
Wer Linux kennt, dem ist klar, dass dies exakt der Unix Home-Directory - Logik entspricht.
Restriktionen:
- kein Samba-Server möglich, es handelt sich um Windows Server mit NTFS, Umstellung auf Active Directory geplant für Ende 2005
- Verwendung von Skripten ist ein Muss, da sonst nie mehr die geschützte Ebene wieder hergestellt werden kann.
- Mittelfristiges Ziel = Einsatz Dokumentenverwaltungssystem, z.Z. jedoch noch nicht möglich!
Offenbar gibt es keine vernünftige Lösung unter Windows! Ich habe mich für folgenden Workaround entschieden:
Die Berechtigung wird via Skript so gesetzt:
<li> geschlossener Bereich (rot):
xcacls.vbs [DIR] /G "Domain Admins":F "[Server]\L_PRJ__Read":X "[Server]\L_PRJ__Change":X /server [Server]</li>
<li> offener Bereich (grün):
xcacls.vbs [DIR] /G "Domain Admins":F "[Server]\L_PRJ__Read":X "[Server]\L_PRJ__Change":M /server [Server]</li>
In Worten bedeutet das:
Die Verzeichnisse im grauen Bereich werden vom Administrator angelegt, erhalten aber das Recht Modify für Projektmitarbeiter. Damit können Unterverzeichnisse und Dateien erzeugt, bearbeitet und gelöscht werden. Löscht jemand ein Verzeichnis im grauen Bereich, dann ist es weg! Nur eine Administrator kann es dann wieder erzeugen.
Die Sache ist natürlich unschön und ärgerlich! Es zeigt doch ziemlich deutlich, das Windows (NTFS) noch nicht wirklich als Server-Betriebssystem für komplexe Verzeichnisstrukturen geeignet ist. Wobei dann meine Folgefrage ist: Läßt sich das Problem mit "Active Directory" lösen?
Gruß Martin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12567
Url: https://administrator.de/forum/hierachische-verzeichnisstruktur-mit-berechtigung-je-nach-ebene-x-oder-m-entspricht-linux-home-logik-12567.html
Ausgedruckt am: 23.12.2024 um 08:12 Uhr
11 Kommentare
Neuester Kommentar
Hallo!
In Anbetracht der Zeit empfehle ich, Dich mal mit der Blockieren-Funktion der Rechte-Vererbung zu beschäftigen. Auf dem Share würde ich nur READ geben, dann können alle lesen (was ja auch so sein soll). Über den Sicherheits-Reiter kannst Du dann die NTFS-Rechte vergeben und dort über "Erweitert" die Rechtevererbung abschalten.
Beachte: Die Rechte unter Windows sind kumulativ, d.h. READ auf dem Share und Schreibrecht weiter unten heisst Schreibrechte in dem betreffenden Ordner.
Es besteht auch die Möglichkeit ein spezielles Recht explizit zu Vergweigern, diese Verweigerung gilt dann vor allem!
Auf jeden fall solltest Du aufpassen, dass Du Dich beim Rechte setzen nicht verzettelst.
Ansonsten gerne morgen nochmal ne Antwort, wenn Du noch Fragen hast
Gruss
Udo
In Anbetracht der Zeit empfehle ich, Dich mal mit der Blockieren-Funktion der Rechte-Vererbung zu beschäftigen. Auf dem Share würde ich nur READ geben, dann können alle lesen (was ja auch so sein soll). Über den Sicherheits-Reiter kannst Du dann die NTFS-Rechte vergeben und dort über "Erweitert" die Rechtevererbung abschalten.
Beachte: Die Rechte unter Windows sind kumulativ, d.h. READ auf dem Share und Schreibrecht weiter unten heisst Schreibrechte in dem betreffenden Ordner.
Es besteht auch die Möglichkeit ein spezielles Recht explizit zu Vergweigern, diese Verweigerung gilt dann vor allem!
Auf jeden fall solltest Du aufpassen, dass Du Dich beim Rechte setzen nicht verzettelst.
Ansonsten gerne morgen nochmal ne Antwort, wenn Du noch Fragen hast
Gruss
Udo
Werde ich testen! Allerdings ist mir noch
nicht ganz klar geworden, wozu ich die
Verweigerung überhaupt brauche. Mir
kommt das irgendwie komisch vor, denn, wenn
ich die Berechtigung sauber
"positiv" vergebe, dann frage ich
mich, wozu ich dann noch eine Verweigerung
brauche.
nicht ganz klar geworden, wozu ich die
Verweigerung überhaupt brauche. Mir
kommt das irgendwie komisch vor, denn, wenn
ich die Berechtigung sauber
"positiv" vergebe, dann frage ich
mich, wozu ich dann noch eine Verweigerung
brauche.
Das ist dann erforderlich, wenn für einen User, der z.B. in zwei Gruppen ist, an einer Stelle nicht diese Berechtigung haben darf, die die Gruppe im Normalfall hat (gleiches gilt auch für Gruppen). Ist etwas verworren, zugegeben, und im "normalen" Leben würde man es auch nicht so machen, aber MS bietet eben die Möglichkeit.
Ein normal ausgebildeter
Windows-Admin müsste mir hier doch eine
Lösung bauen können oder zumindest
sagen können, ob es geht oder nicht.
Windows-Admin müsste mir hier doch eine
Lösung bauen können oder zumindest
sagen können, ob es geht oder nicht.
Das ist korrekt Wobei bzgl. der Rechtevergabe es nicht immer gleich einfach ist. Falls Du also einen zur Hand hast, dann lass das ihn erledigen.
Zu Deiner Grafik:
Die "Module" sind geshared, oder? Dann würde ich dort READ setzen und darunter für die entsprechenden Gruppen das "Ändern" setzen, somit können die User auch Dateien löschen in dem Verzeichnis bzw. Unterordner anlegen und diese wieder löschen.
Gruss
Udo
Der Schlüssel zur Verschlüsselung wird generiert, sobald Du das erste Mal etwas verschlüsselt. Du kannst Ihn über den IE, Sicherheit auslesen, dort wo auch die anderen Zertifikate (Verisign etc.) sind.
Diese Schlüssel solltest Du aber exportieren, da bei einem Crash etc. Du die Dateien nur wiederherstellen kannst, wenn Du den Key dazu hast.
Diese Schlüssel solltest Du aber exportieren, da bei einem Crash etc. Du die Dateien nur wiederherstellen kannst, wenn Du den Key dazu hast.