Daten in HKEY_LOCAL_MACHINE ohne Adminrechte schreiben

[skyobserver]

Hallo,

auf den Client-PCs in unserem Windows-Netzwerk laufen Delphi-Programme
welche verschiedene ODBC-Einträge benötigen. Diese tragen wir bei der
Installation der PCs im Bereich "System-DSN" ein, damit sie allen
Benutzern zur Verfügung stehen.

Wenn mal ein Eintrag fehlt, oder ein neuer dazu kommt, soll das Programm
diesen selbstständig per TRegistry oder Import einer *.Reg-Datei eintragen.

Die Benutzer sind allerdings nur mit Benutzer- oder Hauptbenutzerrechten
angemeldet und dürfen daher nicht auf HKEY_LOCAL_MACHNINE zugreifen.

Gibt es eine Möglichkeit (z.B.mit hinterlegtem Admin-Benutzer+Passwort) diese
ODBC-Einträge anzulegen? Der Shell-Befehl "RunAs" hat laut Hlife nicht die
Möglichkeit ein Passwort zu hinterlegen...

[himitsu]

Ihr könntet einen kleinen Service aufsetzen, welcher dann ja im System-Konto läuft.
Dieser muß nur einmal mit entsprechenden Rechten eingerichtet werden und läuft danach ohne Zutun.
Per Pipe, MMF o.Ä. könnte man dem nun die neuen Daten übergeben und er trägt sie dann dort ein.
Aber im Service nur die entsprechenden Einträge erlauben, da sonst ein Sicherheitsrisiko bestünde.

Ebenso wäre es doch wohl auch nicht so sicher, wenn irgendwo das Adminpasswort "ungeschützt" rumliegen täte, welches dann dein Programm verwenden würde.


CreateProcessAsUser und Co. aber ich würde, wie gesagt, eher davon abraten.

[generic]

Du kannst diese Einstellungen via ActiveDirectory (AD) per GroupPolicyObjects (GPO) machen.

Bei einen >=2008er Server (DomainController) sogar besonders einfach.

[RWarnecke]

Impersonate ist Dein Stichwort. Damit kannst Du in einem Delphi-Programm ein anderes Programm oder Vorgang als Admin aufrufen und ausführen.

[Luckie]

aber dann muss er auch irgendwo die Zugangsdaten hinterlegen, was wieder ein Sicherheitsrisiko bedeutet.

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1085936)

aber dann muss er auch irgendwo die Zugangsdaten hinterlegen, was wieder ein Sicherheitsrisiko bedeutet.

Mit LsaStorePrivateData (alte Methode) oder CryptProtectData sollte dies ein geringes Problem sein.

[jobo]

Wieso muss man das System unbedingt verbiegen?
Was spricht gegen User DSN und Registry Import von einer gemeinsamen Netzdatei beim Login?
Bekommt man ohne Sicherheitsprobleme und Extras und nur mit Bordmitteln.

Man könnte auch gleich mit Datei DSN arbeiten.

Remote per Admin gehts dann auch mit Regedit in die jeweiligen HKLM Einträge. Ich kenne es aber so nur interaktiv.

[skyobserver]

Erst mal danke für die Antworten,

-Also das Passwort würde ich natürlich nicht im Klartext im Code hinterlegen.
Ich würde es kodieren und erst zur Laufzeit dekodieren, wenn es benötigt wird...

-Per GroupPolicy wird nicht gehen, da je nach installierter Datenbank-Client-Version
der ODBC-Eintrag etwas anders aussehen muss. Das Programm bzw. der Service muss erst
die Client-Version ermitteln und dann die entsprechenden Registry-Daten importieren...

-Per Remote-Registry kommt nicht in Frage - wir produzieren 24 Stunden / 7 Tage die Woche
und ich werde ungern Nachts um 04:00 angerufen um einen ODBC-Eintrag zu machen :wink:

-Diese Einträge sind nicht Benutzerspezifisch sondern für alle Benutzer gleichermaßen
verbindlich. Prinzipiell ist also System-DSN der richtige Ort - natürlich funktioniert
Benutzer-DSN grundsätzlich auch...


Werde mir also "CreateProcessAsUser" bzw. "Impersonate" mal ansehen...


Danke!

[alzaimar]

Wenn Du sowieso schon eine automatische Registrierung der DSN vorgesehen hast, nutze das doch. So viele unterschiedliche Benutzer gibt es ja nicht und im Kontext der Sicherheitsphilosophie ist diese Lösung die Richtige.

Wenn Du das Kennwort im Code hast, egal ob verschlüsselt oder nicht, wird das ein Angreifer ohne große Probleme ausnutzen können.

[DelphiSecurity]

Ich bin für den Service. Ist sinnvoll! :wink: