11
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12567
Url: https://administrator.de/contentid/12567
Ausgedruckt am: 23.11.2024 um 01:11 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
Hallo Udo,
Da bin ich im Moment überfragt, was überhaupt eingestellt ist. Ich arbeite ja auf einer existiernden Verzeichnisstruktur. Ich kann mir aber im Moment nicht vorstellen, was sonst eingestellt sein sollte, denn ich kann die Rechte ja weiter hinten sowohl völlig einschränken als auch völlig aufmachen.
Das ist klar! Ich arbeite aber normalerweise gar nicht mit diesem Tool sondern verwende gleich xcacls.
Beachte: Die Rechte unter Windows sind
kumulativ, d.h. READ auf dem Share und
Schreibrecht weiter unten heisst
Schreibrechte in dem betreffenden Ordner.
Hmmh, danke für die Klarstellung!
Es besteht auch die Möglichkeit ein
spezielles Recht explizit zu Vergweigern,
diese Verweigerung gilt dann vor allem!
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.
Auf jeden fall solltest Du aufpassen, dass
Du Dich beim Rechte setzen nicht
verzettelst.
Korrekt! Insbesondere kann die Dauer der Setzung bei der Länge des Pfades ganz schön lange dauern!
Ansonsten gerne morgen nochmal ne Antwort,
wenn Du noch Fragen hast
Na ja, was ich mich eigentlich frage, ist ob denn noch nie jemand auf den Gedanken gekommen ist, so etwas Naheliegendes umzusetzen!
Ich bin hier Projektleiter für dieses recht umfangreiche Migrationsprojekt und möchte mich gar nicht mit der Rechtevergabe beschäftigen. 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.
Gruß Martin
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).
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).
Da bin ich im Moment überfragt, was überhaupt eingestellt ist. Ich arbeite ja auf einer existiernden Verzeichnisstruktur. Ich kann mir aber im Moment nicht vorstellen, was sonst eingestellt sein sollte, denn ich kann die Rechte ja weiter hinten sowohl völlig einschränken als auch völlig aufmachen.
Über den Sicherheits-Reiter
kannst Du dann die NTFS-Rechte vergeben und
dort über "Erweitert" die
Rechtevererbung abschalten.
kannst Du dann die NTFS-Rechte vergeben und
dort über "Erweitert" die
Rechtevererbung abschalten.
Das ist klar! Ich arbeite aber normalerweise gar nicht mit diesem Tool sondern verwende gleich xcacls.
Beachte: Die Rechte unter Windows sind
kumulativ, d.h. READ auf dem Share und
Schreibrecht weiter unten heisst
Schreibrechte in dem betreffenden Ordner.
Hmmh, danke für die Klarstellung!
Es besteht auch die Möglichkeit ein
spezielles Recht explizit zu Vergweigern,
diese Verweigerung gilt dann vor allem!
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.
Auf jeden fall solltest Du aufpassen, dass
Du Dich beim Rechte setzen nicht
verzettelst.
Korrekt! Insbesondere kann die Dauer der Setzung bei der Länge des Pfades ganz schön lange dauern!
Ansonsten gerne morgen nochmal ne Antwort,
wenn Du noch Fragen hast
Na ja, was ich mich eigentlich frage, ist ob denn noch nie jemand auf den Gedanken gekommen ist, so etwas Naheliegendes umzusetzen!
Ich bin hier Projektleiter für dieses recht umfangreiche Migrationsprojekt und möchte mich gar nicht mit der Rechtevergabe beschäftigen. 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.Gruß Martin
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
Hallo Udo,
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.
Leider ist es nicht wirklich so einfach!
1. Geshared ist ein Verzeichnis viel weiter vorne im Ast bzw. an der Wurzel.
2. Richtig kritisch ist das Verzeichnis "Modul". Da gibt es zwei Möglichkeiten:
a. Direkt ACL, so dass im Verzeichnis Modul
a1. folgendes erlaubt ist:
- Neues Verzeichnis aufmachen und ändern
- Neue Datei aufmachen und ändern
a2. folgendes untersagt ist:
Das führende Verzeichnis "Modul" zu ändern oder löschen.
b. ACL, so dass
b1. folgendes erlaubt ist:
- Neues Verzeichnis aufmachen und ändern
- Unterhalb neuer Verzeichnisse Dateien aufmachen und ändern
b2. folgendes untersagt ist:
- Das führende Verzeichnis "Modul" zu ändern oder löschen.
- Im Verzeichnis Modul neue Datei aufmachen und ändern
Ich kann durchaus mit Lösung b. leben, auch wenn das nicht ideal ist. Die Sache hört sich völlig trivial an, ist es aber nicht! Z.B. ist zu berücksichtigen, dass Office eine Datei in einem Verzeichnis öffnet und sofort im selben Verzeichnis eine Kopie anleget, also schreibt.
Gruß Martin
PS: Kennst Du Linux? Da wäre sowas trivial weil völlig normal!
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.
Leider ist es nicht wirklich so einfach!
1. Geshared ist ein Verzeichnis viel weiter vorne im Ast bzw. an der Wurzel.
2. Richtig kritisch ist das Verzeichnis "Modul". Da gibt es zwei Möglichkeiten:
a. Direkt ACL, so dass im Verzeichnis Modul
a1. folgendes erlaubt ist:
- Neues Verzeichnis aufmachen und ändern
- Neue Datei aufmachen und ändern
a2. folgendes untersagt ist:
Das führende Verzeichnis "Modul" zu ändern oder löschen.
b. ACL, so dass
b1. folgendes erlaubt ist:
- Neues Verzeichnis aufmachen und ändern
- Unterhalb neuer Verzeichnisse Dateien aufmachen und ändern
b2. folgendes untersagt ist:
- Das führende Verzeichnis "Modul" zu ändern oder löschen.
- Im Verzeichnis Modul neue Datei aufmachen und ändern
Ich kann durchaus mit Lösung b. leben, auch wenn das nicht ideal ist. Die Sache hört sich völlig trivial an, ist es aber nicht! Z.B. ist zu berücksichtigen, dass Office eine Datei in einem Verzeichnis öffnet und sofort im selben Verzeichnis eine Kopie anleget, also schreibt.
Gruß Martin
PS: Kennst Du Linux? Da wäre sowas trivial weil völlig normal!
Windows kommt vom Desktop und leider nicht von der Netzwerkseite, darum werden wir uns hier wohl noch einige Zeit mit rumschlagen.
Linux kenne ich leider nicht so gut, aber ich weiss, das vieles einfacher ist, genauso wie es mit Netware ist
Linux kenne ich leider nicht so gut, aber ich weiss, das vieles einfacher ist, genauso wie es mit Netware ist
Windows kommt vom Desktop und leider nicht
von der Netzwerkseite, darum werden wir uns
hier wohl noch einige Zeit mit rumschlagen.
Linux kenne ich leider nicht so gut, aber
ich weiss, das vieles einfacher ist, genauso
wie es mit Netware ist
von der Netzwerkseite, darum werden wir uns
hier wohl noch einige Zeit mit rumschlagen.
Linux kenne ich leider nicht so gut, aber
ich weiss, das vieles einfacher ist, genauso
wie es mit Netware ist
Oh!
Bitte keine "politische Diskussion" an dieser Stelle! Es wäre ja nett aber es hilft mir gar nicht weiter! Die Linux-Sache habe ich eigentlich
nur erwähnt, weil sie jedem Linuxaner ziemlich klar sagt, was ich hier eigentlich haben will.Wobei im Grunde es inzwischen auch unter Windows ein "home-Directory" gibt und da die Mimik dieselbe sein sollte!
Gruß Martin
Auf der Suche nach einem Workaround sind mir folgende Optionen eingefallen:
1. Verzeichnis mit dem Attribut "schreibgeschützt" versehen und normalen Usern das Recht zum Schreiben von Attributen entziehen.
Ergebnis: Es scheint nur so, wie wenn das Verzeichnis schreibgeschützt wird, in Wirklichkeit passiert gar nichts, d.h., das Verzeichnis kann problemlos wieder gelöscht werden. Hmmpf!
2. Verzeichnis verschlüsseln. Ja, sowas gibt es inzwischen auch! Was das allerdings bewirkt, weiss ich nicht, da die Verschlüsselung nicht möglich ist, weil auf dem Rechner gar kein Schlüssel existiert. Nun ja, Verschlüsselung ist ja nicht gerade das, was ich will aber mir ist schon fast jeder Weg Recht, um zum Ziel zu kommen und irgendwie kann man nie wissen, was der allseits bekannte Hersteller da wirklich vor hatte...
Gruß Martin
1. Verzeichnis mit dem Attribut "schreibgeschützt" versehen und normalen Usern das Recht zum Schreiben von Attributen entziehen.
Ergebnis: Es scheint nur so, wie wenn das Verzeichnis schreibgeschützt wird, in Wirklichkeit passiert gar nichts, d.h., das Verzeichnis kann problemlos wieder gelöscht werden. Hmmpf!
2. Verzeichnis verschlüsseln. Ja, sowas gibt es inzwischen auch! Was das allerdings bewirkt, weiss ich nicht, da die Verschlüsselung nicht möglich ist, weil auf dem Rechner gar kein Schlüssel existiert. Nun ja, Verschlüsselung ist ja nicht gerade das, was ich will aber mir ist schon fast jeder Weg Recht, um zum Ziel zu kommen und irgendwie kann man nie wissen, was der allseits bekannte Hersteller da wirklich vor hatte...
Gruß Martin
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.
Danke! Wobei natürlich immer noch die Frage ist, ob mir das Verfahren in irgend einer Form weiter hilft - eher nicht, wie es scheint! Martin
Martin
Wie war das? Es hat keiner gesagt, dass es einfach ist??
Schwierig ist bei MS vor allem, dass man herumeiern muss, weil die Dinge nicht wirklich sauber dokumentiert sind oder gar unlogisch - zumindest empfinde ich es teilweise so!
Martin
Martin
