NTFS mit Windows

Jedes Objekt im Dateisystem hat eine Liste von Zugriffsrechten ACL genannt (Access Control List) Das ist seit OS/2 so und auch bei Windows NT 3.51 4.0 und auch 2000 GENAu SO.

Der Vorteil davon. Das Betriebssystem kann im Moment des Zugriffs schnell heraus finden, wer Rechte hat, und wer nicht. Andere Systeme (z.B. NetWare) errechnen das effektive Recht beim Zugriff (Dauert länger beim Zugriff). Damit man verstehen kann, wie Windows 2000 die "Vererbung" macht muss man vergleichen, wie es bisher gewesen ist. In der PräWIN2K Zeit haben wir Rechte "gesetzt". Wenn ich in einem Verzeichnis jemand hinzugefügt habe, dann hat der Explorer die ACL dieses Verzeichnis gesetzt. In der gleichen Dialogbox war in der Regel auch noch das Kreuz bei "Rechte für Dateien ersetzen" angewählt, so dass diese Aktion auf bei allen Dateien "in diesem Verzeichnis" (nicht darunter !!) entsprechend "überschrieben worden sind. Hat man noch das Kreuz bei "unterverzeichnisse" gemacht, dann wurden auch ACL's auf allen Dateien und Verzeichnissen darunter angewendet. 

Der Fachmann erkennt die Probleme:

  • Bestehende ACL's wurden einfach "überschrieben". also platt gemacht (Schade)
  • Man kann im Nachhinein fast nicht mehr herausfinden, wo man wann welche Rechte gegeben hat
  • Der Explorer muss bei RechteÄnderungen alle ACL's in unterverzeichnissen ändern, d.h. mehr Zeitbedarf beim administrieren, dafür schnell beim Zugriff.

Vererbung ? Fehlanzeige, wenn man von Vererbung im Sinne von NetWare denkt. Es ist eher ein "manuelles Vererben" durch den Explorer, indem er die Rechte überall setzt, wenn die entsprechenden Checkboxen gesetzt sind.

Wie hat man in dieser Situation Rechte "hinzugefügt" ??. Einfach mit CACLS.EXE (ist auf jedem System drauf !!!). Das Problem der "Rechte überschreiben" ist also eher ein Anwendungsproblem des Explorers und nicht ein "Kernelproblem". Die fehlende Nachvollziehbarkeit ist aber tatsächlich ein Mangel im System. Hier hilft nur saubere Dokumentation (Siehe TIPP am Ende dieser Info)

und Windows 2000 ?

Da ist das genau das gleiche im Prinzip, ABER zwei Dinge haben sich geändert:

Im Dateisystem gibt es an jedem Recht nun ein Bit "inherited", damit der Explorer sehen kann, ob die Rechte beim letzten Anwenden "von Oben" übernommen worden sind. (Wohlgemerkt, sie stehen IMMER noch als ACL an jedem Objekt !!)

Der Explorer bietet nicht mehr die zwei Checkboxen für Dateien und Verzeichnisse, sondern richtet sich nach der Checkbox "vererben" die nun Je Verzeichnis und Datei vorhanden ist und arbeitet Additiv. Gebe ich mit dem Explorer als nun weiter Oben jemanden ein Recht, dann setzt der Explorer diese Recht auf diesem Verzeichnis. Dann rennt er jede Datei in diesem Verzeichnis durch, und wenn das das Bit "vererben" gesetzt ist, dann addiert er dort die Rechte, die im Verzeichnis stehen und zwar für die Elemente, die das Flag "inherited" selbst haben. Bestehende explizit gegebene Rechte bleiben bestehen. Der Explorer arbeitet also "modifizierend", nicht mehr überschreibend.

Das gleiche macht er für Verzeichnisse und das ganze rekursiv. Wenn man nun im Explorer so ein Verzeichnis anschaut, dann sieht man diese "vererbten" rechte eben "grau". Das sagt nicht mehr, als dass der Explorer damals beim Vergeben hier die ACLS von "oben" übernommen hat. Schaltet man nun die Vererbung hier ab, dann fragt er logischerweise, ob er die ACLs löschen soll oder "kopieren" (also innerhalb der ACL das Flag "inherited" löscht).

Für die Freunde von NetWare. Man kann dieses Kreuz "Vererbung" vielleicht mit einer IRM (inherited Rights Mask) vergleichen, wobei hier immer nur die Wahl zwischen alles und nichts besteht)

Migration:

Das ist das teuflische Thema überhaupt. Angenommen der NT4-Server ist altersschwach und ein neuer W2K Server kommt hinzu und die Daten werden per "Backup/Restore" übernommen. oder ein bestehender NT4 Server wird auf W2K umgestellt: Bei NT4 gab es diese Vererbung nicht. Infolge dessen muss dieses Flag "Vererbe" eben abgeschaltet werden und alle ACLs gesetzt werden, damit das Ergebnis 1:1 identisch ist. Und so passiert es auch.

Praktische Tipps:

Unter NT4 KEIN Explorer nutzen für Rechte, sondern CACLS Am besten einfach alle "Rechte" die vergeben werden, mit einem BATCH-File setzen, welches man weiterpflegt und bei Problemen einfach wieder startet. So hat man eine Dokumentation der gesetzten Rechte (Revision !!!) und nebenbei macht man Änderungen von Benutzer (Ja mit Vollzugriff kann ein User auch Rechte ändern!!!) damit problemlos rückgängig. Ist also so was wie ne "Policy" für NTFS-Rechte. Unter NT 2000, Explorer nutzbar, aber vielleicht auch besser nicht nutzen (mangelnde Dokumentation) 

