none
Userrechte (Windows7) RRS feed

  • Frage

  • Hallo

    Also ich will da gar kein Geheimnis daraus machen, ich musste mich bisher nicht so wirklich viel mit den Userrechten beschäftigen, weil ich es einfach nicht brauchte. Weil die meisten Rechner liefen hier noch mit Windows XP, oder aber die Anwendungen haben keine Rechte gebraucht. Nun haben auch hier die Rechner einen Aufschwung und die Userrechte spielen eine Rolle. So habe ich jetzt eine Anwendung, die ihre Daten alle im Anwendungsverzeichnis haben soll und welche sich selber Updaten kann.

    Das habe ich auch schon hin bekommen, dank ClickOnce geht das (scheinbar) wunderbar (Noch nicht Live gegangen).

    Nun kommt aber ein winzig kleines eigentlich „unwichtiges“ Feature, was scheinbar Adminrechte braucht, um zu funktionieren!?

    Also habe ich meine Manifestdatei so geändert, dass der User halt die Adminrechte bestätigen muss. So weit so gut. Nur ist das wirklich so, dass er das bei jedem Aufruf machen muss!? Das ist doch ein wenig nervig auf Dauer!? Kann man das nicht so schreiben, dass der User ein Mal für die Anwendung die Rechte frei gibt und dann merkt sich Windows das!?

    Das wäre halt meine erste Frage und Ansatz. In Anbetracht dessen, dass man natürlich vermeiden sollte, dass ein Programm Adminrechte braucht, ist der zweite Ansatz, ob ich die für das was ich bewirken will wirklich brauche.

    Mein Ziel in diesem Fall ist es, eine Autostartfunktion über Registryeintrag  zu implementieren. Was auch schon geschehen ist und am Entwicklungsrechner als Release und ohne Debuggen auch wunderbar funktioniert. Nur halt dann auf anderen Rechnern nicht. Dann kommt halt die berühmte UnauthorizedAccessException!

    Hierzu sei angemerkt, dass ich auf Wintows7 64Bit mit VS 2008 und Framework 3.5 entwickle und auf 32 Bit erstelle. Einfach halt aus dem Grund, die Anwendung soll auch auf den XP Rechnern laufen. Mir ist auch klar, ich könnte einfach den Aufruf als Verknüpfung in Autostart schmeißen, aber das möchte ich so wenn möglich vermeiden.

    Die Frage wäre also kann ich ohne Adminrechte einen Autostarteintrag vornehmen!? Dass ist ja nun eigentlich eine normale (alltägliche) Funktionalität die an sich keine Adminrechte benötigen sollte.

    Wie immer schon jetzt vielen Dank für jegliche Hilfe.

    LG
    Christian

    Montag, 14. Januar 2013 09:31

