31
Technische und ethische Frage zur Benutzerkontensteuerung
Hallo,
ich habe eine Frage zur UAC, da ich gestern fast aus allen Wolken gefallen bin, als ich erfahren habe, dass die Entwickler einer Server-Client-Software, die eines unserer Kunden einsetzt, Administratorrechte zum Ausführen sämtlicher Funktionen der Software nutzen zu können. Das klingt erst einmal übel. Schlimmer wird es wenn man erfährt, dass es sich dabei schlicht nur um eine einzige .EXE-Datei handelt, die nichts weiter tut als von der Server-Freigabe eine Datei zu kopieren und auf dem Client die entsprechende Datei zu überschreiben; nur eine einzige Datei wird kopiert! Hierbei handelt es sich um eine .MDB-Datei, die auf dem Client mit einer Access Runtime gestartet wird. Nur das Ausführen dieser .EXE-Datei, die nicht in "C:\Program Files (x86)" o.Ä. liegt, benüötigt erhöhte Rechte.
Also anstatt diese copy.exe so zu entwickeln, dass sie den Sicherheitsrichtlinien von Windows (in diesem Fall Windows 7) entsprechen und von der UAC beim Ausführen verschont bleibt, rät bzw. zwingt man die Nutzer dazu über Administratorrechte in Form einer deaktivierten Benutzerkontensteuerung (es geht nur deaktiviert; die beiden Zwischenstufen ändern nichts), ausschließlich damit das Update dieser Datei, das vielleicht alle paar Wochen einmalig notwendig ist, funktioniert.
Habe ich richtig gehandelt, indem ich gesagt habe, dass das dort nicht stattfinden wird und die UAC aktiviert bleibt? Ich habe selbst eine .BAT-Datei geschrieben, die genau denselben Zweck wie diese copy.exe erfüllt und es funktioniert tadellos, nur eben nicht aus dem Programm heraus, da man sich weigert für den Kunden den internen Pfad von copy.exe auf meine copy.bat zu ändern. Ist aber halb so wild, da man den Nutzern das nur so erklären muss; es sind dort nicht viele.
Ich verstehe das einfach nicht, dass Entwickler den Weg des geringsten Widerstands gehen und ihren Kunden diesen Weg auch noch aufzwingen mit einem herben Verlust der inneren Sicherheit im Netzwerk. Oder mache ich nur etwas falsch? Ist es wirklich so, wie der Vertreter der Software sagt, dass jeder seiner Kunden keine aktivierte UAC hat? Wie gewährleistet man da die Sicherheit und überhaupt Funktionalität? Wenn ich als normaler Domänenbenutzer eine ausgeschaltete UAC habe, dann kann ich entweder alles (Regestry ändern, CMD ausführen, etc.) machen oder ich kann eine Anwendung erst gar nicht starten, da entweder kein Administratorkennwort abgefragt wird oder überhaupt das AAM-Fenster zum Bestätigen des Vorgangs erscheint.
Ich hoffe nur dass ich mich irre und ich nur nicht weiß, wie ich Windows (7) sicher(er) machen kann ohne die UAC eingeschaltetet zu haben, sodass die Nutzer eben keine Administratorrechte haben, aber dennoch alle für sie notwendigen Anwendungen ausführen können.
Das ist für mich gerade ein ethisches Dilemma, da ich so langsam das Vertrauen in das Sicherheitsbewusstsein von Drittanbietersoftware verliere. Quick & Dirty ist keine Lösung weder in großen noch in kleinen Unternehmen. Und solange ich für den Kunden sein Netzwerk administriere findet das auch nicht statt.
Hat jemand ähnliche Erfahrungen?
Grüße Winary
ich habe eine Frage zur UAC, da ich gestern fast aus allen Wolken gefallen bin, als ich erfahren habe, dass die Entwickler einer Server-Client-Software, die eines unserer Kunden einsetzt, Administratorrechte zum Ausführen sämtlicher Funktionen der Software nutzen zu können. Das klingt erst einmal übel. Schlimmer wird es wenn man erfährt, dass es sich dabei schlicht nur um eine einzige .EXE-Datei handelt, die nichts weiter tut als von der Server-Freigabe eine Datei zu kopieren und auf dem Client die entsprechende Datei zu überschreiben; nur eine einzige Datei wird kopiert! Hierbei handelt es sich um eine .MDB-Datei, die auf dem Client mit einer Access Runtime gestartet wird. Nur das Ausführen dieser .EXE-Datei, die nicht in "C:\Program Files (x86)" o.Ä. liegt, benüötigt erhöhte Rechte.
Also anstatt diese copy.exe so zu entwickeln, dass sie den Sicherheitsrichtlinien von Windows (in diesem Fall Windows 7) entsprechen und von der UAC beim Ausführen verschont bleibt, rät bzw. zwingt man die Nutzer dazu über Administratorrechte in Form einer deaktivierten Benutzerkontensteuerung (es geht nur deaktiviert; die beiden Zwischenstufen ändern nichts), ausschließlich damit das Update dieser Datei, das vielleicht alle paar Wochen einmalig notwendig ist, funktioniert.
Habe ich richtig gehandelt, indem ich gesagt habe, dass das dort nicht stattfinden wird und die UAC aktiviert bleibt? Ich habe selbst eine .BAT-Datei geschrieben, die genau denselben Zweck wie diese copy.exe erfüllt und es funktioniert tadellos, nur eben nicht aus dem Programm heraus, da man sich weigert für den Kunden den internen Pfad von copy.exe auf meine copy.bat zu ändern. Ist aber halb so wild, da man den Nutzern das nur so erklären muss; es sind dort nicht viele.
Ich verstehe das einfach nicht, dass Entwickler den Weg des geringsten Widerstands gehen und ihren Kunden diesen Weg auch noch aufzwingen mit einem herben Verlust der inneren Sicherheit im Netzwerk. Oder mache ich nur etwas falsch? Ist es wirklich so, wie der Vertreter der Software sagt, dass jeder seiner Kunden keine aktivierte UAC hat? Wie gewährleistet man da die Sicherheit und überhaupt Funktionalität? Wenn ich als normaler Domänenbenutzer eine ausgeschaltete UAC habe, dann kann ich entweder alles (Regestry ändern, CMD ausführen, etc.) machen oder ich kann eine Anwendung erst gar nicht starten, da entweder kein Administratorkennwort abgefragt wird oder überhaupt das AAM-Fenster zum Bestätigen des Vorgangs erscheint.
Ich hoffe nur dass ich mich irre und ich nur nicht weiß, wie ich Windows (7) sicher(er) machen kann ohne die UAC eingeschaltetet zu haben, sodass die Nutzer eben keine Administratorrechte haben, aber dennoch alle für sie notwendigen Anwendungen ausführen können.
Das ist für mich gerade ein ethisches Dilemma, da ich so langsam das Vertrauen in das Sicherheitsbewusstsein von Drittanbietersoftware verliere. Quick & Dirty ist keine Lösung weder in großen noch in kleinen Unternehmen. Und solange ich für den Kunden sein Netzwerk administriere findet das auch nicht statt.
Hat jemand ähnliche Erfahrungen?
Grüße Winary
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: 298161
Url: https://administrator.de/forum/technische-und-ethische-frage-zur-benutzerkontensteuerung-298161.html
Ausgedruckt am: 22.12.2024 um 14:12 Uhr
31 Kommentare
Neuester Kommentar
Hi.
Halt den Ball flach. Zum kopieren wird der Hersteller wohl kaum Adminrechte anfordern, Wenn doch, frag ihn, was das soll und lass es ihn abstellen, wenn Ihr im Vorfeld vereinbart habt, dass zum Betrieb keine Adminrechte benötigt werden.
Dein langer Text bettelt doch um Diskussion. Nur leider ist diese Diskussion uralt und hängt jedem Securitymensch zum Hals raus, soweit ich das wahrnehme (außer natürlich denen, die gerne viel schreiben und ihre Schlauheit kund tun).
Edit:
Was soll das bitte sein:
Halt den Ball flach. Zum kopieren wird der Hersteller wohl kaum Adminrechte anfordern, Wenn doch, frag ihn, was das soll und lass es ihn abstellen, wenn Ihr im Vorfeld vereinbart habt, dass zum Betrieb keine Adminrechte benötigt werden.
Dein langer Text bettelt doch um Diskussion. Nur leider ist diese Diskussion uralt und hängt jedem Securitymensch zum Hals raus, soweit ich das wahrnehme (außer natürlich denen, die gerne viel schreiben und ihre Schlauheit kund tun).
Edit:
Was soll das bitte sein:
zwingt man die Nutzer dazu über Administratorrechte in Form einer deaktivierten Benutzerkontensteuerung
UAC deaktiviert ist doch nicht das selbe wie Adminrechte an Nutzer vergeben.
Hi,
vollkommen unabhängig vom UAC: Eine Anwendung, welche in einem produktiven Netzwerk läuft, und nur dann funktioniert, wenn der Benutzer lokale Adminrechte hat, gehört ausgetauscht!
Und: Auch wenn UAC eingeschaltet ist, haben die Benutzer diese Adminrechte, wenn sie sie haben. Aktiviertes UAC bedeutet nur, das jedesmal, wenn ein Programm die Adminrechte des Benutzers in Anspruch nehmen will, dieser das erst bestätigen muss.
D.h., dass Dein offensichtlicher Glaube, dass aktiviertes UAC den Benutzern die Adminrechte deaktiviert, wenn sie Mitglieder der lokalen Administratoren sind, falsch ist.
E.
vollkommen unabhängig vom UAC: Eine Anwendung, welche in einem produktiven Netzwerk läuft, und nur dann funktioniert, wenn der Benutzer lokale Adminrechte hat, gehört ausgetauscht!
Und: Auch wenn UAC eingeschaltet ist, haben die Benutzer diese Adminrechte, wenn sie sie haben. Aktiviertes UAC bedeutet nur, das jedesmal, wenn ein Programm die Adminrechte des Benutzers in Anspruch nehmen will, dieser das erst bestätigen muss.
D.h., dass Dein offensichtlicher Glaube, dass aktiviertes UAC den Benutzern die Adminrechte deaktiviert, wenn sie Mitglieder der lokalen Administratoren sind, falsch ist.
E.
Dein langer Text bettelt doch um Diskussion. Nur leider ist diese Diskussion uralt und hängt jedem Securitymensch zum Hals raus, soweit ich das wahrnehme
dito
Zitat von @DerWoWusste:
Halt den Ball flach. Zum kopieren wird der Hersteller wohl kaum Adminrechte anfordern, Wenn doch, frag ihn, was das soll und lass es ihn abstellen, wenn Ihr im Vorfeld vereinbart habt, dass zum Betrieb keine Adminrechte benötigt werden.
Halt den Ball flach. Zum kopieren wird der Hersteller wohl kaum Adminrechte anfordern, Wenn doch, frag ihn, was das soll und lass es ihn abstellen, wenn Ihr im Vorfeld vereinbart habt, dass zum Betrieb keine Adminrechte benötigt werden.
Wenn die UAC aktiv ist und ich als Domänenbenutzer angemeldet bin und diese copy.exe ausführe wird nach dem Administratorkennwort gefragt. Wenn ich aus dem Programm heraus auf das Feld "Update" klicke, das diese copy.exe startet, wird der Vorgang mit einem Fehler bzgl. Remoteprozeduraufruf abgebrochen. Ich habe mir von dem Vertreter erzählen lassen, dass das typisch sein soll wenn die UAC erkennt, dass das Programm aus einer dem PC externen Freigabe eine Datei auf den PC kopieren will; ich habe mir meinen Teil dabei gedacht, da meine .BAT, die auch nur einen xcopy-Befehl innehat, ganz normal im Kontext des Nutzers funktioniert. Ich würde das gerne abstellen lassen, aber Einzelfälle werden offenbar nicht berücksichtigt. Ich kann mir auch nicht vorstellen, dass das bei den seinen anderen Kunden, die dieselbe Software einsetzen, auch so ein problem ist; daher meine Zweifel, ob nur ich vielleicht etwas falsch mache.
Dein langer Text bettelt doch um Diskussion. Nur leider ist diese Diskussion uralt und hängt jedem Securitymensch zum Hals raus, soweit ich das wahrnehme (außer natürlich denen, die gerne viel schreiben und ihre Schlauheit kund tun).
Eine Diskussion war vielleicht nicht der Zweck der Frage, aber ich habe auch nichts dagegen. Ich wollte mehr nur andere Meinungen dazu hören. Ich wollte natürlich aber auch niemanden langweilen, der mit den Umständen schon seit Langem vertraut ist. Tut mir Leid wenn das gerade der Fall ist. Ich bitte um Nachsicht, wenn ich dieses Medium hier nur nutzen sollte falls ich mir nur Luft machen wollte; da bin ich mir noch nicht sicher.
UAC deaktiviert ist doch nicht das selbe wie Adminrechte an Nutzer vergeben.
Wie ich gerade schon genannt habe ist es in dieser Umgebung aber so. Wenn ich die UAC deaktiviere kann ein Domänenbenutzer entweder Systemprogramme ausführen, auch wenn er logischerweise kein lokaler/Domänen-Admnistrator ist oder sie nicht starten weil keine Abfrage nach einem Administratorkennwort kommt. Die PCs sind frisch aufgesetzt und ich sehe keine GPO o.Ä. die irgendetwas mit dem Thema zutun hat. Klar kann ich nachträglich mit GPO dies und das einschränken, aber das ist ja dann nicht so dynamisch wie die UAC. Und ich würde aus diesem Umstand heraus schon die UAC eingeschaltet lassen. Ich will auch nichts zusammenbasteln, dass diese copy.exe von der UAC ausgenommen wird, das ist ja nicht der Sinn dahinter und mir selbst bei der geringen Anzahl an Rechnern dort zu aufwendig.
Zitat von @emeriks:
vollkommen unabhängig vom UAC: Eine Anwendung, welche in einem produktiven Netzwerk läuft, und nur dann funktioniert, wenn der Benutzer lokale Adminrechte hat, gehört ausgetauscht!
vollkommen unabhängig vom UAC: Eine Anwendung, welche in einem produktiven Netzwerk läuft, und nur dann funktioniert, wenn der Benutzer lokale Adminrechte hat, gehört ausgetauscht!
Das sage ich ja auch, daher habe ich selber diesen Kopiervorgang in eine Batch geschrieben. Das ist nur nicht so schick, wie das Update der Datei aus der Anwendung heraus.
Und: Auch wenn UAC eingeschaltet ist, haben die Benutzer diese Adminrechte, wenn sie sie haben. Aktiviertes UAC bedeutet nur, das jedesmal, wenn ein Programm die Adminrechte des Benutzers in Anspruch nehmen will, dieser das erst bestätigen muss.
Die Nutzer haben keine Adminrechte, weder über Gruppen im AD noch über die lokale Administratorgruppe.
D.h., dass Dein offensichtlicher Glaube, dass aktiviertes UAC den Benutzern die Adminrechte deaktiviert, wenn sie Mitglieder der lokalen Administratoren sind, falsch ist.
Das verstehe ich ja auch. Die Benutzer sind nur Domänenbenutzer ohne zugewiesene lokalen Administratorrechte. Insofern besteht keine Frage ob eine aktivierte UAC lokale Adminrechte deaktivert oder nicht.
Wenn die UAC aktiv ist und ich als Domänenbenutzer angemeldet bin und diese copy.exe ausführe wird nach dem Administratorkennwort gefragt.
Ja. Und schaltet man die UAC aus, wird es weiterhin nicht ohne Adminrechte funktionieren, da gibt es keinen Zweifel.
OK, jetzt wird da ein bisschen klarer.
Wenn die User keine lokalen Admins sind, und nur diese eine Funtion des Programms spinnt, wenn UAC aktiviert ist, dann würde ich im Interesse meiner Anwender einen "smarten" Betrieb sicherstellen wollen, also in den sauren Apfel beißen und UAC deaktivieren.
Du hast als Admin jederzeit die Möglichkeit über die Funktion "Als Administartor ausführen" oder "als anderer Benutzer ausführen" Programme zu starten, ohne den gerade interaktiv angemeldeten Benutzer abmelden zu müssen.
Und wenn ein Nicht-Admin Systemprogramme zwar starten, dort aber wegen fehlender Berechtigungen nichts ausrichten kann, dann ist das doch auch ok.
Wenn die User keine lokalen Admins sind, und nur diese eine Funtion des Programms spinnt, wenn UAC aktiviert ist, dann würde ich im Interesse meiner Anwender einen "smarten" Betrieb sicherstellen wollen, also in den sauren Apfel beißen und UAC deaktivieren.
Du hast als Admin jederzeit die Möglichkeit über die Funktion "Als Administartor ausführen" oder "als anderer Benutzer ausführen" Programme zu starten, ohne den gerade interaktiv angemeldeten Benutzer abmelden zu müssen.
Und wenn ein Nicht-Admin Systemprogramme zwar starten, dort aber wegen fehlender Berechtigungen nichts ausrichten kann, dann ist das doch auch ok.
Moin,
ich seh das recht pragmatisch: Wenn der Lieferant nicht auf den Kunden eingehen will, ist das die letzte Zeit der Lieferant gewesen.
Aber zu Deinem Problem:
Wenn die Aktion, durch eine einfache batch-datei im userkomtext ohen UAC zu triggern läuft und die Herstellerverseion eine abgeschaltete UAc erfordert, macht der herstelelr etwas falsch. Ich würde dem auch auf die Füßte treten.
Auch wenn UAc dem benutze rnciht mehr Rechte gewährt, als er ohnehin schon hat, ist es doch ein Hinweis, daß der User etwas tut, was erhöhte Rechte erfordert und man daher vorsichtig sein sollte.
Imho ist es daher durchaus legitim, dem Hersteller auf die Füße zu treten.
lks
PS: Wen Du die User trainieren kannst, dann trichter denen ein, daß sie einfach Deien BAT aufrufen sollen, wenn das nächste mal das UAC-fenster aufploppt-.
ich seh das recht pragmatisch: Wenn der Lieferant nicht auf den Kunden eingehen will, ist das die letzte Zeit der Lieferant gewesen.
Aber zu Deinem Problem:
Wenn die Aktion, durch eine einfache batch-datei im userkomtext ohen UAC zu triggern läuft und die Herstellerverseion eine abgeschaltete UAc erfordert, macht der herstelelr etwas falsch. Ich würde dem auch auf die Füßte treten.
Auch wenn UAc dem benutze rnciht mehr Rechte gewährt, als er ohnehin schon hat, ist es doch ein Hinweis, daß der User etwas tut, was erhöhte Rechte erfordert und man daher vorsichtig sein sollte.
Imho ist es daher durchaus legitim, dem Hersteller auf die Füße zu treten.
lks
PS: Wen Du die User trainieren kannst, dann trichter denen ein, daß sie einfach Deien BAT aufrufen sollen, wenn das nächste mal das UAC-fenster aufploppt-.
Zitat von @DerWoWusste:
Ja. Und schaltet man die UAC aus, wird es weiterhin nicht ohne Adminrechte funktionieren, da gibt es keinen Zweifel.
Ja. Und schaltet man die UAC aus, wird es weiterhin nicht ohne Adminrechte funktionieren, da gibt es keinen Zweifel.
Dann verstehe ich den Zusammenhang nicht, dass wenn ich die UAC deaktiviere und neustarte. Ein normaler Domänenbenutzer danach z.B. regedit.exe starten und bearbeiten kann. Gilt auch für mmc.exe, mit der ich beispielsweise den Zertifikatsspeicher des lokalen Computers öffnen kann. Wenn das nichts mit der UAC zutun hat habe ich keine Ahnung was noch daran beteiligt sein soll. Das gilt selbst für einen neu erstellten Domänenbenutzer ohne zusätzliche Berechtigungen oder Gruppenzugehörigkeiten.
Dann verstehe ich den Zusammenhang nicht, dass wenn ich die UAC deaktiviere und neustarte. Ein normaler Domänenbenutzer danach z.B. regedit.exe starten und bearbeiten kann. Gilt auch für mmc.exe, mit der ich beispielsweise den Zertifikatsspeicher des lokalen Computers öffnen kann. Wenn das nichts mit der UAC zutun hat habe ich keine Ahnung was noch daran beteiligt sein soll. Das gilt selbst für einen neu erstellten Domänenbenutzer ohne zusätzliche Berechtigungen oder Gruppenzugehörigkeiten.
Ich glaube, du machst Dich da gerade selbst meschugge. Programm starten können heißt noch lange nicht, damit Änderungen vornehmen zu können. Das gilt auch für Regedit. Wo der Benutzer keine Rechte hat, kann er nichst schreiben oder löschen. Und das er z.B. die Zertifikate des lokalen Computers lesen kann, ist sogar notwendig, weil er sie sonst gar nicht nutzen könnte. Also kann er auch mit der MMC in den Zertifikatsspeicher schauen. Wenn Du das nicht willst, dann sperre per GPO für Nicht-Admins diverse Programme. Regedit, CMD, MMC usw.
Du musst Dich mal informieren, wie das funktioniert. Es ist doch so einfach. Regedit braucht nicht per se hohe Rechte. Die mmc auch nicht. Beide kannst Du als Nichtadmin eingeloggt starten. Schau bitte mal, ob Du nachlesen kannst, was ein Application-Manifest ist und belies Dich bezüglich runashighest und runasinvoker, dann hast Du die Basis, die Du brauchst.
Danke dafür, dass ich mit meiner Meinung nicht ganz so falsch liege. Der Kunde kann auf diese Software leider nicht verzichten. Meinen Unmut habe ich dem Vertreter des Herstellers beherrscht geäußert, es wird sich aber nichts ändern. Mir unbegreiflich.
Es ist ja auch nur dieser Kopiervorgang dieser einen Datei. Das entspricht vielleicht 0,0001% vom Umfang der ganzen Anwendung. Da kann ich als Entwickler doch nur deswegen keine Administratorrechte verlangen. Mehr ist das ja nicht was ich nicht verstehe.
Natürlich sage ich den Nutzern, dass sie meine Batch nutzen sollen. Die UAC ploppt ja nur auf wenn ich die copy.exe direkt starte. Wenn ich das Update aus der Anwendung heraus ausführe kommt aber stattdessen ein Fehler. Und das stört schon im Arbeitsfluss für den Nutzer, selbst wenn er das mit dem Workaround lösen kann und wird.
Der Kunde kann auf diese Software leider nicht verzichten. Meinen Unmut habe ich dem Vertreter des Herstellers beherrscht geäußert, es wird sich aber nichts ändern. Mir unbegreiflich.Es ist ja auch nur dieser Kopiervorgang dieser einen Datei. Das entspricht vielleicht 0,0001% vom Umfang der ganzen Anwendung. Da kann ich als Entwickler doch nur deswegen keine Administratorrechte verlangen. Mehr ist das ja nicht was ich nicht verstehe.
Natürlich sage ich den Nutzern, dass sie meine Batch nutzen sollen. Die UAC ploppt ja nur auf wenn ich die copy.exe direkt starte. Wenn ich das Update aus der Anwendung heraus ausführe kommt aber stattdessen ein Fehler. Und das stört schon im Arbeitsfluss für den Nutzer, selbst wenn er das mit dem Workaround lösen kann und wird.
Zitat von @Winary:
Ich habe selbst eine .BAT-Datei geschrieben, die genau denselben Zweck wie diese copy.exe erfüllt und es funktioniert tadellos,
Grüße Winary
Ich habe selbst eine .BAT-Datei geschrieben, die genau denselben Zweck wie diese copy.exe erfüllt und es funktioniert tadellos,
Grüße Winary
Dann leg doch diese BAT-Datei auf den Desktop, stell die Programmfenstergröße so ein, dass an der Seite ein schmaler Streifen des Desktop (mit der BAT) sichtbar bleibt. So kann der Nutzer darauf klicken.
Alternativ: Link auf den Desktop zur Bat. Link-"Eigenschaften" mit Tastenkombination belegen (die nicht von dem Programm verwendet wird / abgefangen wird) , und schon kann der Nutzer mittels Tastenkombination - auch wenn das Programm aktiv ist - die BAT aufrufen.
Gruß
Holger
Edit: Gelben Zettel mit der Tastekombi an den Monitor pappen !!!
Zitat von @DerWoWusste:
Du musst Dich mal informieren, wie das funktioniert. Es ist doch so einfach. Regedit braucht nicht per se hohe Rechte. Die mmc auch nicht. Beide kannst Du als Nichtadmin eingeloggt starten. Schau bitte mal, ob Du nachlesen kannst, was ein Application-Manifest ist und belies Dich bezüglich runashighest und runasinvoker, dann hast Du die Basis, die Du brauchst.
Du musst Dich mal informieren, wie das funktioniert. Es ist doch so einfach. Regedit braucht nicht per se hohe Rechte. Die mmc auch nicht. Beide kannst Du als Nichtadmin eingeloggt starten. Schau bitte mal, ob Du nachlesen kannst, was ein Application-Manifest ist und belies Dich bezüglich runashighest und runasinvoker, dann hast Du die Basis, die Du brauchst.
Das Starten ja, aber auch das Bearbeiten/Ändern? Und der Zertifikatsspeicher des Computers? Den habe ich noch nicht als normaler Nutzer öffnen/beschreiben können. Ich muss mir nochmal alles genau anschauen. Vielleicht gibt es doch irgendwas, das den Nutzern erhöhte Rechte gibt.
Ich werde mich dazu belesen, Danke für den Hinweis. Diese runashighest und runasinvoker habe ich schon einmal gehört in Zusammenhang mit dem Erstellen von Ausnahmen für die UAC mit dem Application Compatibility Toolkit.
Es ist ja auch nur dieser Kopiervorgang dieser einen Datei. Das entspricht vielleicht 0,0001% vom Umfang der ganzen Anwendung. Da kann ich als Entwickler doch nur deswegen keine Administratorrechte verlangen. Mehr ist das ja nicht was ich nicht verstehe.
@Winary: Du sagst selbst, dass es funktioniert, sobald UAC deaktiviert ist. So ist es doch?Und wir haben jetzt schon mehrmals geschrieben, das "UAC deaktivieren" ungleich "Admin-Rechte vergeben ist". Die Benutzer haben keine Admin-Rechte, bloß weil UAC deaktiviert wird. Kapierst Du das?
Zitat von @Dilbert-MD:
Dann leg doch diese BAT-Datei auf den Desktop, stell die Programmfenstergröße so ein, dass an der Seite ein schmaler Streifen des Desktop (mit der BAT) sichtbar bleibt. So kann der Nutzer darauf klicken.
Alternativ: Link auf den Desktop zur Bat. Link-"Eigenschaften" mit Tastenkombination belegen (die nicht von dem Programm verwendet wird / abgefangen wird) , und schon kann der Nutzer mittels Tastenkombination - auch wenn das Programm aktiv ist - die BAT aufrufen.
Dann leg doch diese BAT-Datei auf den Desktop, stell die Programmfenstergröße so ein, dass an der Seite ein schmaler Streifen des Desktop (mit der BAT) sichtbar bleibt. So kann der Nutzer darauf klicken.
Alternativ: Link auf den Desktop zur Bat. Link-"Eigenschaften" mit Tastenkombination belegen (die nicht von dem Programm verwendet wird / abgefangen wird) , und schon kann der Nutzer mittels Tastenkombination - auch wenn das Programm aktiv ist - die BAT aufrufen.
Ich habe bereits die Batchdatei in einer Serverfreigabe liegen. Die Datei wird per GPP in jeden Dokumenteordner der Nutzer kopiert. Gleichzeitig wird eine Verknüpfung dahin auf dem Desktop erzeugt. Das mit der Tastenkombination werde ich noch einfügen; Danke für den Hinweis, gute Idee.
Zitat von @emeriks:
@Winary: Du sagst selbst, dass es funktioniert, sobald UAC deaktiviert ist. So ist es doch?
@Winary: Du sagst selbst, dass es funktioniert, sobald UAC deaktiviert ist. So ist es doch?
Ja, es geht wenn die UAC deaktiviert ist. Es gehen damit aber auch Anwendungen, die der Nutzer nicht starten/verändern darf/soll.
Und wir haben jetzt schon mehrmals geschrieben, das "UAC deaktivieren" ungleich "Admin-Rechte vergeben ist". Die Benutzer haben keine Admin-Rechte, bloß weil UAC deaktiviert wird. Kapierst Du das?
Dann meinen wir dasselbe, aber ich habe es falsch formuliert, indem ich die zwei unterschiedlichen Begrifflichkeiten zu einem Wort zusammengefasst habe. Sorry. Verstanden.
Es gehen damit aber auch Anwendungen, die der Nutzer nicht starten darf/soll.
Das kann man ganz einfach per GPO erledigen.Das weiß ich und liegt in der Urne mit den Zetteln, auf dem die möglichen Optionen stehen. Diesen Zettel will ich aber als letztes ziehen.
Wie gesagt möchte ich die UAC aktiviert lassen. Oder ist es so gang und gäbe, dass in einem Produktivbetrieb die UAC aus ist und über GPO (System-)Anwendungen beschränkt werden? Bisher hatte ich das noch nicht gesehen. Das wäre natürlich gut zu wissen wenn eher das Best Practice ist. Jeder macht das natürlich anders und wenn ich wegen dieser Kleinigkeit nun an meinem "Schema F" zweifeln muss, dann ist das ja nichts Schlimmes.
Denk doch mal nach:
Der "normale" Benutzer (99%) hat keine Admin-Rechte. UAC ist aber nur für Benutzer mit Admin-Rechten relevant.
Wenn Du also UAC deaktivierst, dann hat das auf 99% der Benutzer keine negativen Auswirkungen. Nur auf solche mit Admin-Rechten. Also z.B. Dich.
Edit. Und Du bist Admin für die Anwender, nicht umgekehrt.
Der "normale" Benutzer (99%) hat keine Admin-Rechte. UAC ist aber nur für Benutzer mit Admin-Rechten relevant.
Wenn Du also UAC deaktivierst, dann hat das auf 99% der Benutzer keine negativen Auswirkungen. Nur auf solche mit Admin-Rechten. Also z.B. Dich.
Edit. Und Du bist Admin für die Anwender, nicht umgekehrt.
UAC ist aber nur für Benutzer mit Admin-Rechten relevant.
Äh...bitte? UAC ist durch Datei- und Registryvirtualisierung weiterhin eine der wichtigsten Komponenten, wenn es um Kompatibilität von Legacy-Anwendungen geht. Und damit meine ich Komp. mit Benutzung durch Nichtadmins.
Ich habe mir jetzt nochmal diesen Artikel durchgelesen. http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richt ...
Ich möchte ja diesen Over-The-Shoulder"-Modus, nur eben nicht für diese copy.exe, da die UAC eigentlich nicht völlig unnötig greift. Der Entwickler hat sich offenbar auch nicht mit diesem Application Manifest Thema auseinandergesetzt.
Dann stimmt etwas mit der Umgebung nicht. Ohne UAC ist der normale Benutzer hier aber Admin, aber auch irgendwie nicht. Da muss ich nochmal nachschauen.
Das macht schon Sinn. aber wie gesagt verhalten sich die Domänenbenutzerkonten echt merkwürdig ohne UAC. Ich dächte ja auch, dass sie ohne Berechtigungen von Domänenseite oder von der lokalen Seite nichts administrativ machen dürften, aber es geht irgendwie.
Nach diesem Credo mache ich das auch nach aller Möglichkeit. Das eckenlose Nutzerelebnis ist mir aber dennoch wichtig.
Ich möchte ja diesen Over-The-Shoulder"-Modus, nur eben nicht für diese copy.exe, da die UAC eigentlich nicht völlig unnötig greift. Der Entwickler hat sich offenbar auch nicht mit diesem Application Manifest Thema auseinandergesetzt.
Zitat von @emeriks:
Der "normale" Benutzer (99%) hat keine Admin-Rechte. UAC ist aber nur für Benutzer mit Admin-Rechten relevant.
Der "normale" Benutzer (99%) hat keine Admin-Rechte. UAC ist aber nur für Benutzer mit Admin-Rechten relevant.
Dann stimmt etwas mit der Umgebung nicht. Ohne UAC ist der normale Benutzer hier aber Admin, aber auch irgendwie nicht. Da muss ich nochmal nachschauen.
Wenn Du also UAC deaktivierst, dann hat das auf 99% der Benutzer keine negativen Auswirkungen. Nur auf solche mit Admin-Rechten. Also z.B. Dich.
Das macht schon Sinn. aber wie gesagt verhalten sich die Domänenbenutzerkonten echt merkwürdig ohne UAC. Ich dächte ja auch, dass sie ohne Berechtigungen von Domänenseite oder von der lokalen Seite nichts administrativ machen dürften, aber es geht irgendwie.
Edit. Und Du bist Admin für die Anwender, nicht umgekehrt.
Nach diesem Credo mache ich das auch nach aller Möglichkeit. Das eckenlose Nutzerelebnis ist mir aber dennoch wichtig.
Äh...bitte? UAC ist durch Datei- und Registryvirtualisierung weiterhin eine der wichtigsten Komponenten, wenn es um Kompatibilität von Legacy-Anwendungen geht. Und damit meine ich Komp. mit Benutzung durch Nichtadmins.
Könntest Du das bitte erläutern?https://msdn.microsoft.com/en-us/library/windows/desktop/bb648649%28v=vs ...
Dort steht lediglich, dass UAC die automatische (ohne Nachfrage) oder halb-automatische (mit Nachfrage) Elevierung steuert. Wenn eine Anwendung Admin-Rechte anfordert (wie Due schon geschrieben hast: "runashighest" oder auch "requireAdministrator", "highestAvailable"), dann wird versucht, den Prozess "anzuheben". Wenn der Benutzer diese Rechte hat, dann kommt die Frage, ob er das zulassen will. Wenn er die Rechte nicht hat, dann kommt der Dialog zur Anmeldung mit einem Admin-Konto, auch wenn man nicht explizit "ausführen als" auswählt.
Mehr lese ich da nicht. Die Datei- und Registryvirtualisierung bezieht sich auch nur auf Schreibvorgänge der lokalen Administratoren.
Zitat:
Benutzerkontensteuerung: Datei- und Registrierungsschreibfehler an Einzelbenutzerorte virtualisieren
Mit dieser Richtlinieneinstellung wird gesteuert, ob Schreibfehler in Anwendungen in definierte Orte in der Registrierung und im Dateisystem umgeleitet werden. Mit der Richtlinieneinstellung werden Anwendungen aufgefangen, die unter dem Administratorkonto ausgeführt werden, und von denen Laufzeitanwendungsdaten in "%Programme%, %Windir%, %Windir%\system32" oder "HKLM\Software\..." geschrieben werden.
Mit dieser Richtlinieneinstellung wird gesteuert, ob Schreibfehler in Anwendungen in definierte Orte in der Registrierung und im Dateisystem umgeleitet werden. Mit der Richtlinieneinstellung werden Anwendungen aufgefangen, die unter dem Administratorkonto ausgeführt werden, und von denen Laufzeitanwendungsdaten in "%Programme%, %Windir%, %Windir%\system32" oder "HKLM\Software\..." geschrieben werden.
Oder meinst Du was anderes?
emeriks, "virtuals store" sagt Dir nichts? Schau mal rein auf Deinem Rechner unter %localappdata%\VirtualStore
Dahin werden Schreibzugriffe von Anwendungen umgeleitet (z.B. nach c:\windows oder c:\progfiles), die sonst fehlschlagen würden wegen mangelnder Rechte. Ohne UAC wwird nichts umgeleitet, sondern Zugriff verweigert, Resultat: Anwendung läuft nicht/nicht rund ohne Adminrechte. Das selbe gibt es auch für die Registry.
Dahin werden Schreibzugriffe von Anwendungen umgeleitet (z.B. nach c:\windows oder c:\progfiles), die sonst fehlschlagen würden wegen mangelnder Rechte. Ohne UAC wwird nichts umgeleitet, sondern Zugriff verweigert, Resultat: Anwendung läuft nicht/nicht rund ohne Adminrechte. Das selbe gibt es auch für die Registry.
PS: Was Du zitierst ist im Original
%localappdata%\VirtualStore\Program Files (x86)\irfanview liegt bei mir eine i_view32.ini
Hätte ich die UAC aus, würde die ini nicht zur Verfügung stehen, sie könnte nicht gespeichert werden (es sei denn, irfanview lässt Einstellungen für alternative Pfade zu).
Du siehst, MS hat seine eigenen Policies mangelhaft beschrieben.
User Account Control: Virtualize file and registry write failures to per-user locations | This policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software| • Enabled: (Default) Application write failures are redirected at run time to defined user locations for both the file system and registry.
Und damit ebenso falsch. Beispiel: ich habe keine Adminrechte an meinem PC. Irfanview habe ich ausgeführt und irfanview möchte eine ini-Datei ins Programmverzeichnis schreiben. Das würde misslingen, der virtual store wurde benutzt, unter%localappdata%\VirtualStore\Program Files (x86)\irfanview liegt bei mir eine i_view32.ini
Hätte ich die UAC aus, würde die ini nicht zur Verfügung stehen, sie könnte nicht gespeichert werden (es sei denn, irfanview lässt Einstellungen für alternative Pfade zu).
Du siehst, MS hat seine eigenen Policies mangelhaft beschrieben.
@dww
Danke für die Erläuterung! Ich werde mir das genauer anschauen.
Schönes WE!
Danke für die Erläuterung! Ich werde mir das genauer anschauen.
Schönes WE!
Ohne die anderen Antworten gelesen zu haben:
1. *.cmd (früher *.bat) Datei schreiben die deine Kopie erledigt.
2. Google "Bat to Exe Converter" (Link zeigt auf ein Ergebnis der Suche)
4. blöde copy.exe durch schöne copy.exe ersetzen.
What's the problem?
Viele Grüße
pelzfrucht
1. *.cmd (früher *.bat) Datei schreiben die deine Kopie erledigt.
2. Google "Bat to Exe Converter" (Link zeigt auf ein Ergebnis der Suche)
4. blöde copy.exe durch schöne copy.exe ersetzen.
What's the problem?
Viele Grüße
pelzfrucht
Interessanter Ansatz. Daran hatte ich auch nicht gedacht. Kommt mit in die vorhin genannte Urne
Danke dafür.
Moin,
das ist leider in verschiedenen Umfeldern so der standard.
Primär weil die Softwarefirmen nicht programmieren können oder wollen.
Ich habe hier mal den Auszug einer Software die recht weit am Markt bei Zahnärzten verbreitet ist.
1. Jeder Benutzer benötigt lokale Administratorrechte
2. UAC muss deaktiviert sein
3. Es darf kein Antivirusprogramm installiert sein
Warum
Viele Medzinische Programme kommunizieren über eine INI-Dateien die sich historisch in c:\Windows befinden und auch nicht verschieben lassen.
Zusätzlich verschiedene Word-Makros bei denen sich sicherheitstechnisch mir die Fußnägel aufrollen.
Bei den Zahnärzten benötigen ca. 90% der PCs lokale Administratorrechte.
Und nein, den Anbieter der Röntgensoftware kann man nicht wechseln. Außerdem sind die anderen nicht besser.
Stefan
das ist leider in verschiedenen Umfeldern so der standard.
Primär weil die Softwarefirmen nicht programmieren können oder wollen.
Ich habe hier mal den Auszug einer Software die recht weit am Markt bei Zahnärzten verbreitet ist.
1. Jeder Benutzer benötigt lokale Administratorrechte
2. UAC muss deaktiviert sein
3. Es darf kein Antivirusprogramm installiert sein
Warum
Viele Medzinische Programme kommunizieren über eine INI-Dateien die sich historisch in c:\Windows befinden und auch nicht verschieben lassen.
Zusätzlich verschiedene Word-Makros bei denen sich sicherheitstechnisch mir die Fußnägel aufrollen.
Bei den Zahnärzten benötigen ca. 90% der PCs lokale Administratorrechte.
Und nein, den Anbieter der Röntgensoftware kann man nicht wechseln. Außerdem sind die anderen nicht besser.
Stefan
Und damit ebenso falsch. Beispiel: ich habe keine Adminrechte an meinem PC. Irfanview habe ich ausgeführt und irfanview möchte eine ini-Datei ins Programmverzeichnis schreiben. Das würde misslingen, der virtual store wurde benutzt, unter
%localappdata%\VirtualStore\Program Files (x86)\irfanview liegt bei mir eine i_view32.ini
Hätte ich die UAC aus, würde die ini nicht zur Verfügung stehen, sie könnte nicht gespeichert werden (es sei denn, irfanview lässt Einstellungen für alternative Pfade zu).
@dww, ich habe das eben exakt so reproduzieren können. Danke nochmal für den Wink.%localappdata%\VirtualStore\Program Files (x86)\irfanview liegt bei mir eine i_view32.ini
Hätte ich die UAC aus, würde die ini nicht zur Verfügung stehen, sie könnte nicht gespeichert werden (es sei denn, irfanview lässt Einstellungen für alternative Pfade zu).
Jedoch: Kann es sein, dass sich das auf INI-Dateien beschränkt? Jedenfalls kann ich auf diese Weise z.B. keine TXT aus so einem Verzeichnis mit Notepad ändern und an selber Stelle abspeichern. Mir ist so in Erinnerung, als wenn MS für das Lesen und Speichern von INI extra API anbietet. Man kennt das ja schon aus dem TS-Umfeld, wo solche INI's früher schon im %homeshare%\Windows gelandet sind.
@DerWoWusste
Habe mich eben hier belesen: Understanding and Configuring User Account Control
Es ist tatsächlich, wie Du schreibst, aber es gibt auch Einschränkungen, wo das nicht greift. So z.B. bei x64-Anwendungen und bei solchen, welche eine Mainfest Datei haben, welche die Elevierung gezielt anfordern.
Habe mich eben hier belesen: Understanding and Configuring User Account Control
Es ist tatsächlich, wie Du schreibst, aber es gibt auch Einschränkungen, wo das nicht greift. So z.B. bei x64-Anwendungen und bei solchen, welche eine Mainfest Datei haben, welche die Elevierung gezielt anfordern.
