![]() |
|
|||||||
| Newsgroup microsoft.public.de.german.entwickler.dotnet.csharp Forum microsoft.public.de.german.entwickler.dotnet.csharp |
![]() |
|
|
Themen-Optionen | Ansicht |
|
#1
|
|||
|
|||
|
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 |
|
|
||||
|
||||
|
|
|
#2
|
|||
|
|||
|
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 ----------------------- |
|
#3
|
|||
|
|||
|
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 |
|
#4
|
|||
|
|||
|
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 |
|
#5
|
|||
|
|||
|
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. |
|
#6
|
|||
|
|||
|
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 ----------------------- |
|
#7
|
|||
|
|||
|
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. |
|
#8
|
|||
|
|||
|
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 ----------------------- |
|
#9
|
|||
|
|||
|
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 |
|
#10
|
|||
|
|||
|
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 |
|
|
|
|
![]() |
| Themen-Optionen | |
| Ansicht | |
|
|
Ähnliche Themen
|
||||
| Thema | Erstellt von | Forum | Antworten | Letzter Beitrag |
| [S] Hilfe im Umgang mit Raw | Andreas Gugau | Newsgroup de.rec.fotografie | 36 | 09-17-2009 01:11 PM |
| Umgang mit Unsicherheit | marmorkuchen@mailinator.com | Newsgroup de.talk.romance | 1224 | 03-13-2009 02:22 PM |
| Umgang mit Heckenstreitigkeit | Ralf Heiter | Newsgroup de.soc.recht.wohnen | 13 | 08-06-2008 05:55 AM |
| Der Umgang miteinander | wegzeiger | Newsgroup de.soc.weltanschauung.christentum | 2 | 03-03-2008 07:24 PM |
| umgang mit triebwerksausfall | Ralf Handel | Newsgroup de.rec.luftfahrt | 74 | 10-21-2007 08:37 AM |