Vererbung - Was sie unbedingt verstehen müssen

Wenn Sie schon die Seite Adminkonzept gelesen haben, dann wissen Sie, wie wichtig Berechtigungen in einer SystemUmgebung sind. Zwar haben die Mitglieder der Gruppe "Domänen Administratoren" sehr weit reichende Berechtigungen, wenn auch nicht alle, aber wer will schon die ganze Zeit als Administrator angemeldet sein. Die Aufgabenstellung ist aber etwas umfangreicher:

  • Administrative Berechtigungen
    Berechtigungen sind zum einen nützlich um administrative Tätigkeiten auf weniger privilegierte Gruppen und Personen zu delegieren.
  • Datenberechtigungen
    Der zweite Einsatzzweck ist die Steuerung von Berechtigungen für Anwender z.B. für Dateisysteme auf Dateiservern.

Die meisten Administratoren vergeben dabei häufig Berechtigungen ohne genauer über die Hintergründe Bescheid zu wissen und die Feinheiten zu beachten.

SACL, DACL, ACE - war ist das ?

Windows speichert zu fast jeden Objekt auch entsprechende Berechtigungen ab und da gibt es weit mehr als nur eine Sache, die berechtigt werden kann. Daher die wichtigsten Begriffe

  • SID = Security Identifier
    Jedes Objekt, welches zur Vergabe von Berechtigungen genutzt wird, hat eine eindeutige Nummer. Es gibt einige vordefinierte Nummern wie S-1-5-18, S-1-5-19 etc. SIDs von Benutzern und Gruppen sehen etwas wie S-1-5-21-11949459-30317519-74842111-500 aus. Ist der letzte Abschnitt eine 500, dann ist es der Administrator. Benutzer beginnen dann bei 1000.
  • SACL = system access control list
    Einstellungen die z.B. das Auditing steuern, d.h. wie welche Zugriffe auf das Objekt im Sicherheitseventlog protokolliert werden.
  • DACL = discretionary access control list
    Liste mit den SIDs die auf das Objekt berechtigt sind (Allow aber auch DENY)

Jedes Objekt hat zusätzlich noch einen Owner, der immer die Rechte ändern kann, selbst wenn er selbst keine sonstigen Berechtigungen hat.

Vererbung und "Scope"

Nun wäre es ja zu einfach, wenn Sie an einem Objekt einfach die SID samt gewünschten Berechtigungen in die DACL hinzufügen und schon hat der Benutzer den gewünschten Zugriff. Aber da kommt die Vererbung mit ins Spiel. Es wäre doch sehr unbequem, wenn Sie auf jedem Objekt, d.h. jedem Ordner,  jedem Unterordner und jeder Datei darin die Berechtigungen immer wieder neu setzen müssten.

Daher kennt Windows die Funktion der "Vererbung" und dazu die Möglichkeit eben diese auch wieder zu blockieren. Was viele nicht wissen ist, dass der Begriff "zweimal" angewendet werden kann.

  • Vererbung beim Objekt
    Über die Checkbox in den erweiterten Sicherheitseinstellungen können Sie steuern, ob die Berechtigungen vom übergeordneten Objekt auf dieses Objekt übernommen werden. Dies ist quasi eine harte Methode ab einer bestimmten Stelle mit neuen Berechtigungen anzufangen.

Diese Option ist meistens eingeschaltet und meine Empfehlung lautet auch, diese nicht abzuschalten, da Programme sehr oft auf der Wurzel z.B.: Rechte addieren und diese dann darunter nicht mehr greifen würden. Das ist z.B.: bei der Exchange Konfiguration der Fall.

  • Vererbung bei der Berechtigung
    Die zweite Steuerung ist vielen nicht bekannt, da Sie erst hinter den erweiterten Einstellungen zu finden ist. Ich kann einem Benutzer nicht nur mal so ein paar Berechtigungen geben, sondern auch bestimmen, auf welche Objekte und Unterobjekte diese angewendet werden.

    Ist ist sehr wichtig für die folgenden Beispiele, weil Sie damit ein leistungsfähiges Instrument um Berechtigungen auf untergeordneten Objekten abweichend zu setzen ohne die Vererbung auf dem Objekt selbst global abschalten zu müssen und sie ebenfalls auf den Einsatz von DENY verzichten können.

Praktische Regeln für Berechtigungen

Aus meiner Sicht sollten Sie folgende drei Grundregeln können:

  • Vererbung nicht abschalten
    Wenn die Vererbung auf Unterobjekte aktiv ist, dann sollten Sie diese nur in Ausnahmefällen abschalten. Denn oft werden bei einem Update oder Änderungen der Installation die Berechtigungen auf höherer Stufe geändert und werden dann in diesem Zweig nicht mehr mit aktualisiert. Das ist bei Exchange besonders kritisch, wenn Sie z.B. einen neuen Server installieren. Auch dieses Computerkonto bekommt "Rechte". Eine deaktivierte Vererbung kann hier zu extremen Störungen führen, die sehr schwer zu entdecken sind.
  • Vorsicht mit DENY
    Ein DENY gewinnt fast immer über ALLOW und kann daher auch dem  Administrator oder Dienstkonten die Arbeit verhindern. Sogar eine Backupsoftware, Quota-Software, Virenscanner etc. können davon betroffen sein. Daher ist es immer besser ein Recht erst gar nicht zu geben, anstatt es danach wieder zu entziehen.
    Das ist besonders tückisch, da sie mit einem expliziten ALLOW ein DENY auf dem jeweiligen Objekt aufheben können, aber auf Unterobjekte n das vererbte DENY wieder über das vererbte ALLOW gewinnt.
  • Sinnvoller Einsatz von Scope
    Bei der Vergabe von Berechtigungen können Sie über Scope einstellen, ob diese vererbt werden dürfen oder nicht. Das ist allemal besser als die Vererbung auf Objekten selbst zu deaktivieren oder mit DENY ein Recht zu entziehen.

Change Management
Auch wenn es aufwändig ist, sollten sie jede Veränderung von Berechtigungen genau mit Datum und Zeit dokumentieren. Sie erleichtern sich später die Fehlersuche, Kontrolle und Anpassungen.

Probleme/Bug in der Vererbung

Bei der Vererbung müssen Sie unterscheiden, ob die Vererbung durch das Betriebssystem errechnet bzw. gesetzt wird oder eine Anwendungssoftware rekursiv durch die Unterobjekte läuft und die ACLs setzt. Ich habe keine genaueren Details aber glaube folgendes feststellen zu können.

  • NTFS-Dateisystem
    Wird ein Recht vergeben, dann wird es auf dieses Objekt geschrieben. Der Explorer, d.h. nicht das NTFS-Subsystem. sorgt dann für die Eintragung der Berechtigungen auf Unterobjekte n, solange dort die Vererbung aktiv ist, was bei vielen Daten natürlich lange dauern kann ein bei einem "Absturz" des Explorers oder fremder Bearbeitung zu Inkonsistenzen führt.
  • Active Directory (und damit auch Exchange Konfiguration)
    Diese Einstellungen "scheinen" errechnet zu werden. Zumindest werden Änderungen auch auf Unterobjekte angewendet, egal ob man den Exchange System Manager, ADSIEDIT oder andere Tools einsetzt.
  • Novell NDS
    Berechtigungen werden nur an dem jeweiligen Objekt gesetzt und die untergeordneten Berechtigungen werden dynamisch vom Betriebssystem ermittelt, wenn ein Zugriff erfolgt.
  • Novell NetWare Dateisystem ( nicht Unix !)
    Berechtigungen werden nur an dem jeweiligen Ordner oder Datei gesetzt. Der Server "errechnet" dann die erforderlichen Berechtigungen
  • Unix Dateisystem
    Jede Datei und jedes Verzeichnis hat seine Berechtigungen. Ein CHMOD setzt die Berechtigungen auf dem Objekt. Unterobjekte sind rekursiv durch den Ausführenden zu setzen.

Diese Details sind wichtig, wenn bei der Veränderung der Berechtigungen etwas "schief" geht. Wenn eine Software selbst rekursiv durch den Baum laufen und Rechte anpassen muss, dann kann dabei ja z.B.: die Netwerkverbindung abbrechen. Das Ergebnis ist dann eine "teilweise" Vererbung, die fast nicht mehr zu finden ist. (Frage Transaktionsorientierung)

Weiterhin kann es ja sein, dass Sie über andere Wege Berechtigungen ändern. So können Sie zwar mit dem Windows Explorer die Berechtigungen ändern, die dieser auch schön brav auf alle unterordner verschiebt, aber Sie können ja auch per CACLS, XCACLS die Rechte verändern. Und diese Programme "kennen" nicht unbedingt die Art der Vererbung. So könnten Sie quasi ein "Recht" setzen oder entfernen ohne dass die unterordner entsprechend der Vererbung bearbeitet werden.

Dass dem So ist, kann ich auf meinem eigenen Notebook nachweisen. Auf einem unterordner ist mein Name als "vererbt" eingetragen (und kann daher nicht gelöscht werden) obwohl im Ordner darüber keine Berechtigung mehr enthalten ist.

Hier sehen Sie die Berechtigungen auf "C:\TEMP" und die Berechtigungen auf C:\

Auf C:\TEMP hat mein Benutzer Vollzugriff aber nur auf diesen Ordner, was aber einem nicht näher bezeichneten "übergeordneten Objekt" vererbt wird. Schaut man sich dann aber C:\ als die nächst höhere Struktur an, dann ist da das Konto "Carius, Frank" gar nicht mehr zu sehen.

NTFS Berechtigungen und Mountpoints

Windows kann Partitionen problemlos als Verzeichnis in anderen Dateisystemen einbinden. So genannte Mountpoints erlauben es, die Grenzen der Buchstaben von A: bis Z: zu überspringen. Dabei wird aber gerne übersehen, dass dies auch Auswirklungen auf Berechtigungen hat. Ein MountPoint besteht aus einem Verzeichnis, welches natürlich eine ACL hat. Aber andererseits verweist dieses Verzeichnis auch auf ein Volume, welches ebenfalls Berechtigungen hat. Dies kann man im Explorer gut sehen, da Mountpoints eine weite Eigenschaftskarte aufweisen:

Man kann erkennen, dass das Verzeichnis "Backup" in der Baumstruktur ein Mountpoint darstellt. Schaut man sich die Eigenschaften an, bekommt man aber die Berechtigungen des Verzeichnisses, was aber nicht als Basis für die weiteren Verzeichnisse und Dateien auf dem Backup-Volume dienst. Auf der Karteikarte "Allgemein" ist aber ein neuer Button verfügbar der dann direkt zu den Berechtigungen des eingebundenen Dateisystems führt. Die dort vergebenen Berechtigungen werden für die weitere Vererbung genutzt.

Weitere Links