Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Adminrechte für eine Prozedur (https://www.delphipraxis.net/187050-adminrechte-fuer-eine-prozedur.html)

Captnemo 23. Okt 2015 11:12

Adminrechte für eine Prozedur
 
HI,

ich möchte in einem Programm 2 Registry-Schlüssel erstellen. Einen in HKEY_LOCAL_MACHINE und einen in HKEY_CURRENT_USER.
Für den in HKLM macht mir die UAC ein Strich durch die Rechnung, wenn ich das Programm "normal" starte. Den Schlüssel kann ich nur erstellen, wenn ich das Programm explizit mit Adminrechten starte. Dann aber kann ich auf den entsprechenden HKCU nicht zugreifen, weil das Programm dann unter einem anderen Benutzerkontext läuft.

Gibt es die Möglichkeit sich innerhalb des Programm's die Adminrechte vom Betriebssystem anzufordern und später wieder abzugeben?

Zacherl 23. Okt 2015 11:32

AW: Adminrechte für eine Prozedur
 
Zitat:

Zitat von Captnemo (Beitrag 1319539)
Dann aber kann ich auf den entsprechenden HKCU nicht zugreifen, weil das Programm dann unter einem anderen Benutzerkontext läuft.

:shock: Das sollte nicht der Fall sein. Oder ist dein Benutzer kein Admin und du startest den Prozess tatsächlich mit anderen Credentials?

Bernhard Geyer 23. Okt 2015 13:22

AW: Adminrechte für eine Prozedur
 
Zitat:

Zitat von Zacherl (Beitrag 1319545)
Zitat:

Zitat von Captnemo (Beitrag 1319539)
Dann aber kann ich auf den entsprechenden HKCU nicht zugreifen, weil das Programm dann unter einem anderen Benutzerkontext läuft.

:shock: Das sollte nicht der Fall sein. Oder ist dein Benutzer kein Admin und du startest den Prozess tatsächlich mit anderen Credentials?

HKCU als Admin != HKCU normaler User.

Du müsstest wissen unter welchen Key HKEY_USERS der User eigentlich liegt ...

DeddyH 23. Okt 2015 13:37

AW: Adminrechte für eine Prozedur
 
Ich würde den Schlüssel unter HKLM vom Setup erstellen lassen und den unter HKCU bei Bedarf.

Zacherl 23. Okt 2015 14:51

AW: Adminrechte für eine Prozedur
 
Zitat:

Zitat von Bernhard Geyer (Beitrag 1319559)
HKCU als Admin != HKCU normaler User.

Das ist schlicht und einfach falsch. HKCU ist HKCU. Habe es grade nochmal getestet. Werte die ich mit meinem Programm schreibe ohne zu elevaten sind auch dann lesbar, wenn ich den Prozess ausdrücklich per UAC Dialog als Admin starte und andersrum.

Captnemos Problem muss an anderer Stelle liegen.

Macht ja auch gar keinen Sinn. Seit es UAC gibt, ist das Token jedes Admin-Users mit einem zusätzlichen Token verlinkt. Das normale Token hat halt auch bei Admin Accounts nur eingeschränkte Rechte. Wenn man elevated, wird das linked Token zugewiesen, welches die tatsächlichen Adminrechte besitzt. Beide Token gehören aber dem selben Benutzer, deshalb sieht man auch den selben HKCU Key und hat ebenfalls genauso Zugriff auf das jeweilige Benutzerverzeichnis.

Der schöne Günther 23. Okt 2015 16:41

AW: Adminrechte für eine Prozedur
 
Nein, er hat Recht.

Benutzer A: Standardnutzer
Benutzer B: Lokaler Admin

Wenn du beim UAC-Prompt nun die Credentials von Benutzer B angibst (wen sollte man sonst nehmen?) dann ist HKCU definitiv der von Benutzer B.

mkinzler 23. Okt 2015 17:32

AW: Adminrechte für eine Prozedur
 
Ihr redet von 2 unterschiedlichen Szenarien.

Captnemo 23. Okt 2015 18:47

AW: Adminrechte für eine Prozedur
 
Ich kann ja auch die Frage mal ein bisschen anders stellen (wobei ich die Aussage von Zacherl noch mal eingehend prüfen werde).

Mein Programm kommt und soll auch ohne Installation daher. Es gibt aber innerhalb des Programmes eine optionale Einstellung, die der User auswählen kann. Tut er dies, so soll das Programm für den Fall die entsprechenden Rechte einfordern (sofern das überhaupt geht), und nach dem Setzen dieser Einstellung eben wieder ohne diese Adminrechte weiterlaufen.
Ich will vermeiden, dass ein User auf die Idee kommt, den Haken "Programm als Administrator ausführen" setzt, zumal ich auch glaube, dass dann die vom User gemappten Laufwerke ggf. auch nicht zur Verfügung stehen. Und die Adminrechte generell schon beim Start vorauszusetzen, nur um eine Option zur Verfügung zu halten, die nicht immer benötigt wird, wäre auch keine gute Idee.

Daher meine Frage: geht das überhaupt, oder nicht.

Zacherl 23. Okt 2015 19:26

AW: Adminrechte für eine Prozedur
 
Markus hat recht, deshalb hatte ich bei meiner ersten Antwort explizit nach Credentials gefragt. Ich arbeite als lokaler Admin. Wenn da das UAC Fenster kommt, wird der Prozess ganz einfach über das linked Token elevated. Hier findet KEIN Switch auf einen anderen User statt.

Klar, wenn du eingeschränkt arbeitest musst du Credentials von einem Adminuser eingeben. In diesem Falle hat Bernhard natürlich recht.

Jetzt wieder zurück zum Problem. Ja du kannst über diverse Methoden auch nur einen einzigen Thread elevaten. Stichwort ist impersonation. Die Impersonation kannst du nach deiner Aktion auch ohne Probleme wieder rückgängig machen (MSDN-Library durchsuchenRevertToSelf)

HolgerX 24. Okt 2015 05:29

AW: Adminrechte für eine Prozedur
 
Hmm..

Und wo ist nun das Problem?

HKLM ist immer bei beiden Anmeldungen gleich (solange auf dem selben PC ausgeführt).

Wenn Du die Speicherroutinen in die Registry aufteilst, dann sollte es eigentlich klappen, nach dem Motto:

Normaler User
-> Speichern in HKCU

Admin anfordern
-> Speichern in HKLM

wieder zurück (zum normalen User)
-> Speichern/lesen in HKCU, lesen in HKLM

Ich habe einige Dienste erstellt, welche gleichzeitig mit verschiedenen Anmeldungen laufen.
- Der Dienst selber als LocalSystem
- Der Kommunikations- Thread als User A
- Ein spezieller PrintSpooler als User B (Dieser hatte die Netzwerk-Drucker gemappt)

Geh hin und lagere das 'speichern' in HKLM in eine Funktion aus, welche mit LogonUser, LoadUserProfile, ImpersonateLoggedOnUser einen Admin anmeldet und dann das Speichern durchführt. Anschließend dann mit RevertToSelf und UnloadUserProfile wieder zurück zum normalen User.


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:57 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz