5
Schreibschutz auf ProgramData - Euer Workaround
Hallo Admins und Systemintegratoren,
aktuell stehen bei uns in der Firma wieder Rollouts von Windows 7 Betriebssystemen an und da demnächst auch in eine neue Serverinfrastruktur investiert wird, kann es nicht schaden das bisherige Vorgehen mal zu hinterfragen.
Immer wieder führt es zu Problemen, dass die normalen Benutzer standardmäßig nicht in den Verzeichnissen ProgramData und ProgramFiles schreiben dürfen, was bedeutet, dass die meisten Programme entweder keine Einstellungen speichern können oder eben sofort abschmieren.
Bisher haben wir dann ohne großartiges Hinterfragen dem Benutzer dann eben auch Schreibrechte auf die Verzeichnisse gegeben und alle waren mit dieser Lösung mehr oder weniger glücklich. (Administrationsrechte soll der Benutzer nicht haben.)
Nun sind aktuell aber irgendwie Zweifel an dem bisherigen Vorgehen da. Ich geh einfach mal davon aus, Microsoft hat diese Hürde nicht ohne Grund eingeführt und hat sich vermutlich auch etwas dabei gedacht. Natürlich kann ich nun wie schon bereits in der Vergangenheit geschehen, dieses Prinzip aufbohren und die User gewähren lassen. Aber damit führe ich ja eigentlich die Kernfunktion ad absurdum.
Interessant wäre für mich nur zu wissen, wie sich Microsoft das eigentlich gedacht hat und/oder ob jemand von euch eine elegantere Methode hat, die er vielleicht kurz vorstellen möchte, bzw. Anregungen geben möchte.
Vielen Dank!
aktuell stehen bei uns in der Firma wieder Rollouts von Windows 7 Betriebssystemen an und da demnächst auch in eine neue Serverinfrastruktur investiert wird, kann es nicht schaden das bisherige Vorgehen mal zu hinterfragen.
Immer wieder führt es zu Problemen, dass die normalen Benutzer standardmäßig nicht in den Verzeichnissen ProgramData und ProgramFiles schreiben dürfen, was bedeutet, dass die meisten Programme entweder keine Einstellungen speichern können oder eben sofort abschmieren.
Bisher haben wir dann ohne großartiges Hinterfragen dem Benutzer dann eben auch Schreibrechte auf die Verzeichnisse gegeben und alle waren mit dieser Lösung mehr oder weniger glücklich. (Administrationsrechte soll der Benutzer nicht haben.)
Nun sind aktuell aber irgendwie Zweifel an dem bisherigen Vorgehen da. Ich geh einfach mal davon aus, Microsoft hat diese Hürde nicht ohne Grund eingeführt und hat sich vermutlich auch etwas dabei gedacht. Natürlich kann ich nun wie schon bereits in der Vergangenheit geschehen, dieses Prinzip aufbohren und die User gewähren lassen. Aber damit führe ich ja eigentlich die Kernfunktion ad absurdum.
Interessant wäre für mich nur zu wissen, wie sich Microsoft das eigentlich gedacht hat und/oder ob jemand von euch eine elegantere Methode hat, die er vielleicht kurz vorstellen möchte, bzw. Anregungen geben möchte.
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 227226
Url: https://administrator.de/contentid/227226
Printed on: April 20, 2024 at 01:04 o'clock
5 Comments
Latest comment
Moin,
1. Für sowas gibt es den VirtualStore (%localappdata%\VirtualStore) seit Vista oder 7, bin ich mir nicht ganz sicher.
Edit: Infos: http://blog.m-ri.de/index.php/2007/02/10/der-virtualstore-und-seine-sch ...
2. Eigentlich sollten Einstellungen unter %appdata% gespeichert werden.
Gruß
Chris
1. Für sowas gibt es den VirtualStore (%localappdata%\VirtualStore) seit Vista oder 7, bin ich mir nicht ganz sicher.
Edit: Infos: http://blog.m-ri.de/index.php/2007/02/10/der-virtualstore-und-seine-sch ...
2. Eigentlich sollten Einstellungen unter %appdata% gespeichert werden.
Gruß
Chris
1
Hallo,
Ja. Software verwenden die für dein OS Entwickelt und getestet und freigegeben wurde. Krasse Antwort? Vielleicht. Du füllst in deinen Auto ja auch kein Sprint ein der von deinen Motor nicht genutzt werden kann, oder? Warum dann bei einem OS (Hier W7)?
Mit dem Vista wurde ein neues Sicherheitsmodell eingeführt und mit W7 und W8 weiterentwickelt. Das trennen von Programm und Daten aber auch vom OS und Benutzer ist das Ziel. Dazu gehören Restriktionen mancher Ordner aber auch in der Windows Registrierung hat es entsprechende Einschränkungen gegeben. Wer heute noch mit VB 1.0 seine Software entwickelt, braucht sich nicht zu Wundern wenn diese auf aktuellen OSe einfach nur Feuer und Rauch erzeugen.
Du würdest ja auch auf keinem Unix versuchen dein MS-DOS Programm installiert zu bekommen oder gar damit dort Arbeiten wollen. (Ohne Emulatoren usw)
Auch ein Windows wird Kontinuierlich intern weiterentwickelt. Aussen siehst du trotzdem nur deine bunten Bilder
Auch ich kenne sehr aktuelle und vor allem sehr teuere Business Software wo der Hersteller (z.B. Sage Frankreich bzw. Spanien) tatsächlich darauf besteht die UAC auszuschalten und dem normalen Nutzer zwingend Admin Rechte zu gewähren, und das zum Arbeiten. Über die Installation und die nötigen Klimmzüge mal gar nicht zu sprechen. Und das Produkt ist angeblich geprüft und Zertifiziert für bis zu Windows 8.1 pro usw.. Home Versionen werden von der Software bei der Installation gar nicht erst zugelassen. Haha.
Einige Entwickler haben noch nicht mal das XP verstanden.... und Entwickeln zwar mit modernen Werkzeuge aber immer noch nach Schema Windows 3.0...
Jetzt such dir aus was dein Problem ist
Gruß,
Peter
Ja. Software verwenden die für dein OS Entwickelt und getestet und freigegeben wurde. Krasse Antwort? Vielleicht. Du füllst in deinen Auto ja auch kein Sprint ein der von deinen Motor nicht genutzt werden kann, oder? Warum dann bei einem OS (Hier W7)?
Mit dem Vista wurde ein neues Sicherheitsmodell eingeführt und mit W7 und W8 weiterentwickelt. Das trennen von Programm und Daten aber auch vom OS und Benutzer ist das Ziel. Dazu gehören Restriktionen mancher Ordner aber auch in der Windows Registrierung hat es entsprechende Einschränkungen gegeben. Wer heute noch mit VB 1.0 seine Software entwickelt, braucht sich nicht zu Wundern wenn diese auf aktuellen OSe einfach nur Feuer und Rauch erzeugen.
Du würdest ja auch auf keinem Unix versuchen dein MS-DOS Programm installiert zu bekommen oder gar damit dort Arbeiten wollen. (Ohne Emulatoren usw)
Auch ein Windows wird Kontinuierlich intern weiterentwickelt. Aussen siehst du trotzdem nur deine bunten Bilder
Auch ich kenne sehr aktuelle und vor allem sehr teuere Business Software wo der Hersteller (z.B. Sage Frankreich bzw. Spanien) tatsächlich darauf besteht die UAC auszuschalten und dem normalen Nutzer zwingend Admin Rechte zu gewähren, und das zum Arbeiten. Über die Installation und die nötigen Klimmzüge mal gar nicht zu sprechen. Und das Produkt ist angeblich geprüft und Zertifiziert für bis zu Windows 8.1 pro usw.. Home Versionen werden von der Software bei der Installation gar nicht erst zugelassen. Haha.
Einige Entwickler haben noch nicht mal das XP verstanden.... und Entwickeln zwar mit modernen Werkzeuge aber immer noch nach Schema Windows 3.0...
Jetzt such dir aus was dein Problem ist
Gruß,
Peter
4
Moin,
Ansonsten schliesse ich mich Chris an:
lg,
Slainte
.... nicht in den Verzeichnissen ProgramData und ProgramFiles schreiben dürfen ...
Das ist aber nicht erst seit Win7 so. Bereits unter 2000/XP konnte der Normale User da nichts rein schreiben (sofern man auf NTFS installiert hat)Bisher haben wir dann ohne großartiges Hinterfragen dem Benutzer dann eben auch Schreibrechte auf die Verzeichnisse gegeben und alle
waren mit dieser Lösung mehr oder weniger glücklich. (Administrationsrechte soll der Benutzer nicht haben.)
Damit ist im Prinzip die komplette Security deiner PCs kompromittiert.waren mit dieser Lösung mehr oder weniger glücklich. (Administrationsrechte soll der Benutzer nicht haben.)
Ansonsten schliesse ich mich Chris an:
Eigentlich sollten Einstellungen unter %appdata% gespeichert werden.
Und Pogramme die sich nicht daran halten haben im Unternehmensumfeld nichts verloren.lg,
Slainte
2
Sers,
es gibt ja leider immer noch Softwarehersteller die sich kategorisch weigern %AppData% zu verwenden. Deltra mit der ERP Software Orgamax gehört hier leider dazu. In dem Fall ist der Workaround die Software etwa nach c:\orgamax zu installieren. Per Default haben dann auch normale Nutzer Schreibrechte auf das Programmverzeichnis.
Die 3D-Drucker Software ObjetStudio ist auch so ein Fall. Die braucht dann aber auch Schreibzugriff auf %ProgramData%, %ProgramFiles% und HKLM. Das volle Programm eben.
Was in solchen Fällen aber klar sein muss: Ordnerüberwachung auf die jeweiligen Verzeichnisse.
Ansonsten hat @christoph.kern natürlich voll und ganz Recht. Also fühl deinen Softwarelieferanten auf den Zahn. Irgendwann wird die Anpassung schon kommen. Und wenn sie einfach nur deswegen kommt damit deine Nerverei aufhört
Grüße,
Philip
es gibt ja leider immer noch Softwarehersteller die sich kategorisch weigern %AppData% zu verwenden. Deltra mit der ERP Software Orgamax gehört hier leider dazu. In dem Fall ist der Workaround die Software etwa nach c:\orgamax zu installieren. Per Default haben dann auch normale Nutzer Schreibrechte auf das Programmverzeichnis.
Die 3D-Drucker Software ObjetStudio ist auch so ein Fall. Die braucht dann aber auch Schreibzugriff auf %ProgramData%, %ProgramFiles% und HKLM. Das volle Programm eben.
Was in solchen Fällen aber klar sein muss: Ordnerüberwachung auf die jeweiligen Verzeichnisse.
Ansonsten hat @christoph.kern natürlich voll und ganz Recht. Also fühl deinen Softwarelieferanten auf den Zahn. Irgendwann wird die Anpassung schon kommen. Und wenn sie einfach nur deswegen kommt damit deine Nerverei aufhört
Grüße,
Philip
1
Moin.
Kann mich diversen Vorrednern anschließen und füge hinzu:
Kann mich diversen Vorrednern anschließen und füge hinzu:
Immer wieder führt es zu Problemen, dass die normalen Benutzer standardmäßig nicht in den Verzeichnissen ProgramData und ProgramFiles schreiben dürfen, was bedeutet, dass die meisten Programme entweder keine Einstellungen speichern können oder eben sofort abschmieren.
Immer wieder? Bei uns ist das die absolute Ausnahme. Der genannte Virtual store schaltet sich nämlich automatisch ein, um dieses Problem zu umschiffen...wenn...ja wenn die UAC an ist. Ohne gibt's keine Ordnervirtualisierung.
