![]() |
AW: Zugriff auf Registry eines eingeschränkten Benutzerkontos mit Adminrechten
Man könnte höchstens den Benutzer des Elternsprozesses ermitteln. Aber dann fehlt dir ja immer noch das Passwort.
|
AW: Zugriff auf Registry eines eingeschränkten Benutzerkontos mit Adminrechten
Es gibt schon einen Grund warum das so ist und der heißt Malware. Aber um Dien Problem einigermaßen zu umschiffen, kannst Du Luckies Vorschlag nutzen oder eine StartUp-Schicht einfügen, welche die benötigten Daten sammelt, wozu jedoch nicht das Admin-Passowrt gehört. Daher wurdest Du gleich zu Beginn dieses Threads auch immer wieder gefragt, ob Du den Admin nerven möchtest, wenn er immer wieder sein Passwort eingeben muss.
An dieser Stelle solltest Du jedoch auch bedenken, dass dieses Vorgehen ein erhöhtes Sicherheitsrisiko bedeutet. Immerhin hast Du extra ein eingeschränktes User-Konto für den Internet-Zugriff erstellt und möchtest dieses nun die ganze Zeit über wieder umgehen. Wenn Du Dir nun einen Trojaner eingehandelt hast, der einen Keylogger nachinstalliert, dann hast Du auf diese Weise möglicherweise soeben Deinen Rechner kapern lassen. Denk mal drüber nach. :vernupft: |
AW: Zugriff auf Registry eines eingeschränkten Benutzerkontos mit Adminrechten
Ich habe gerade alles durchgelesen und verstehe immernoch nichts.
Krze Fragen: 1. Windows XP oder Vista oder 7? 2. Es läuft irgendein SQL Server als Dienst. Den willst du starten und stoppen als Admin? 3. Du willst auf die Registry des Benutzers zugreifen. Dort stehen irgendwelche Einstellungen drin? Ich folgere: Du hast ein Programm, das kann ohne Adminrechte irgend etwas machen (z.B. Registry des Users benutzen). Aber manchmal willst du darin auch den SQL Server steuern (starten/stoppen). Dafür brauchst du Adminrechte. Deshalb muss der Benutzer derzeit schon von Anfang an dein Programm als Admin starten. Aber dann kannst du die Benutzereinstellungen des normalen Benutzers nicht nutzen, sondern nur vom Admin. Alles korrekt? Jetzt kommt Frage 1 ins Spiel: Ich verstehe nicht, wie keiner danach fragen konnte? Unter XP ist der Administrator ein eigenes Benutzerkonto mit eigener Registry. Ab Vista ist ein Administrator erst einmal ein normaler User und wird durch eine Abfrage an den Nutzer (UAC) für einen Prozess zum Admin. Aber es gibt auch Benutzer, die keine Admins sind und bei denen wieder ein echter Admin sich anmelden muss, der dann natürlich wie in XP mit eigener Registry ankommt. Für Vista ist die Lösung einfach. Baue den Code für die SQL Serversteuerung aus der Anwendung aus und setze sie in eine COM-DLL (nennt sich COM Elevation Moniker). Mit Windows kann diese DLL als Admin ausgeführt werden, ohne dass dein Prozess dazu Adminrechte braucht. In XP geht es leider nicht. Stattdessen musst du einen neuen Prozess mit Adminrechten (z.B. ShellExecute und Verb = runas) starten, der eben den SQL Server stoppt/startet. Du kannst z.B. deiner Anwendung Kommandozeilenparameter verpassen, um dies zu machen und dann eben die eigene Anwendung kurzzeitig nochmal sicht selbst starten lassen (über Verb = runas). Über den Prozessrückgabewert kannst du Fehler prüfen oder auch eine Kommunikation über Pipes, Events und MemoryMapped Files herstellen. Die Sache ist also einfach: Dein Prozess läuft ohne Admin und startet dann kurzzeitig einen weiteren Prozess mit Adminrechten, der die SQL Serversteuerung übernimmt: Teile und herrsche |
AW: Zugriff auf Registry eines eingeschränkten Benutzerkontos mit Adminrechten
Zitat:
Zitat:
ich danke Dir auch für die ausführliche Erläuterung zur Problemlösung, die ich bei Gelegenheit einmal ausprobieren werde. Wie gesagt, derzeit habe ich eine andere Lösung gefunden. Die Lösung mit runas als separates Programm kam mir auch in den Sinn. Zitat:
|
AW: Zugriff auf Registry eines eingeschränkten Benutzerkontos mit Adminrechten
Sry, hab ich wohl überlesen. Ich sehe nicht, dass du eine Lösung gepostet hättest.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz