NTFS: Lokale Gruppen Benutzer, Administratoren und UAC

Lese- oder Schreibrechte auf File Servern, die Benutzer über Berechtigungsgruppen erhalten, wirken manchmal nicht:
– Benutzer ohne „Lese“-Berechtigungen können Verzeichnisse sehen.
– Benutzer ohne „Schreib“-Berechtigungen können Verzeichnisse erstellen.

Ich möchte in diesem Artikel näher auf Probleme mit den lokalen Gruppen „Benutzer“ und „Administratoren“ sowie deren Verbindung zu UAC eingehen und Lösungsmöglichkeiten aufzeigen.

 
In den vergangen Wochen habe ich immer wieder Diskussionen über die lokale Gruppe „Benutzer“ und „Administratoren“ im Zusammenhang mit UAC (User Account Control) und NFTS Berechtigungen unter Windows Server 2008R2 und Windows Server 2012R2 geführt. Die Sache erscheint zunächst glasklar und wirft dennoch Fragen auf.

Theorie – Berechtigungsvergabe für File Server

Die Berechtigungsvergabe für File Server erfolgt über den kleinsten gemeinsamen Nenner zwischen:

• den Share Berechtigungen und
• den NTFS Berechtigungen

Vergibt man für eine Gruppe lediglich „Lese“-Berechtigungen auf der Freigabe, so wird der Zugriff auf maximal „Lesen“ eingeschränkt. Dies geschieht unabhängig davon ob im NTFS vielleicht höhere Berechtigungen vergeben wurden.

In der Praxis werden meist „Ändern“ Berechtigungen auf der Freigabe vergeben und die NTFS Rechte steuern dann ob „Ändern“ oder „Lesen“ erlaubt wird.
 

Praxis – Berechtigung Share und File System

Zur Verdeutlichung des Problems der Berechtigungsvergabe für lokale Gruppen ein kleines Beispiel:

1. Wir erstellen eine Freigabe für den Ordner „D:\Daten“ mit dem Namen „Daten“.
2. Wir erstellen eine Berechtigungsgruppe in der Active Directory Domäne „RF-Daten-R“
3. Wir vergeben der Gruppe „Lese“-Berechtigungen auf den Ordner „D:\Daten“
4. Wir vergeben der Freigabe „Ändern“-Berechtigungen
5. Wir erstellen ggfs. weitere Unterverzeichnisse und Berechtigungsgruppen.

ABE (Access Based Enumeration) ist für das Share aktiviert. Ein Benutzerkonto wird Mitglied in diversen Gruppen, auch in „RF-Daten-R“.
 

Wir erwarten, dass:

• mit ABE nur die Verzeichnisse anzeigten werden,
  welche aufgrund der Mitgliedschaft in Berechtigungsgruppen für den Benutzer erlaubt sind
• der Benutzer „Lese“-Berechtigung in den Ordern hat,
  bei denen er „Lese“-Berechtigungen über eine Gruppenmitgliedschaft bekommen hat (also diese auch wirken).

Wir stellen fest, dass

• der Benutzer alle Verzeichnisse sehen kann,
  auch Verzeichnisse für die er eigentlich keine Berechtigungen hat und daher mittels ABE ausgeblendet sein sollten
• der Benutzer in Verzeichnissen dennoch Dateien und Order anlegen kann,
  obwohl er in diesen durch die Gruppenmitgliedschaften nur „Lese“-Berechtigungen haben.
   

Erläuterung des Berechtigungskonflikts

Ein Blick in die NTFS Berechtigungen verrät warum es anders gekommen ist.
Standardmäßig ist die lokale Gruppe „Benutzer“ (Users) auf jedem NTFS Volume berechtigt.
Zum einen mit „Read & execute“ und zum anderen mit speziellen Berechtigungen „Create files / write data„.

Der erste Gedanke ist vielleicht:
„Der Benutzer ist ja nicht Mitglied der lokalen Gruppe des File Servers“ – Doch leider stimmt dies nicht.
Ein Blick in die MSDN Library zu lokalen Standardgruppen erklärt den Grund:
 

Lokale Gruppe Benutzer:
„Die Gruppen Domänenbenutzer, Authentifizierte Benutzer und Interaktiv sind standardmäßig Mitglieder dieser Gruppe. Daher wird jedes in der Domäne erstellte Benutzerkonto zu einem Mitglied dieser Gruppe.“
 

Lösung für die lokale Gruppe Benutzer

Die Lösung ist denkbar einfach. Wir entfernen die Berechtigung der lokalen Gruppe „Benutzer“ auf dem obersten Level eines neuen NTFS Volumes, bevor wir mit der Einrichtung der Verzeichnisse und Freigaben beginnen.
Leider bringt diese Lösung einen neue Komponente mit in Spiel: UAC.
 

UAC – User Access Control

Nachdem wir die lokale Gruppe „Benutzer“ aus den NTFS ACLs entfernt haben und uns evtl. neu per RDP an unserem neuen File Server angemeldet haben, stellen wir fest, dass wir keinen Zugriff mehr auf die Verzeichnisse haben. Wir kontrollieren die Mitgliedschaft in den lokalen Administratoren und wundern uns…

SID der lokalen Gruppe Administratoren fehlt

Der Hintergund dieses Problems ist, dass UAC bei der Anmeldung per RDP die SID der lokalen Gruppe der Administratoren aus dem Access Token entfernt. Somit ist man faktisch kein Administrator mehr. Bei vielen administrativen Programmen kommt automatisch eine Abfrage, ob man das Programm mit erhöhten Rechten ausführen möchte, oder man startet es direkt per Rechtsklick mit „Als Administrator ausführen„. Der Windows Explorer wird immer im Kontext des angemeldeten Benutzers ausgeführt, ein „Run-As“ gibt es hier nicht.

Somit lässt sich das zunächst seltsam anmutende Verhalten erklären:

• kein lokaler Administrator dank UAC
• keine NTFS Berechtigung für die lokale Gruppe Benutzer (wurde zuvor entfernt)
• ergibt: keinen Zugriff auf die Verzeichnisse des NTFS Volumes
   

Lösung 1 – Administrative Domänengruppe

Auch für die UAC gibt es eine einfache Lösung. Es empfiehlt sich die Definition einer administrativen Domänengruppe, welche zur Administration der File Services delegiert wird. Diese File-Admin Gruppe wird Mitglied der Gruppe der lokalen Administratoren und bekommt „Vollzugriff“ auf das NTFS Volume. Zusätzlich erteilen wir dieser Gruppe „Vollzugriff“-Berechtigungen auf dem Share, damit die NTFS Berechtigungen auch über das Netzwerk verwaltet werden können.
 

Lösung 2 – UAC deaktivieren

Eine etwas radikalere Art mit der UAC Problematik umzugehen, ist UAC einfach per Regitry zu deaktivieren. Dies will ich hier nicht empfehlen, dennoch zur Vollständigkeit aber erwähnen:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
UAC aktivieren: EnableLUA = 0x00000001
UAC deaktivieren: EnableLUA = 0x00000000

Mit Lösung 1 oder 2 sollten die Berechtigungen für die lokale Gruppe Benutzer auf NTFS dann korrekt funktionieren.