Ich habe gleich mehrere schwerwiegende Probleme mit Windows Vista bzw
Windows 7 und ihrer UAC Steuerung, weshalb ich die Unterstützung
echter Profis benötige. Für jegliche Hilfe wäre ich unglaublich
dankbar, da ich selbst nach tagelangem Googeln, experimentieren und in
Büchern schmökern nicht weiter gekommen bin.


UAC Hintergrund:
==================
Seit Vista gibt es die sogenannte UAC Steuerung. Auf einer lokalen
Maschine hat man selbst als Administrator auf bestimmte Pfade, z.B.
%ProgramFiles% keinen Schreibzugriff, da die explorer.exe mit Standard
Benutzer Privilegien gestartet wird. Man muss den Weg über den
SecureDesktop gehen. Wenn man Standard User ist, kommt beim
SecureDesktop aber noch die Eingabefelder für eine Benutzeranmeldung,
damit man die Möglichkeit hat, sich mit einem anderen Account
Adminrechte zu verschaffen. Ansonsten bleibt einem dieser Zugriff
verwehrt.


Mein Programm:
==================
Ich habe ein Programm, welches sich in %ProgramFiles% (Standard User:
keine Schreibrechte) installiert. Die Installation führt ein
Systemadmin durch. Damit das Programm regelmäßig aktualisiert werden
kann, prüft das Programm auf einem Netzwerkpfad, ob eine
AutoUpdate.exe vorhanden ist und führt diese dann aus. Es handelt sich
hierbei um eine Wise Setup-Routine.

Das Programm soll prüfen, ob der angemeldete User Schreibzugriff im
Installationsverzeichnis (%ProgramFiles%) hat und wenn nicht prüfen,
ob er mit dem derzeit angemeldeten Account sich über den SecureDesktop
die Rechte überhaupt aneignen kann. Ein normaler User soll nämlich
nicht die Meldung mit dem Secure Desktop und der Benutzeranmeldung
bekommen, sondern stattdessen nur eine Messagebox mit der Meldung,
dass ein Update vorhanden ist.

Allerdings soll der Admin in den Programmeinstellungen auch einen
Adminaccount (Domäne, Benutzername, Passwort) hinterlegen können,
welches bei Wunsch automatisch genutzt werden soll, wenn der User
nicht in der Lage ist, mit seinem eigenen Account höhere Adminrechte
anzufordern. Sprich: Standard Benutzer wird zum Adminbenutzer und
fordert dann mit SecureDesktop höhere Rechte an. Von all dem, außer
dem einmaligen Secure Desktop, soll der Benutzer nichts mit bekommen.
Ich hoffe, ich habe mich verständlich ausgedrückt. Ansonsten ruhig
fragen.


Probleme:
==================

Problem 1:
Ich prüfe mit folgendem Befehl, ob der User Admin ist:

public bool istAdmin { get { return new WindowsPrincipal
(WindowsIdentity.GetCurrent()).IsInRole
(WindowsBuiltInRole.Administrator); } private set { } }

Doch zeigt er mir nur True an, wenn ich per SecureDesktop höhere
Adminrechte anforderte. Selbst wenn ich als lokaler Admin angemeldet
bin, würde ohne Secure Desktop nur False zurück kommen. So kann ich
also nicht effektiv prüfen, ob einer in der Lage ist, sich höhere
Adminrechte anzufordern oder nicht. Weiß da jemand rat? Vor allem weiß
ich nicht genau, wie es sich mit UAC verhält, wenn der Benutzer ein
Admin von einer Domäne ist. Gibt es da sowas wie ein SecureDesktop
überhaupt? Wenn nicht, dann würde meine Routine ja funktionieren.
Jedoch nicht, wenn es sich um einen lokalen Benutzer handelt.

Problem 2:
Per WindowsImpersonation (Kernel32.dll, advapi32.dll und der
WindowsIdentity Klasse) schaffe ich es, die laufende Anwendung als
jemand anders laufen zu lassen. Doch kann ich mit dieser Person keine
höhere Adminrechte anfordern (Secure Desktop), so dass das Autoupdate
mit Schreibzugriff auf %ProgramFiles% gestartet werden kann. Kann mir
einer zeigen, wie ich effektiv ein Programm als jemand anders
(Anmeldedaten werden hinterlegt) mit erhöhten Adminrechten starten
kann, damit man Schreibrechte auf %ProgramFiles% erhält?


viele liebe Grüße

euer hoffnungslos verzweifelter Manuel

Hallo Michael,

langes Posting, ich versuche die Antworten
mal kurz zu halten:

1. Damit prüfst Du, ob Du effektiver Admin
bist, d.h. LinkedToken bzw. ElevatedToken:

[DllImport("advpack.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsNTAdmin(uint Reserved,
ref uint pReserved);

so rufst Du das mal auf (einmal als admin, einmal als non-admin:

uint Reserved = 0;
uint pReserved = 0;

MessageBox.Show(IsNTAdmin(Reserved,ref pReserved).ToString());

So startest Du ein Program (oder dich selber!) mit der Aufforderung
des UAC Dialogs:

//triggert den UAC Dialog, fordert für den neuen Prozess Admin
Rechte an
//und startet eine zweite instanz mit admin rechten wenn
bestätigt

ProcessStartInfo psi = new
ProcessStartInfo(Process.GetCurrentProcess().MainM odule.FileName);
psi.Verb = "runas"; //triggert den UAC Dialog

Process p = Process.Start(psi);

> Das Programm soll prüfen, ob der angemeldete User Schreibzugriff im
> Installationsverzeichnis (%ProgramFiles%) hat und wenn nicht prüfen,
> ob er mit dem derzeit angemeldeten Account sich über den SecureDesktop
> die Rechte überhaupt aneignen kann.

Zu dem Verzeichnis lesen können, d.h. ob ein benutzer darauf zugriff hat,
dazu schausst Du dir bitte mal diesen thread an, da ist auch ein gutes
beispiel:

http://www.developmentnow.com/g/36_2...ermissions.htm

> Allerdings soll der Admin in den Programmeinstellungen auch einen
> Adminaccount (Domäne, Benutzername, Passwort) hinterlegen können,
> welches bei Wunsch automatisch genutzt werden soll, wenn der User
> nicht in der Lage ist, mit seinem eigenen Account höhere Adminrechte
> anzufordern.

Einen Benutzer kannst Du nur als Admin anlegen, also als echter Admin
und das geht so, bzw. wird hier beschrieben, darunter einige Möglichekiten,
einige echt gute, wie Du das machen kannst (Kommentare unten lesen!):

http://www.thejackol.com/2004/08/03/...-account-cnet/


Das sollte Dir helfen,...

Grüße

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------

Hallo Michael,

> [...] Kann mir einer zeigen, wie ich effektiv ein Programm als
> jemand anders (Anmeldedaten werden hinterlegt) mit
> erhöhten Adminrechten starten kann, damit man
> Schreibrechte auf %ProgramFiles% erhält?

Diese Frage lässt "vermuten", dass nicht weisst,
dass bei Vista und höher %ProgramFiles%
virtaulisiert wird. Normal nach:
-> C:\Users\......\Appdata\Local\VirtualStore\Program Files

Ich vermute einen Konzept-Fehler, deswegen frage
ich Dich mal zunächst: "warum musst Du in Programm-
Files schreiben?".
Man hat standardmässig Verzeichnisse unterhalb
des UserProfile, wo diese Berechtigungen nicht
benötigt werden. Administrative Programmteile
handelt man oft beim Setup ab.

Dann könntest Du Dir auch das ganze Admin-
Zeug sparen, zumal Du noch wesentlich mehr
Sachen machen müsstest, als bereits gepostet wurde.

[Step 6: Create and Embed an Application Manifest (UAC)]
http://msdn.microsoft.com/en-us/library/bb756929.aspx

Best Practices wäre es auch, den administrativen
Teil möglichst kurz zu halten und nicht gleich die
ganze App administrativ laufen zu lassen:

[Code mit anderen Rechten ausführen]
http://dzaebel.net/LogonUser.htm

Aber schaun wir erstmal, ob Du sowas wirklich brauchst.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Hallo Michael,

> Problem 1:
> Ich prüfe mit folgendem Befehl, ob der User Admin ist:
>
> public bool istAdmin { get { return new WindowsPrincipal
> (WindowsIdentity.GetCurrent()).IsInRole
> (WindowsBuiltInRole.Administrator); } private set { } }
>
> Doch zeigt er mir nur True an, wenn ich per SecureDesktop höhere
> Adminrechte anforderte. Selbst wenn ich als lokaler Admin angemeldet
> bin, würde ohne Secure Desktop nur False zurück kommen. So kann ich
> also nicht effektiv prüfen, ob einer in der Lage ist, sich höhere
> Adminrechte anzufordern oder nicht. Weiß da jemand rat? Vor allem weiß
> ich nicht genau, wie es sich mit UAC verhält, wenn der Benutzer ein
> Admin von einer Domäne ist. Gibt es da sowas wie ein SecureDesktop
> überhaupt? Wenn nicht, dann würde meine Routine ja funktionieren.
> Jedoch nicht, wenn es sich um einen lokalen Benutzer handelt.
Den Secure Desktop gibt es für *alle*. Der einzige User, der nicht mit der
UAC behelligt wird ist der Administrator-Account der Domäne selbst. Hier
würde Deine Prüfung folglich "true" zurückliefern. Die Lösung für Dich
sollte das Application Manifest sein. Stichwort: "requestedPrivileges" /
"trustInfo". Hier solltest Du als Wert "highestAvailable" verwenden. Damit
erreichst Du, dass das Programm beim Start von der UAC automatisch
heraufgestuft wird, sofern machbar. Der normale User bleibt dabei im
normalen User Kontext, der Admin kommt automtisch auf den Secure Desktop. Es
sollte nicht nach einem User / Passwort gefragt werden. Anschließend
funktioniert auch Deine Prüfung und Du kannst die entsprechende Aktion
(Update / Message) ausführen lassen.

> Problem 2:
> Per WindowsImpersonation (Kernel32.dll, advapi32.dll und der
> WindowsIdentity Klasse) schaffe ich es, die laufende Anwendung als
> jemand anders laufen zu lassen. Doch kann ich mit dieser Person keine
> höhere Adminrechte anfordern (Secure Desktop), so dass das Autoupdate
> mit Schreibzugriff auf %ProgramFiles% gestartet werden kann. Kann mir
> einer zeigen, wie ich effektiv ein Programm als jemand anders
> (Anmeldedaten werden hinterlegt) mit erhöhten Adminrechten starten
> kann, damit man Schreibrechte auf %ProgramFiles% erhält?
Dies machst Du über die Process-Klasse. Hier kannst Du (ich meine in der
ProcessStartInfo) das RunAs-Verb hinteregen.

HTH

Sebastian

Danke für die vielen Antworten.

Ich arbeite jetzt mal alles nacheinander ab


* Kerem Gümrükcü

- Mit IsNTAdmin bekomme ich quasi das selbe gesagt, was ich bereits
mit meiner Methode herausgefunden erreiche.
Bin ich ein Domänenadmin, bekomme ich true. Bin ich nicht in einer
Domäne, aber lokaler Admin, bekomme ich false.

- Wie ich die Zugriffsrechte des aktuellen Users herausfinde, klappt
fabelhaft. Danke schön.

- mit Process.start hakt es noch bei mir.

Um einen Prozess mit einem anderen User Account zu starten, kann man
psi.Domain, psi.UserName und psi.Password übergeben. Doch muss dafür
der Wert psi.UseShellExecute auf false gestellt sein. Soweit klappt es
auch fabelhaft.

Um ein Prozess mit UAC Dialog zu starten, muss psi.Verb auf "runas"
und psi.UseShellExecute auf true gestellt werden. Auch dies klappt
einwandfrei.

Doch wie mache ich, wenn ich beides haben möchte? Beim einen muss
UseShellExecute false sein, beim anderen true. Ich bin jedoch drauf
angewiesen, dass der Prozess als jemand anderes mit UAC Dialog
aufgerufen wird.



*FrankDzaebel
Vielleicht habe ich mich ein wenig falsch ausgedrückt. Ich meine
damit, dass das Programm, wie es die Admins meistens wollen, in c:
\Programme(x86) bzw c:\Programme installiert wird. Und dort hat der
StandardUser keine Schreibrechte, selbst wenn er nicht in der Domäne
ist, sondern an einem lokalen PC.

Da die funktionalität des Programms durch Benutzer nicht beeinflusst
werden soll, ist die Sache mit dem Schreibschutz auch wünschenswert.
Doch muss das Projekt immer wieder aktualisiert werden, der Admin
möchte aber nicht jedesmal an den Rechner ran, sondern die Updates vom
StandardUser installieren lassen. Daher dieser komische Schritt von
mir, dass die AutoUpdates als ein anderer User (Account mit
Adminrechten) + UAC gestartet wird.


*Sebastian
Danke für deinen Hinweis. War wichtig für mich zu verstehen. Das mit
dem ApplicationManifest habe ich mir auch schon überlegt, doch wollte
ich nicht, dass das Hauptprogramm beim Admin immer mit Adminrechten
startet und er deshalb bei jedem Start diesen SecureDesktop bekommt.
Manche Kunden sind nämlich nicht in einer Domäne, sondern arbeiten
Lokal als Admin (was die meisten privaten User machen) mit dem
Programm.

Hallo Michael,

> Doch wie mache ich, wenn ich beides haben möchte? Beim einen muss
> UseShellExecute false sein, beim anderen true. Ich bin jedoch drauf
> angewiesen, dass der Prozess als jemand anderes mit UAC Dialog
> aufgerufen wird.

ich verstehe nicht, was das bringen soll,...mit den Lösungen
solltest Du doch alles abdecken können,...

Grüße

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------

On 6 Nov., 14:17, Kerem Gümrükcü <kareem...*hotmail.com> wrote:
> Hallo Michael,
>
> > Doch wie mache ich, wenn ich beides haben möchte? Beim einen muss
> > UseShellExecute false sein, beim anderen true. Ich bin jedoch drauf
> > angewiesen, dass der Prozess als jemand anderes mit UAC Dialog
> > aufgerufen wird.
>
> ich verstehe nicht, was das bringen soll,...mit den Lösungen
> solltest Du doch alles abdecken können,...
>
> Grüße
>
> Kerem
>
> --
> *-----------------------
> Beste Grüsse / Best regards / Votre bien devoue
> Kerem Gümrükcü
> Latest Project:http://www.pro-it-education.de/software/deviceremover
> Latest Open-Source Projects:http://entwicklung.junetz.de
> ----------------------- *



Wie ich schrieb ist beides über ProcessStartInfo nicht möglich, da der
Wert von UseShellExecute jeweils eins ausschließt. Wenn ich LogOnUser
verwende kann ich den aktuellen Prozess zwar als jemand anders
fortführen (der Prozess wird ja dabei nicht neu gestartet), aber
sobald ich dann aus diesem Prozess versuche, die autoupdate.exe mit
UAC Dialog aufzurufen, kommt eine mir kryptische Fehlermeldung.

Hallo,

>sobald ich dann aus diesem Prozess versuche, die autoupdate.exe mit
>UAC Dialog aufzurufen, kommt eine mir kryptische Fehlermeldung.

Und die wäre,...

Grüße

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------

Hallo Michael,

> Danke für deinen Hinweis. War wichtig für mich zu verstehen. Das mit
> dem ApplicationManifest habe ich mir auch schon überlegt, doch wollte
> ich nicht, dass das Hauptprogramm beim Admin immer mit Adminrechten
> startet und er deshalb bei jedem Start diesen SecureDesktop bekommt.
> Manche Kunden sind nämlich nicht in einer Domäne, sondern arbeiten
> Lokal als Admin (was die meisten privaten User machen) mit dem
> Programm.

Du kannst es - wie gesagt - auch über einen Self-Restart lösen, indem Du
einen Button mit dem elevated Shield belegst, der den Prozess nochmals mit
runAs-Verb startet (und ggf. eine entsprechende Kommandozeile übergibt). So
kannst Du im Voraus filtern, was als Aktion passieren soll. Kerem / Frank
schrieben ja auch bereits, dass dies auch der "normale Weg" ist, da nur die
entsprechenden und tatsächlich gewünschten Funktionen elevated ausgeführt
werden sollen. Die Anwendung läuft folglich erst einmal "asInvoker" und
startet dann die Update.exe entsprechend an, die heraufgestuft laufen soll?!

Eine andere (und eher die normale) Ausführungsweise ist ein Windows
Installer Paket. Hier sind die entsprechenden Funktionen ohnehin schon drin
und z.B. mit WIX lassen sich die Setups auch schön einfach bauen. Anstatt
nun Deine Update.exe zu starten, könntest Du auch ein MSP auf die
Installation anwenden lassen. Dies hätte den Vorteil, dass Du dies auch aus
dem Kontext des Users antriggern könntest. Um den Rest würde sich in diesem
Fall der Windows Installer kümmern.

Grüße

Sebastian

Hallo Michael,

ich antworte mal hier.

> Ich meine damit, dass das Programm, wie es die Admins
> meistens wollen, in c:\Programme(x86) bzw c:\Programme installiert wird.
> Und dort hat der StandardUser keine Schreibrechte, selbst wenn er
> nicht in der Domäne ist, sondern an einem lokalen PC.

$*%&§!
geh mal in Gedanken durch, wie sich das anfühlt, wenn
man genau das, was ich hier in der Gruppe bestimmt schon 100
Mal gepostet hat, jemand anderer Dir zu beschreiben versucht.
Nein - ich bleibe ruhig ;-)

Trotzdem nochmal, da Du auch keinen Bezug genommen hast:
sei Dir klar darüber, dass das Verzeichnis virtualisiert wird mit
all den Folgen, die dann beim Schreiben auftreten können.

[Häufige Probleme mit der Datei- und Registrierungsvirtualisierung in
Windows Vista]
http://support.microsoft.com/kb/927387

Schau Dir da ggf. ClickOnce oder andere Architektur-Pattern an:

[Übersicht über die ClickOnce-Bereitstellung]
http://msdn.microsoft.com/de-de/library/142dbbz4.aspx

[Microsoft Application Architecture Guide, 2nd Edition]
http://msdn.microsoft.com/en-us/library/dd673617.aspx

Wenn Du trotz allem da hereinschreiben willst, ... lade Dir mal folgendes
herunter:

[Download details: Windows Vista UAC Demo Sample Code]
http://www.microsoft.com/downloads/d...playlang=en&tm

dort das "RunElevatedCommand" Projekt als Startprojekt
einstellen und ins Command "services.msc" eingibst (also nur
für Admins). Dort siehst Du auch, wie man die Shields an die
Buttons bekommt (best practice). Und schau Dir meine Artikel
bezüglich der Manifeste nochmal in Ruhe an.

[Step 6: Create and Embed an Application Manifest (UAC)]
http://msdn.microsoft.com/en-us/library/bb756929.aspx

Ansonsten geh auch mal ins Beispiel:

[UAC-Beispiel]
http://msdn.microsoft.com/de-de/library/aa970890.aspx

Die VistBridgeLibrary kann u.a. hier erstellt werden:

[Vista Bridge-Beispiele]
http://msdn.microsoft.com/de-de/library/ms756482.aspx

Da wird auch ins %ProgramFiles% Verzeichnis geschrieben .... ;-)

Ein paar Dinge (wie Shield-Handling) ist für Windows 7 auch hier:

[Windows® API Code Pack for Microsoft® .NET Framework - Home]
http://code.msdn.microsoft.com/WindowsAPICodePack


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET