Wie Adminrechte für eigenes Prog holen ?

[kalmi01]

Hallo,

auf Grund Umstellung von NT auf XP, nutzen meine Kollegen die Chance, den Anwendern die Zugriffsrechte auf diverse Verzeichnisse zu beschneiden.
=> Soweit OK, aber leider legen einige, der von mir betreuten Prog's ihre INI direkt im Windows-Verzeichnis ab.

Um geändert INI-Dateien ins Windows-Verzeichnis kopieren zu können muß ich Admin sein.
Auch OK.

Jetzt wäre es schön, wenn ich mir ein Prog erstellen könnte, welches unter dem Benutzer-Account startet und sich selbst Admin-Rechte, über einen von mir angelegten Admin-Account, holt.
D.h. das Prog soll sich selbst zum Admin machen.

"RunAs" ist keine Lösung (!!!) da Prog als Consolen-Prg im Hintergrund läuft.

Bei der Suche in der DP hab ich leider nichts passendes gefunden.

[Tyler]

da gibts ne ganze Menge externe Tools:

PSExec von Sysinternals http://www.sysinternals.com/
RunAsSPC http://robotronic.de/runasspc/
CPAU http://www.joeware.net/win/free/tools/cpau.htm


Mit PSExec hab ich aber das Probleme, wenn ich in einer Domäne ein Programm auf dem Server unter anderem Account ausführen möchte, was wohl daran liegt, dass auf dem Domänencontroller kein lokaler Benutzer existiert.

Dann gabs unter XP noch ein mitgeliefertes Programm auf Kommandozeilenebene, dessen Namen mir gerade entfallen ist - das ist wohl das von dir erwähnte RunAs.

Hoffe das hilft?

tyler

//EDIT
warum soll das Programm nicht als Konsolenprogramm laufen, wo liegt da das Problem?

PS:
sollte es eine Lösung in Delphi geben, wäre ich an der auch sehr interessiert.. :)

[alcaeus]

Moin Kalmi,

wenn du Programme fuer die Win-NT-Schiene erstellst, musst du auch zusehn dass diese Win-NT-konform programmiert sind. Nachdem NT, 2000 und XP Mehruser-faehig sind, ist es sozusagen deine Pflicht, die Konfiguration eines Programms im jeweiligen User-Ordner abzuspeichern, und nicht im Programmordner. Ehrlich gesagt waere ich auch sauer, wenn jemand in meinen Einstellungen rumpfuschen wuerde. Denk mal an Terminal Server z.B., da arbeiten teilweise 150 User an einem Server, d.h. sie wuerden alle in den gleichen Einstellungen rumspielen :shock:

Deshalb: aendere das Programm, das geht schneller als zu versuchen, das Ganze User-Rights-Management auszuhebeln.

Greetz
alcaeus

[kalmi01]

Hallo alcaeus,

danke für den Hinweis:

Zitat:

wenn du Programme fuer die Win-NT-Schiene erstellst, musst du auch zusehn dass diese Win-NT-konform programmiert sind
....
Deshalb: aendere das Programm, das geht schneller als zu versuchen, das Ganze User-Rights-Management auszuhebeln

aber:

Zitat:

Soweit OK, aber leider legen einige, der von mir betreuten Prog's ihre INI direkt im Windows-Verzeichnis ab

"Von mir betreut" heißt nicht: "von mir erstellt.

Es handelt sich um gekaufte Software, bei der teilweise die Hersteller nicht mehr existieren !

D.h. ich versuche einen Minimal-WorkAround um den Kram am Leben zu halten.
Sourcen existieren nicht, RunAs für das Fremdprogramm fällt aus, weil der Anwender seinen Schrott sonst überall im System speichern könnte.


Hi Tyler,

Programm, welches Programm mit Adminrechten startet fällt aus.
Sonst ruft Prg auf, welches Prg aufruft, welches Prg aufruft, welches Prg aufruft, welches die Rechte nicht haben darf.

[sakura]

Erst einmal: warum speicherst Du die INIs nicht an einem anderen Ort :gruebel: Das Windows-(System-)Verzeichnis ist der denkbar ungeeigneteste Platz dafür. :cyclops:

Zitat:

Zitat von kalmi01

Jetzt wäre es schön, wenn ich mir ein Prog erstellen könnte, welches unter dem Benutzer-Account startet und sich selbst Admin-Rechte, über einen von mir angelegten Admin-Account, holt.
D.h. das Prog soll sich selbst zum Admin machen.

In der Unit Windows sind die Funktionen LogonUser und ImpersonateLoggedOnUser, die helfen dir bestimmt. Beispiel:

Delphi-Quellcode:

var
  Token: Cardinal;
...
  LogonUser('UserName', 'Domain', 'Password', LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, Token);
  ImpersonateLoggedOnUser(Token);

...:cat:...

[kalmi01]

Hi sakura,

ich bin's doch garnicht, ich will's doch garnicht.
Es handelt sich um gekaufte Software, bei der teilweise die Hersteller nicht mehr existieren !

[NicoDE]

Unter Windows NT können INI-Dateien in der Registry gemappt werden.
Such im Netz mal nach IniFileMapping

Zum Beispiel: http://msdn.microsoft.com/library/en...filestring.asp

[sakura]

Zitat:

Zitat von kalmi01

Es handelt sich um gekaufte Software, bei der teilweise die Hersteller nicht mehr existieren !

Warum postest Du dann in der Sparte Delphi :gruebel: Ich hatte Deinen Post davor nicht mitbekommen :?