So ein Batch hat den Vorteil, dass man bei der Umstellung auf einen neuen Server quasi die Vererbung überall aktiv machen kann und dann die Rechte einfach wieder "einsetzt"

Achtung: CACLS unter W2K beachtet NICHT die Vererbung, also diese Rechte dann mit dem Explorer vergeben (da dieser Rekursiv dann werkelt). die "Vererbung" ist also weiterhin kein Bestandteil des Filesystem oder Kernel sondern "nur" eine Leistung der Administrationsoberfläche "Explorer.exe". Sieht man auch daran, dass bei aktiver Vererbung und Nutzung von CACLS die Rechte NICHT auf entsprechende Dateien oder Ordner vererbt werden.

Wobei auch der Explorer nicht frei von Tadel ist. Wird z.B.: ein Verzeichnisbaum auf einer Partition verschoben, so ist das ja kein Kopieren. Ergo bleiben auch die Rechte beim Alten. Auch dann ist es Fakt, dass dass im Verzeichnis darüber andere Rechte eingestellt sein können und diese trotz aktivierter "Vererbung" doch nicht zum Zuge kommen.

Übernahme eines Servers ?

Tja am besten die Rechte ordentlich dokumentieren (DUMPACL von Somarsoft hilft) und dann den Verzeichnisbaum neu aufbauen (mit Vererbung), die Rechte dann setzen und Vererbung an den gewünschten Abzweigungen kappen.. Und dann die Dateien "reinkopieren" (damit sie die Rechte beim "Create" ererben und das Flag Vererbung auch aktiv ist. Und man dann richtig mit W2K arbeiten kann.

Tipp am Rande. Wer einen W2K-Server hat und darauf 100.000 Dateien und "Vererbung aktiv" und stellt nun ein, dass auf dem Root der Platte der Dienstkonto "Virusscan" Vollzugriff gibt, kann durchaus einige Minuten "lahm gelegt" sein. Der Explorer fasst jede Datei an und das Fenster ist "nicht modal", d.h. man kann nicht mal ein weiteres Fenster des Explorers aufmachen... Geduld haben. Ansonsten: Verzeichnisbaum anlegen und "üben, üben, üben" ehe man es live macht. Und wichtige Verzeichnisse (z.B. Personalrat etc.) über einen Skript eben überwachen lassen (z.B. ein Batch, der mit CACLS als Administrator die Rechte ausliest und mit einem Sollwert vergleicht.

CACLS, XCACLS und DCACLS

Ich habe schon zwei Programme von Microsoft genannt, welche Bestandteil von Windows bzw. des Ressource Kits sind. CACLS und XCACLS.

Aber es gibt noch ein weiteres Produkt, welches von Daniel Nast (www.nastyboy.ch) entwickelt wurde, und ebenfalls ACLS per Kommandozeile setzt. Daniel hat sich auch geärgert:

"Mit CACLS, XCACLS oder SuBINACL wurde die automatische Vererbung immer weggefegt, wenn ich einen remove eines Benutzerrechtes machte. Aber bei einer bestimmten Größe der Ablage (ich sage mal größeren Firmen Context) macht man ja nichts mehr über Explorer."

Wünsche für die Zukunft

Ein Programm für W2K, das die Verzeichnisse und Dateien durchsucht und quasi nur die "explizit" gesetzten Rechte heraus findet, d.h. ein Administrator, der sauber mit Vererbung arbeitet, kann so ein Reverse Engineering machen und dokumentieren. Ein Programm das alle Verzeichnisse und Dateien durchsucht und Dateien und Verzeichnisse, die die gleichen Rechte haben, wie das darüber liegende Verzeichnis, die Rechte löscht und die Vererbung einschaltet bzw. das Flag "inherited" bei jedem Recht in der ACL setzt. Damit nach einer Migration von NT4 auf 2000 diese auch nutzbar ist. (Bisher mach ich das mit DUMPACL in eine Textdatei und dann ....) W2K-Explorer.exe als Kommandozeile :-) Sprich ein "Vererbungstaugliches" CACLS.

Umgekehrt wäre ein Prüfprogramm nett, welches prüft, ob unterverzeichnisse auch tatsächlich die Rechte von oben erhalten haben, wenn das Bit "Vererben" gesetzt ist.

Nun die Verwirrung komplett ??

Nicht besprochen wurde nun:

  • NTFS-Rechte und SHARE-Rechte
  • Kombination von NTFS-Rechten per User, Gruppen
  • "Verweigernde" NTFS-Rechte als Blockierung

Gelöschte SIDs

Ein immer wieder gefragtes Thema ist die Thematik der SIDs, die in den ACLs auftauchen aber nicht mehr zugeordnet werden können. Das passiert immer wieder weil das Betriebssystem nicht nachverfolgt, welche SID an welcher Stelle verwendet wird. Wird daher ein Benutzer oder eine Gruppe gelöscht, dann geistern die alten Einträge bis zum Ende des Servers in den ACLs herum. für einige Dinge habe ich Abhilfen gefunden:

Bei all dem darf man aber eins nicht vergessen:

Es gibt keinen sicheren Weg zu erkennen, ob eine SID wirklich nicht mehr benutzt wird. Temporäre Probleme bei Namensauflösungen, Trusts o.ä. können ein Programm irrtümlich dazu bringen, eine SID als "gelöscht" zu erkennen und zu entfernen. Daher mein Rat: Lassen Sie die SIDs in Ruhe. Vergeben Sie von Anfang an nie Rechte an Benutzer sondern immer nur über Gruppen. Diese sind sehr viel beständiger.

Weitere Links