Antworten

  • Die Frage wäre also kann ich ohne Adminrechte einen Autostarteintrag vornehmen!?

    Hallo Christian,

    Die kurze Antwort lautet: Nein.

    An und für sich gibt es recht viele Arten, eine Anwendung automatisch starten zu lassen. Wenn wir jedoch nur ausführbare .NET-Assemblies berücksichtigen, bleiben vor allem:

    1. Autostart/Startup-Verzeichnis des aktuellen Benutzers / aller Benutzer
    2. Run-Registrierungsschlüssel (HKLM oder HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run oder RunOnce)
    3. Active-Setup-Schlüssel (HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components)
    4. Windows NT-Dienste die für die Ausführung beim Systemstart konfiguriert sind
    5. Geplante Aufgaben / Scheduled Tasks (Windows Task Scheduler, Boot- oder Logon-Tasks)

    Den ersten Punkt wolltest Du nicht haben, warum auch immer. Der zweite und dritte Punkt scheitern an der erwähnten UnauthorizedAccessException, da die Berechtigung für den schreibenden Registrierungs-Zugriff fehlt. Zudem wird bei jedem Zugriff überprüft, in welchem Logon-Kontext die Anwendung ausgeführt wird. Punkt vier wäre zwar eine Möglichkeit, da man angeben kann unter welchem Konto der Dienst ausgeführt werden soll, aber ich halte das für Overkill. Bleibt Punkt fünf: die Einplanung eines Windows-Tasks mit den erforderlichen Credentials (diese werden meines Wissens nach auch entspr. gecacht). Zu diesem Zweck könnte man im Code z.B. den Task Scheduler Manager Wrapper einsetzen.

    Gruß
    Marcel

    Montag, 14. Januar 2013 15:24
    Moderator
  • Hallo Christian,

    > Ich verstehe allerdings nicht wie das dann andere Programme machen, ohne Adminrechte.

    Kannst Du mir bitte eine Anwendung nennen, die das unter Windows 7 kann?

    > Punkt 5 gebe ich dir Recht, dass ist mit Kanonen auf Spatzen oder so.

    Ich meinte Punkt 4 nicht Punkt 5, wo das Problem mit wenigen Zeilen Code erledigt ist. Aber auch bei Punkt 5 brauchst Du beim ersten Mal erhöhte Rechte, um den Task/die Aufgabe überhaupt einplanen zu können.

    > Wenn ich das richtig sehe, werde ich wohl auf eine Verknüpfung im Autostart umbauen müssen. Gibt es dafür einen Automatismus in .Net?

    Nur über ein Setup-Projekt in Visual Studio bzw. über den  Setup-Designer. Dort erstellt man eine Verknüpfung zur gewünschten ausführbaren Datei, fügt im Dateisystem-Designer (rechte Maustaste > speziellen Ordner hinzufügen > Startordner des Benutzers) den Startordner hinzu, und zieht die Verknüpfung in diesen Ordner.

    > War halt noch die Frage, ob man die Adminrechte auch so anlegen kann, dass man sie nur ein Mal bestätigen muss. Aber ich denke das wird wohl nicht gehen.

    Nein, das geht nicht. Das würde Übeltätern Tür und Tor öffnen. Eines der wichtigsten Sicherheitsprinzipien in Windows ist das Prinzip der geringsten Rechte (least privilege). Auch wenn man unter Windows 7 als Administrator angemeldet ist, arbeitet man nach der Anmeldung zunächst nicht mit dem vollen Administrator-Token, sondern mit einem gefilterten Token und ist somit ein Standardbenutzer.

    Erst beim Zugriff auf schutzwürdige Ressourcen greift UAC ein und fordert zur Eingabe der Admin-Credentials auf. Dann wird der zu startende Prozess mit dem vollen Administratortoken ausgeführt und der neue Sicherheitskontext erlaubt den Zugriff auf die geschützte (lokale) Ressource.

    Wie andere Programme Autostart-Einträge dann erstellen? 

    Wenn der Autostart über die Registry erfolgt, dann ist es meist ein MSI-Paket das während der Installation über die elevierte msiexec.exe eine Befehlszeile in die Registrierung schreibt.

    Die Anwendung auf welche die Befehlszeile verweist, darf aber selbst nicht auf UAC-geschützte Ressourcen zugreifen. Sobald sie das tut, erscheint unweigerlich der UAC-Prompt (wegen des gefilterten Tokens). 

    Einzige Ausnahme: Wenn die Anwendung über kein Anwendungsmanifest verfügt, wird die Virtualisierung eingeschaltet und der UAC-Prompt erscheint nicht. Allerdings hilft dir das nicht weiter in Sachen Registry, denn Du würdest trotzdem eine SecurityException bekommen, weil der Standardbenutzer in Windows 7 eben keine Schreibrechte auf die \Run-Keys hat, nichteinmal unter HKCU. Sieh dir doch mal in regedit.exe die Eigenschaften des Run-Schlüssels an und Du wirst dort vermutlich das Objekt "EINGESCHRÄNKTER ZUGRIFF" finden, dem wir die fehlenden Schreibrechte des Standardbenutzers verdanken.

    Um es nochmals deutlich zu sagen: Man braucht den vollen Administrator-Token, um über den Registryschlüssel Run oder RunOnce eine Anwendung als Autostartanwendung zu definieren.

    Und wenn Du dran denkst, die Elevierung so zu machen:

    ProcessStartInfo startInfo = new ProcessStartInfo();
    startInfo.UseShellExecute = true;
    startInfo.WorkingDirectory = Environment.CurrentDirectory;
    startInfo.FileName = pathToExe;
    startInfo.Verb = "runas";
    try
    {
       Process.Start(startInfo);
    }
    catch
    {
       // Benutzer hat UAC verweigert
    return;
    }

    dann wird das nur funktionieren, wenn der aktuelle Benutzer z.Z. bereits einen gefilterten Administrator-Token hat. 

    Wird die Anwendung aber über ein Standardbenutzerkonto ausgeführt, würde der Code von oben nicht mehr funktionieren, da bei Process.Start() mit Benutzerkonto-Anmeldung schon mal ShellExecute auf false stehen muss.

    Gut, versuchen wir dann aus dem vom Standardbenutzer ausgeführten Code einen Prozess mit Administrator-Rechten abzuspalten:

    using System;
    using System.Diagnostics;
    using System.Security;
    using System.IO;
    // Diese Anwendung wird von einem Standardbenutzer ausgeführt, unter:
    // C:\Users\[Standard User]\Desktop\ConsoleApplication2.exe
    // Die Anwendung versucht ein Prozess abzuspalten, um sich mittels
    // valider Credentials Admin-Berechtigungen zu verschaffen.
    namespace ConsoleApplication2
    {
        class Program
        {
            static void Main(string[] args)
            {
                var exeToStart = @"C:\Users\[Standard User]\Desktop\ConsoleApplication1.exe";
                var userName = "[Admin-Konto]";
                
                SecureString adminPassword = new SecureString();
                Console.Write("Passwort für {0}: ", userName);
                var keyInfo = Console.ReadKey(true);
                while (keyInfo.Key != ConsoleKey.Enter)
                {
                    adminPassword.AppendChar(keyInfo.KeyChar);
                    Console.Write('*');
                    keyInfo = Console.ReadKey(true);
                }
                adminPassword.MakeReadOnly();
                ProcessStartInfo startInfo = new ProcessStartInfo();
                startInfo.WorkingDirectory = Path.GetDirectoryName(exeToStart);
                startInfo.UserName = userName; 
                startInfo.Password = adminPassword;
                startInfo.LoadUserProfile = true;
                startInfo.FileName = exeToStart;
                // Damit es möglich ist einen Prozess als Benutzer zu starten
                // muss die UseShellExecute-Eigenschaft auf false festgelegt werden.
                startInfo.UseShellExecute = false;
                // "runas" funktioniert hier nicht mehr, u.a. wegen UseShellExecute = false
                // Details: http://tinyurl.com/b4xardz
                startInfo.Verb = "runas"; 
                try
                {
                    Process.Start(startInfo);
                }
                catch(Exception ex)
                {
                    Console.WriteLine(ex);
                }
                Console.ReadKey(true);
            }
        }
    }

    Und das Ergebnis? Obwohl wir doch soeben den Namen des Administrators und sein Passwort im Code eingegeben haben (bitte nicht im Produktionscode nachmachen!) und der Prozess erstellt wurde, erhalten wir folgende Ausnahme:

    System.ComponentModel.Win32Exception (0x80004
    005): Der angeforderte Vorgang erfordert erhöhte Rechte
    Die Anmeldung als Administrator hat funktioniert, wir haben einen gefilterten Admin-Token, nur dummerweise kann die Elevierung nicht erfolgen, da wir UseShellExecute = false setzen mussten.

     

    Nun. Ich will nicht verschweigen, dass es dennoch eine Lösung gibt: Sie steht im Blog von Chris Jackson und sieht konzeptuell so aus:
    Anwendung A -> CreateProcessWithLogonW -> Bootstrapper (asInvoker) -> Application B (requireAdministrator).

    Aber ... ich würde dringend davon abraten. Wenn man mal von der Mühe der Implementierung absieht, müsste man doch die Credentials vom Benutzer irgendwie erfragen und dann evtl. auch noch für spätere Verwendung cachen (um sie ggf. an CreateProcessWithLogonW weiterzugeben). Das wäre ein großes Sicherheitsrisiko.

    Ein allgemeiner Hinweis noch: Du könntest über das Microsoft Application Compatibility Toolkit 5.6 überprüfen, ob deine Anwendung überhaupt schon bereit für Windows 7 ist, bzw. herausfinden wo es noch hapert. Aber sei gewarnt dass alles seine Zeit braucht: Installation, Einlesen in die Dokumentation, Auslagern der Funktionalität welche elevierte Rechte braucht, digitale Signatur etc.

    Gruß
    Marcel

    Dienstag, 15. Januar 2013 13:33
    Moderator