...:cat:...

[DP-Maintenance]

Dieses Thema wurde von "sakura" von "Sonstige Fragen zu Delphi" nach "Windows 9x / ME / 2000 / XP / 2003" verschoben.

[kalmi01]

Hi sakura,

weil ich einen WorkAround in Delphi programmiert habe, der die Sachen aus den lokalen Prg-Verzeichnissen an die richtigen Stellen im System kopiert, wo die "Alt-Software" ihr geraffel sucht.
Ist leider nicht nur ein Pfad, sondern auch noch Registry-Einträge.
Diese können sich dynamisch ändern und sollen von meinem Prog an die richtige Stelle im System gebeamt werden.
Mein Delphi-Prog funktioniert auch soweit, allerdings bräuchte ich für ein paar Millisekunden Adminrechte, ähnlich wie mit RunAs oder SU unter UNIX.
Einen geeigneten Admin-Acount, der nur das darf, was ich brauche, hab ich ebenfalls angelegt.

Jetzt muss mein Prg nur unter User-Acount die Daten sammeln und anschließend als Admin ins System schießen.

[DP-Maintenance]

Dieses Thema wurde von "sakura" von "Windows 9x / ME / 2000 / XP / 2003" nach "Windows API / MS.NET Framework API" verschoben.
Na gut, dann zurück...

[sakura]

Zitat:

Zitat von kalmi01

weil ich einen WorkAround in Delphi programmiert habe, der die Sachen aus den lokalen Prg-Verzeichnissen an die richtigen Stellen im System kopiert, wo die "Alt-Software" ihr geraffel sucht.
Ist leider nicht nur ein Pfad, sondern auch noch Registry-Einträge.
Diese können sich dynamisch ändern und sollen von meinem Prog an die richtige Stelle im System gebeamt werden.

Eine Erklärung, welche Du auch eher hättest geben können ;-)

Zitat:

Zitat von kalmi01

Mein Delphi-Prog funktioniert auch soweit, allerdings bräuchte ich für ein paar Millisekunden Adminrechte, ähnlich wie mit RunAs oder SU unter UNIX.
Einen geeigneten Admin-Acount, der nur das darf, was ich brauche, hab ich ebenfalls angelegt.

Jetzt muss mein Prg nur unter User-Acount die Daten sammeln und anschließend als Admin ins System schießen.

Dann schreibst Du also doch ein Delphi-Programm. Dann sollte Dir der obige Code von mir auch helfen, oder :gruebel: Damit kannst Du zur gegebenen in den administrativen Account wechseln. Mit RevertToSelf kannst Du zu späterer Zeit wieder zurück auf die normale Userebene.

...:cat:...

[Olli]

Das o.g. Mapping der INI-Dateien solltet ihr nochmals in Betracht ziehen!!! Wenn entsprechende Funktionen von Windows benutzt werden, funktioniert das. Ist es eine "homegrown"-Lösung, dürfte es nicht gehen. Also am besten erstmal abchecken.

[kalmi01]

Hi Olli,

wenn jemand eine INI-Datei im Working-Directory anlegt, Sie ins Programm-Verzeichnis kopiert und nach Windows/WinNT, beim nächsten Start die INI-Datei aber nur im Windows/WinNT-Verzeichnis sucht, geh ich mal nicht davon aus, dass er:

Zitat:

Wenn entsprechende Funktionen von Windows benutzt werden, funktioniert das.

dies berücksichtigt hat :spin2:

[NicoDE]

Mit welchen (API-)Funktionen greift das Programm auf die Daten der INI-Datei zu?
(gibt es eine Möglichkeit das ganze abzukürzen - zum Beispiel das Programm zur Einsicht per EMail?)

[kalmi01]

Hallo NicoDE,

Zitat:

Mit welchen (API-)Funktionen greift das Programm auf die Daten der INI-Datei zu?

:?: :gruebel: :?: :gruebel: :?:
Ist Fremdsoftware.



:hello:
so, hier also eine Lösung:

Delphi-Quellcode:

var
  Token : Cardinal;
begin
  if not LogonUser('admin',   //'UserName'
                   'hier',    //'Domain'
                   '1234',    //'Password'
                   LOGON32_LOGON_BATCH,
                   LOGON32_PROVIDER_DEFAULT,
                   Token)
  then MessageDlg('Unbekannter Benutzer', mtWarning, [mbOK], 0);

  if not ImpersonateLoggedOnUser(Token)
  then MessageDlg('Benutzerrechte nicht übernommen', mtWarning, [mbOK], 0);

  if not DeleteFile('\\pc116115\c$\test')
  then MessageDlg('Löschen fehlgeschlagen', mtWarning, [mbOK], 0);

  RevertToSelf;
end;

LOGON32_LOGON_INTERACTIVE hatte nicht funktionierte, warum auch immer,
LOGON32_LOGON_BATCH hat dafür prima geklappt.

Problem gelöst :!:

:thumb: :dancer:

[NicoDE]

Zitat:

Zitat von kalmi01

Ist Fremdsoftware.

Das würde mich nicht abhalten es herauszufinden (und zu fixen) *g*
Wie auch immer, Du hast ja eine Lösung.

[Vjay]

Naja als Alternative vielleicht einen Funktionshook in die externe Software schieben und den Pfad zur Ini-Datei abändern ;).
Ist genau so eine Frickellösung, aber es hilft ja nichts ;). Ist wohl schwieriger, aber wenigstens baust du dir keine Löcher ins System (oder?).