16
NTFS Berechtigungen bei Freigaben
Hallo zusammen,
auf einem Server 2022 liegt auf D:\Datenbank eine Software (EXE Datei), die über das LAN ausgeführt werden soll.
Ausführen der EXE sollen aber nur bestimmte User können. Deshalb wurde im AD eine Gruppe grp_DBuser angelegt und dieser Gruppe das Recht lesen & ausführen auf dem Ordner gegeben.
Per (Windows) default haben auf D:\ alle lokalen Benutzer das Recht "Lesen, ausführen" und dieses wird vererbt auf die Unterordner.
Bei einem Test zeigte sich, dass ein User über das LAN auf die Freigabe und die EXE zugreifen kann, obwohl dieser nicht in der Gruppe grp_DBuser ist.
Das liegt offenbar daran, dass in der Gruppe der lokalen Benutzer die "Domänenbenutzer" und "NT-Authorität\Authentifizierte Benutzer" sind.
Ich habe zunächst mal die Domänenbenutzer aus der Gruppe der lokalen Benutzer geworfen.
Anschließend die "Authentifizierte Benutzer". Jetzt läuft es so wie ich es mir wünsche:
Mitglieder aus grp_DBuser können per LAN auf das Share zugreifen.
User, die sich z.B. zur Wartung lokal an dem Server anmelden, können auf D: Zugreifen.
Wie wäre denn hier die saubere Lösung?
Vielen Dank!
auf einem Server 2022 liegt auf D:\Datenbank eine Software (EXE Datei), die über das LAN ausgeführt werden soll.
Ausführen der EXE sollen aber nur bestimmte User können. Deshalb wurde im AD eine Gruppe grp_DBuser angelegt und dieser Gruppe das Recht lesen & ausführen auf dem Ordner gegeben.
Per (Windows) default haben auf D:\ alle lokalen Benutzer das Recht "Lesen, ausführen" und dieses wird vererbt auf die Unterordner.
Bei einem Test zeigte sich, dass ein User über das LAN auf die Freigabe und die EXE zugreifen kann, obwohl dieser nicht in der Gruppe grp_DBuser ist.
Das liegt offenbar daran, dass in der Gruppe der lokalen Benutzer die "Domänenbenutzer" und "NT-Authorität\Authentifizierte Benutzer" sind.
Ich habe zunächst mal die Domänenbenutzer aus der Gruppe der lokalen Benutzer geworfen.
Anschließend die "Authentifizierte Benutzer". Jetzt läuft es so wie ich es mir wünsche:
Mitglieder aus grp_DBuser können per LAN auf das Share zugreifen.
User, die sich z.B. zur Wartung lokal an dem Server anmelden, können auf D: Zugreifen.
Wie wäre denn hier die saubere Lösung?
Vielen Dank!
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: 7905614190
Url: https://administrator.de/contentid/7905614190
Ausgedruckt am: 19.12.2024 um 14:12 Uhr
16 Kommentare
Neuester Kommentar
Man durchbricht die Vererbung und entfernt die genannten Grupen und fügt die gewollte Gruppe hinzu - sauberer wird's nicht.
1
Moin,
wenn ich Deine Beschreibung richtig verstanden habe, dann macht man das genau so.
Liebe Grüße
Erik
wenn ich Deine Beschreibung richtig verstanden habe, dann macht man das genau so.
Liebe Grüße
Erik
Aber er schreibt doch:
Ich habe zunächst mal die Domänenbenutzer aus der Gruppe der lokalen Benutzer geworfen.
Und DAS macht man lieber nicht.Zitat von @DerWoWusste:
Aber er schreibt doch:
Aber er schreibt doch:
Ich habe zunächst mal die Domänenbenutzer aus der Gruppe der lokalen Benutzer geworfen.
Und DAS macht man lieber nicht.Das stimmt. Ich hatte das so verstanden, dass er die Gruppe aus den NTFS-Rechten des Verzeichnisses entfernt hätte und durch die dezidierte Gruppe ersetzt hat.
Setz doch auf D:\ erstmal die Rechte ordentlich.
System + Administratoren + Domänen-Administratoren
Und dann fügst du bei den Unterordnern die entsprechenden Rechte hinzu!
System + Administratoren + Domänen-Administratoren
Und dann fügst du bei den Unterordnern die entsprechenden Rechte hinzu!
Ich habe zunächst mal die Domänenbenutzer aus der Gruppe der lokalen Benutzer geworfen.
Mutig ...
Hi
Steht in der Freigabeberechtigung jeder oder Authentifizierte Benutzer drinnen ?
Ändere das mal auf die grp_DBUser.
Dann können nurnoch die zugreifen
Mit freundlichen Grüßen
Nemesis
Steht in der Freigabeberechtigung jeder oder Authentifizierte Benutzer drinnen ?
Ändere das mal auf die grp_DBUser.
Dann können nurnoch die zugreifen
Mit freundlichen Grüßen
Nemesis
Hallo zusammen.
Warum sollte auf einem Server, der nur für diesen einen Zweck (eine DB lauft darauf und eine EXE auf einem Share wird ausgeführt) läuft, die Gruppe der Domänenbenutzer in der Gruppe der lokalen Benutzer enthalten sein?
Das unterbrechen von Vererbungen sehe ich prinzipiell eher als eine Notlösung. Und dann auch noch den lokalen Benutzern den Zugriff auf den lokalen Ordner entziehen. Hm. Gefällt mir irgendwie nicht wirklich.
Den Zugriff über die Beschränkung der Freigabe zu regeln "macht man nicht"
kann ich aus dem Stehgreif garnicht begründen, aber das sollte über NTFS laufen.
Ich denk nochmal drüber nach ... aber ich hänge aktuell an:
ALLE Domainuser sind grundsätzlich auch Mitglied der lokalen User auf ALLEN Systemen im LAN.
Das klingt nicht gut und nicht logisch.
thx
Zitat von @DerWoWusste:
Aber er schreibt doch:
Aber er schreibt doch:
Ich habe zunächst mal die Domänenbenutzer aus der Gruppe der lokalen Benutzer geworfen.
Und DAS macht man lieber nicht.Warum sollte auf einem Server, der nur für diesen einen Zweck (eine DB lauft darauf und eine EXE auf einem Share wird ausgeführt) läuft, die Gruppe der Domänenbenutzer in der Gruppe der lokalen Benutzer enthalten sein?
Das unterbrechen von Vererbungen sehe ich prinzipiell eher als eine Notlösung. Und dann auch noch den lokalen Benutzern den Zugriff auf den lokalen Ordner entziehen. Hm. Gefällt mir irgendwie nicht wirklich.
Den Zugriff über die Beschränkung der Freigabe zu regeln "macht man nicht"
kann ich aus dem Stehgreif garnicht begründen, aber das sollte über NTFS laufen.Ich denk nochmal drüber nach ... aber ich hänge aktuell an:
ALLE Domainuser sind grundsätzlich auch Mitglied der lokalen User auf ALLEN Systemen im LAN.
Das klingt nicht gut und nicht logisch.
thx
Warum sollte auf einem Server, der nur für diesen einen Zweck (eine DB lauft darauf und eine EXE auf einem Share wird ausgeführt) läuft, die Gruppe der Domänenbenutzer in der Gruppe der lokalen Benutzer enthalten sein?
Das ist der Default. An Defaults zu schrauben macht man immer nur mit Bedacht. Die Mitgliedschaft beinhaltet bestimmte Privilegien, zum Beispiel das Recht der lokalen Anmeldung.Und dann auch noch den lokalen Benutzern den Zugriff auf den lokalen Ordner entziehen. Hm. Gefällt mir irgendwie nicht wirklich.
Du sprachst bislang noch nicht davon, dass es lokale Nutzer gibt. Das wäre dann ein Terminalserver (?). Die Admins kommen ja weiterhin rauf.Mach es wie Du magst - ich habe nur darauf hingewiesen, dass es Konsequenzen hat, die Mitgliedschaft in der Gruppe der lokalen Nutzer zu entfernen.
Moin
Was bleibt Dir aber anderes übrig, wenn Du nicht auf einem Laufwerk/einer Freigabe nur einen Satz an Berechtigungen haben willst? Diese "Notlösung" ist eher der Standard, wenn man mit Berechtigungen arbeiten will.
Genau. Freigabeberechtigungen fast man nicht wirklich an. Da kann man auch durch aus mit "Jeder" und ""ändern" arbeiten. Wenn Du anfängst, Zugriffsrechte über die Freigabe zu setzen, produzierst Du nur unnötiges Chaos.
Doch.. das ist absolut logisch @DerWoWusste hat recht...
Die Domänenbenutzer bekommen ihre Rechte auf dem lokalen System dadurch, dass sie als Gruppe Mitglied in der Benutzergruppe sind. Domänenbenutzer an sich haben keine Rechte auf den Systemen. Die Rechte erhalten sie erst durch diese Verschachtelung.
Was übrigens auch für die administrativen Rechte gilt. Der Domänenadministrator hat nur deshalb administrative Rechte auf dem Client, weil er durch die Aufnahme des Clients der lokale Administratorgruppe über die Gruppe der Domänenadministratoren hinzugefügt wird.
Ich habe da gerade "live" bei einem Kunden erlebt, dass der Buchhalter meinte, er müsse an den Berechtigungen auf seinem DATEV-System rumbasteln. Irgendwann lief auf dem System nicht mehr viel. Wir habe es veruscht, das alles irgendwie noch zu reparieren - schlussendlich haben wir die Maschine aus dem Backup wiederhergestellt.
Gruß
Zitat von @Aubanan:
Warum sollte auf einem Server, der nur für diesen einen Zweck (eine DB lauft darauf und eine EXE auf einem Share wird ausgeführt) läuft, die Gruppe der Domänenbenutzer in der Gruppe der lokalen Benutzer enthalten sein?
Das unterbrechen von Vererbungen sehe ich prinzipiell eher als eine Notlösung. Und dann auch noch den lokalen Benutzern den Zugriff auf den lokalen Ordner entziehen. Hm. Gefällt mir irgendwie nicht wirklich.
Warum sollte auf einem Server, der nur für diesen einen Zweck (eine DB lauft darauf und eine EXE auf einem Share wird ausgeführt) läuft, die Gruppe der Domänenbenutzer in der Gruppe der lokalen Benutzer enthalten sein?
Das unterbrechen von Vererbungen sehe ich prinzipiell eher als eine Notlösung. Und dann auch noch den lokalen Benutzern den Zugriff auf den lokalen Ordner entziehen. Hm. Gefällt mir irgendwie nicht wirklich.
Was bleibt Dir aber anderes übrig, wenn Du nicht auf einem Laufwerk/einer Freigabe nur einen Satz an Berechtigungen haben willst? Diese "Notlösung" ist eher der Standard, wenn man mit Berechtigungen arbeiten will.
Den Zugriff über die Beschränkung der Freigabe zu regeln "macht man nicht" kann ich aus dem Stehgreif garnicht begründen, aber das sollte über NTFS laufen.
kann ich aus dem Stehgreif garnicht begründen, aber das sollte über NTFS laufen.Genau. Freigabeberechtigungen fast man nicht wirklich an. Da kann man auch durch aus mit "Jeder" und ""ändern" arbeiten. Wenn Du anfängst, Zugriffsrechte über die Freigabe zu setzen, produzierst Du nur unnötiges Chaos.
Ich denk nochmal drüber nach ... aber ich hänge aktuell an:
ALLE Domainuser sind grundsätzlich auch Mitglied der lokalen User auf ALLEN Systemen im LAN.
Das klingt nicht gut und nicht logisch.
ALLE Domainuser sind grundsätzlich auch Mitglied der lokalen User auf ALLEN Systemen im LAN.
Das klingt nicht gut und nicht logisch.
Doch.. das ist absolut logisch
@DerWoWusste hat recht...Die Domänenbenutzer bekommen ihre Rechte auf dem lokalen System dadurch, dass sie als Gruppe Mitglied in der Benutzergruppe sind. Domänenbenutzer an sich haben keine Rechte auf den Systemen. Die Rechte erhalten sie erst durch diese Verschachtelung.
Was übrigens auch für die administrativen Rechte gilt. Der Domänenadministrator hat nur deshalb administrative Rechte auf dem Client, weil er durch die Aufnahme des Clients der lokale Administratorgruppe über die Gruppe der Domänenadministratoren hinzugefügt wird.
Ich habe da gerade "live" bei einem Kunden erlebt, dass der Buchhalter meinte, er müsse an den Berechtigungen auf seinem DATEV-System rumbasteln. Irgendwann lief auf dem System nicht mehr viel. Wir habe es veruscht, das alles irgendwie noch zu reparieren - schlussendlich haben wir die Maschine aus dem Backup wiederhergestellt.
Gruß
Hi,
wenn ich einem Server ein Datenlaufwerk verpasse, dann ist es so ziemlich das Erste was ich nach der Formatierung mit NTFS mache, die ACL der Laufwerkswurzel zu bearbeiten und alles außer SYSTEM und Administratoren rauszuschmeißen. Das impliziert dann automatisch, dass man für jedes neue Datenverzeichnis auf diesem Laufwerk bewusst Zugriffsrechte erteilen muss, wenn dort nicht bloß SYSTEM und Administratoren drauf zugreifen müssen. Ich folge also hier primär dem Ansatz "nicht unterbrechen, nur hinzufügen".
Das funktioniert in 99,9999% aller Fälle. Der einzige Fall, welcher mir spontan einfällt, ist der WSUS Server, wo man aufpassen muss. Dieser verlangt, dass, wenn man die Ordner des WSUS-Servers auf das Datenlaufwerk verlegt, man dann dem Benutzer "Netzwerkdienst" ab der Root min. Lese-Rechte erteilt.
E.
wenn ich einem Server ein Datenlaufwerk verpasse, dann ist es so ziemlich das Erste was ich nach der Formatierung mit NTFS mache, die ACL der Laufwerkswurzel zu bearbeiten und alles außer SYSTEM und Administratoren rauszuschmeißen. Das impliziert dann automatisch, dass man für jedes neue Datenverzeichnis auf diesem Laufwerk bewusst Zugriffsrechte erteilen muss, wenn dort nicht bloß SYSTEM und Administratoren drauf zugreifen müssen. Ich folge also hier primär dem Ansatz "nicht unterbrechen, nur hinzufügen".
Das funktioniert in 99,9999% aller Fälle. Der einzige Fall, welcher mir spontan einfällt, ist der WSUS Server, wo man aufpassen muss. Dieser verlangt, dass, wenn man die Ordner des WSUS-Servers auf das Datenlaufwerk verlegt, man dann dem Benutzer "Netzwerkdienst" ab der Root min. Lese-Rechte erteilt.
E.
2Zitat von @emeriks:
Hi,
wenn ich einem Server ein Datenlaufwerk verpasse, dann ist es so ziemlich das Erste was ich nach der Formatierung mit NTFS mache, die ACL der Laufwerkswurzel zu bearbeiten und alles außer SYSTEM und Administratoren rauszuschmeißen. Das impliziert dann automatisch, dass man für jedes neue Datenverzeichnis auf diesem Laufwerk bewusst Zugriffsrechte erteilen muss, wenn dort nicht bloß SYSTEM und Administratoren drauf zugreifen müssen. Ich folge also hier primär dem Ansatz "nicht unterbrechen, nur hinzufügen".
Das funktioniert in 99,9999% aller Fälle. Der einzige Fall, welcher mir spontan einfällt, ist der WSUS Server, wo man aufpassen muss. Dieser verlangt, dass, wenn man die Ordner des WSUS-Servers auf das Datenlaufwerk verlegt, man dann dem Benutzer "Netzwerkdienst" ab der Root min. Lese-Rechte erteilt.
E.
Hi,
wenn ich einem Server ein Datenlaufwerk verpasse, dann ist es so ziemlich das Erste was ich nach der Formatierung mit NTFS mache, die ACL der Laufwerkswurzel zu bearbeiten und alles außer SYSTEM und Administratoren rauszuschmeißen. Das impliziert dann automatisch, dass man für jedes neue Datenverzeichnis auf diesem Laufwerk bewusst Zugriffsrechte erteilen muss, wenn dort nicht bloß SYSTEM und Administratoren drauf zugreifen müssen. Ich folge also hier primär dem Ansatz "nicht unterbrechen, nur hinzufügen".
Das funktioniert in 99,9999% aller Fälle. Der einzige Fall, welcher mir spontan einfällt, ist der WSUS Server, wo man aufpassen muss. Dieser verlangt, dass, wenn man die Ordner des WSUS-Servers auf das Datenlaufwerk verlegt, man dann dem Benutzer "Netzwerkdienst" ab der Root min. Lese-Rechte erteilt.
E.
Absolut, genau so! Bei SQL und HyperV muss man auch aufpassen.
Zitat von @emeriks:
wenn ich einem Server ein Datenlaufwerk verpasse, dann ist es so ziemlich das Erste was ich nach der Formatierung mit NTFS mache, die ACL der Laufwerkswurzel zu bearbeiten und alles außer SYSTEM und Administratoren rauszuschmeißen. [...]
wenn ich einem Server ein Datenlaufwerk verpasse, dann ist es so ziemlich das Erste was ich nach der Formatierung mit NTFS mache, die ACL der Laufwerkswurzel zu bearbeiten und alles außer SYSTEM und Administratoren rauszuschmeißen. [...]
Das klingt schonmal nach einem sauberen Ansatz.
Bedeutet aber, wenn ich als Admin etwas an den Dateien auf der Platte machen will, muss ich immer den Explorer z.B. mit erhöhten Rechten starten.
Grüße
Zitat von @Aubanan:
Bedeutet aber, wenn ich als Admin etwas an den Dateien auf der Platte machen will, muss ich immer den Explorer z.B. mit erhöhten Rechten starten.
Nö.Bedeutet aber, wenn ich als Admin etwas an den Dateien auf der Platte machen will, muss ich immer den Explorer z.B. mit erhöhten Rechten starten.
Entweder Du machst es von einem anderen Rechner über Netzwerk: \\server\lw$
Oder Du erstellst eine lokale Gruppe, z.B. "FileserverAdmins", und packst dort alle berechtigten Benutzer rein. Diese Gruppe bekommt ebenfalls Vollzugriff auf die Root des Laufwerks.
Statt lokaler Gruppe geht auch domänenlokale Gruppe.
1
Hallo!
Zunächst habe ich, wie oben beschrieben, aus den Berechtigungen des Root der Platte alle außer System und Administratoren entfernt.
In der Folge konnte ich nicht mehr mit dem Explorer auf das Laufwerk zugreifen.
Zu meiner Verwunderung auch dann nicht, wenn der Explorer "Als Administrator ausführen" gestartet wird.
Der TotalCommander hingegen kann, "Als Administrator ausführen" gestartet, zugreifen.
So habe ich es nun gemacht.
Es gibt nun eine lokale Gruppe der Lusers
Hier kam ein weiterer Aha Effekt: Die Gruppe der (lokalen) Administratoren lässt sich nicht in diese neue Gruppe hinzufügen.
Zunächst habe ich, wie oben beschrieben, aus den Berechtigungen des Root der Platte alle außer System und Administratoren entfernt.
In der Folge konnte ich nicht mehr mit dem Explorer auf das Laufwerk zugreifen.
Zu meiner Verwunderung auch dann nicht, wenn der Explorer "Als Administrator ausführen" gestartet wird.
Der TotalCommander hingegen kann, "Als Administrator ausführen" gestartet, zugreifen.
Zitat von @emeriks:
... Du erstellst eine lokale Gruppe, z.B. "FileserverAdmins", und packst dort alle berechtigten Benutzer rein. Diese Gruppe bekommt ebenfalls Vollzugriff auf die Root des Laufwerks.
... Du erstellst eine lokale Gruppe, z.B. "FileserverAdmins", und packst dort alle berechtigten Benutzer rein. Diese Gruppe bekommt ebenfalls Vollzugriff auf die Root des Laufwerks.
So habe ich es nun gemacht.
Es gibt nun eine lokale Gruppe der Lusers
Hier kam ein weiterer Aha Effekt: Die Gruppe der (lokalen) Administratoren lässt sich nicht in diese neue Gruppe hinzufügen.
Zu meiner Verwunderung auch dann nicht, wenn der Explorer "Als Administrator ausführen" gestartet wird.
Um den Explorer wirklich elevated starten zu können, gehe so vor:start regedit.exe and go to the following key:
HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}
make a right click on Permissions and set your user as owner (click on advanced button to be
able to take ownership) of the key and give your current user writing permissions.
Next, rename the value RunAs to _Runas
Danach kann man explorer.exe Rechtsklicken und „als Administrator ausführen wählen“ und er
handelt dann auch so wie erwartet.
2Zitat von @DerWoWusste:
Um den Explorer wirklich elevated starten zu können, gehe so vor:
start regedit.exe and go to the following key:
[...]start regedit.exe and go to the following key:
Danke für die Info.
Das werde ich so nicht machen. Da bleibe ich lieber beim TotalCommander.
Grüße
1