Alle Antworten

  • Die Frage wäre also kann ich ohne Adminrechte einen Autostarteintrag vornehmen!?

    Hallo Christian,

    Die kurze Antwort lautet: Nein.

    An und für sich gibt es recht viele Arten, eine Anwendung automatisch starten zu lassen. Wenn wir jedoch nur ausführbare .NET-Assemblies berücksichtigen, bleiben vor allem:

    1. Autostart/Startup-Verzeichnis des aktuellen Benutzers / aller Benutzer
    2. Run-Registrierungsschlüssel (HKLM oder HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run oder RunOnce)
    3. Active-Setup-Schlüssel (HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components)
    4. Windows NT-Dienste die für die Ausführung beim Systemstart konfiguriert sind
    5. Geplante Aufgaben / Scheduled Tasks (Windows Task Scheduler, Boot- oder Logon-Tasks)

    Den ersten Punkt wolltest Du nicht haben, warum auch immer. Der zweite und dritte Punkt scheitern an der erwähnten UnauthorizedAccessException, da die Berechtigung für den schreibenden Registrierungs-Zugriff fehlt. Zudem wird bei jedem Zugriff überprüft, in welchem Logon-Kontext die Anwendung ausgeführt wird. Punkt vier wäre zwar eine Möglichkeit, da man angeben kann unter welchem Konto der Dienst ausgeführt werden soll, aber ich halte das für Overkill. Bleibt Punkt fünf: die Einplanung eines Windows-Tasks mit den erforderlichen Credentials (diese werden meines Wissens nach auch entspr. gecacht). Zu diesem Zweck könnte man im Code z.B. den Task Scheduler Manager Wrapper einsetzen.

    Gruß
    Marcel

    Montag, 14. Januar 2013 15:24
    Moderator
  • Hallo Marcel

    Danke für deine (wiedermal) ausführliche und tolle Antwort.
    Das gibt mir einen guten Überblick.

    Wenn ich das richtig sehe, werde ich wohl auf eine Verknüpfung im Autostart umbauen müssen.
    (Gibt es dafür einen Automatismus in .Net, oder muss ich "einfach" selber eine Verknüpfung erstellen und dann in das Verzeichnis speichern!?)
    Punkt 5 gebe ich dir Recht, dass ist mit Kanonen auf Spatzen oder so.

    Ich verstehe allerdings nicht wie das dann andere Programme machen, ohne Adminrechte.
    Weil es ist ja keine Seltenheit, dass Programme so was anbieten. Nur Adminrechte brauchte ich dafür noch nicht jedes mal bestätigen. (Und die haben keine Verknüpfung im Autostartordner. Und ich kann die Einträge über z.B. MSCONFIG sehen.)

    War halt noch die Frage, ob man die Adminrechte auch so anlegen kann, dass man sie nur ein Mal bestätigen muss. Aber ich denke das wird wohl nicht gehen.

    Danke und lg
    Christian

    Dienstag, 15. Januar 2013 07:47
  • Hallo Christian,

    > Ich verstehe allerdings nicht wie das dann andere Programme machen, ohne Adminrechte.

    Kannst Du mir bitte eine Anwendung nennen, die das unter Windows 7 kann?

    > Punkt 5 gebe ich dir Recht, dass ist mit Kanonen auf Spatzen oder so.

    Ich meinte Punkt 4 nicht Punkt 5, wo das Problem mit wenigen Zeilen Code erledigt ist. Aber auch bei Punkt 5 brauchst Du beim ersten Mal erhöhte Rechte, um den Task/die Aufgabe überhaupt einplanen zu können.

    > Wenn ich das richtig sehe, werde ich wohl auf eine Verknüpfung im Autostart umbauen müssen. Gibt es dafür einen Automatismus in .Net?

    Nur über ein Setup-Projekt in Visual Studio bzw. über den  Setup-Designer. Dort erstellt man eine Verknüpfung zur gewünschten ausführbaren Datei, fügt im Dateisystem-Designer (rechte Maustaste > speziellen Ordner hinzufügen > Startordner des Benutzers) den Startordner hinzu, und zieht die Verknüpfung in diesen Ordner.

    > War halt noch die Frage, ob man die Adminrechte auch so anlegen kann, dass man sie nur ein Mal bestätigen muss. Aber ich denke das wird wohl nicht gehen.

    Nein, das geht nicht. Das würde Übeltätern Tür und Tor öffnen. Eines der wichtigsten Sicherheitsprinzipien in Windows ist das Prinzip der geringsten Rechte (least privilege). Auch wenn man unter Windows 7 als Administrator angemeldet ist, arbeitet man nach der Anmeldung zunächst nicht mit dem vollen Administrator-Token, sondern mit einem gefilterten Token und ist somit ein Standardbenutzer.

    Erst beim Zugriff auf schutzwürdige Ressourcen greift UAC ein und fordert zur Eingabe der Admin-Credentials auf. Dann wird der zu startende Prozess mit dem vollen Administratortoken ausgeführt und der neue Sicherheitskontext erlaubt den Zugriff auf die geschützte (lokale) Ressource.

    Wie andere Programme Autostart-Einträge dann erstellen? 

    Wenn der Autostart über die Registry erfolgt, dann ist es meist ein MSI-Paket das während der Installation über die elevierte msiexec.exe eine Befehlszeile in die Registrierung schreibt.

    Die Anwendung auf welche die Befehlszeile verweist, darf aber selbst nicht auf UAC-geschützte Ressourcen zugreifen. Sobald sie das tut, erscheint unweigerlich der UAC-Prompt (wegen des gefilterten Tokens). 

    Einzige Ausnahme: Wenn die Anwendung über kein Anwendungsmanifest verfügt, wird die Virtualisierung eingeschaltet und der UAC-Prompt erscheint nicht. Allerdings hilft dir das nicht weiter in Sachen Registry, denn Du würdest trotzdem eine SecurityException bekommen, weil der Standardbenutzer in Windows 7 eben keine Schreibrechte auf die \Run-Keys hat, nichteinmal unter HKCU. Sieh dir doch mal in regedit.exe die Eigenschaften des Run-Schlüssels an und Du wirst dort vermutlich das Objekt "EINGESCHRÄNKTER ZUGRIFF" finden, dem wir die fehlenden Schreibrechte des Standardbenutzers verdanken.

    Um es nochmals deutlich zu sagen: Man braucht den vollen Administrator-Token, um über den Registryschlüssel Run oder RunOnce eine Anwendung als Autostartanwendung zu definieren.

    Und wenn Du dran denkst, die Elevierung so zu machen:

    ProcessStartInfo startInfo = new ProcessStartInfo();
    startInfo.UseShellExecute = true;
    startInfo.WorkingDirectory = Environment.CurrentDirectory;
    startInfo.FileName = pathToExe;
    startInfo.Verb = "runas";
    try
    {
       Process.Start(startInfo);
    }
    catch
    {
       // Benutzer hat UAC verweigert
    return;
    }

    dann wird das nur funktionieren, wenn der aktuelle Benutzer z.Z. bereits einen gefilterten Administrator-Token hat. 

    Wird die Anwendung aber über ein Standardbenutzerkonto ausgeführt, würde der Code von oben nicht mehr funktionieren, da bei Process.Start() mit Benutzerkonto-Anmeldung schon mal ShellExecute auf false stehen muss.

    Gut, versuchen wir dann aus dem vom Standardbenutzer ausgeführten Code einen Prozess mit Administrator-Rechten abzuspalten:

    using System;
    using System.Diagnostics;
    using System.Security;
    using System.IO;
    // Diese Anwendung wird von einem Standardbenutzer ausgeführt, unter:
    // C:\Users\[Standard User]\Desktop\ConsoleApplication2.exe
    // Die Anwendung versucht ein Prozess abzuspalten, um sich mittels
    // valider Credentials Admin-Berechtigungen zu verschaffen.
    namespace ConsoleApplication2
    {
        class Program
        {
            static void Main(string[] args)
            {
                var exeToStart = @"C:\Users\[Standard User]\Desktop\ConsoleApplication1.exe";
                var userName = "[Admin-Konto]";
                
                SecureString adminPassword = new SecureString();
                Console.Write("Passwort für {0}: ", userName);
                var keyInfo = Console.ReadKey(true);
                while (keyInfo.Key != ConsoleKey.Enter)
                {
                    adminPassword.AppendChar(keyInfo.KeyChar);
                    Console.Write('*');
                    keyInfo = Console.ReadKey(true);
                }
                adminPassword.MakeReadOnly();
                ProcessStartInfo startInfo = new ProcessStartInfo();
                startInfo.WorkingDirectory = Path.GetDirectoryName(exeToStart);
                startInfo.UserName = userName; 
                startInfo.Password = adminPassword;
                startInfo.LoadUserProfile = true;
                startInfo.FileName = exeToStart;
                // Damit es möglich ist einen Prozess als Benutzer zu starten
                // muss die UseShellExecute-Eigenschaft auf false festgelegt werden.
                startInfo.UseShellExecute = false;
                // "runas" funktioniert hier nicht mehr, u.a. wegen UseShellExecute = false
                // Details: http://tinyurl.com/b4xardz
                startInfo.Verb = "runas"; 
                try
                {
                    Process.Start(startInfo);
                }
                catch(Exception ex)
                {
                    Console.WriteLine(ex);
                }
                Console.ReadKey(true);
            }
        }
    }

    Und das Ergebnis? Obwohl wir doch soeben den Namen des Administrators und sein Passwort im Code eingegeben haben (bitte nicht im Produktionscode nachmachen!) und der Prozess erstellt wurde, erhalten wir folgende Ausnahme:

    System.ComponentModel.Win32Exception (0x80004
    005): Der angeforderte Vorgang erfordert erhöhte Rechte
    Die Anmeldung als Administrator hat funktioniert, wir haben einen gefilterten Admin-Token, nur dummerweise kann die Elevierung nicht erfolgen, da wir UseShellExecute = false setzen mussten.

     

    Nun. Ich will nicht verschweigen, dass es dennoch eine Lösung gibt: Sie steht im Blog von Chris Jackson und sieht konzeptuell so aus:
    Anwendung A -> CreateProcessWithLogonW -> Bootstrapper (asInvoker) -> Application B (requireAdministrator).

    Aber ... ich würde dringend davon abraten. Wenn man mal von der Mühe der Implementierung absieht, müsste man doch die Credentials vom Benutzer irgendwie erfragen und dann evtl. auch noch für spätere Verwendung cachen (um sie ggf. an CreateProcessWithLogonW weiterzugeben). Das wäre ein großes Sicherheitsrisiko.

    Ein allgemeiner Hinweis noch: Du könntest über das Microsoft Application Compatibility Toolkit 5.6 überprüfen, ob deine Anwendung überhaupt schon bereit für Windows 7 ist, bzw. herausfinden wo es noch hapert. Aber sei gewarnt dass alles seine Zeit braucht: Installation, Einlesen in die Dokumentation, Auslagern der Funktionalität welche elevierte Rechte braucht, digitale Signatur etc.

    Gruß
    Marcel

    Dienstag, 15. Januar 2013 13:33
    Moderator
  • Hallo Marcel

    Danke für diese Einführung ins Sicherheitsprinzip von Windows.

    Die Anwendungen die ich da im Auge hatte, werden dass dann wohl wie von dir beschrieben über die Installation machen und dann zur Laufzeit über die msiexec.exe.

    Muss ja irgend wie so gehen, nur das ist für das Projekt hier und für das kleine Feature dann doch zu viel.

    Da werde ich doch lieber die Autostartordner Variante nehmen, oder eine weitere Exe schreiben
    die dann aufgerufen wird und explizit die Rechte Anfordert um dann den Eintrag zu machen, oder zu löschen.

    Muss mir das mal für mich selber überlegen und dann auch mal bei uns hier besprechen.

    Habe vielen Dank und lg
    Christian

    Mittwoch, 16. Januar 2013 07:50
  • Hallo Christian,

    Gern geschehen.

    Die Autostartordner-Variante ist in diesem Fall vom Ökonomischen her recht passabel. Du wirst aber unter Windows 7 mit einer asInvoker-Anwendung gegen die gleiche UnauthorizedAccessException-Mauer rennen, auch wenn der Benutzer grundsätzlich über Schreibrechte auf ACL-Ebene im SpecialFolders.Startup / SpecialFolders.CommonStartup-Ordner verfügt. UAC läßt grüßen.

    Die Idee, deine Anwendung in zwei Teile aufzuteilen (eine die im app.manifest ein ExecutionLevel von asInvoker hat, die andere, die requireAdministrator verwendet) entspricht dem empfohlenen Standardvorgehen bei UAC-aktivierten Anwendungen. Sie setzt aber voraus, dass der Benutzer (der ja ggf. nur Standardbenutzer ist) entweder (auch) zur Gruppe der Administratoren gehört oder über die nötigen Administrator-Credentials verfügt, um die UAC-Consent-Aufforderung positiv zu bescheiden.

    Wenn sich der Benutzer jedoch entscheidet, oder entscheiden muss, im Benutzerkontensteuerungs-Dialog die Elevierung abzulehnen, wird der nachgeordnete Code, der die elevierten Berechtigungen benötigt, fehlschlagen.

    Gruß

    Marcel


    Donnerstag, 17. Januar 2013 10:02
    Moderator