RunAs Dialog vor dem Programmstart???

[Piro]

Moin,

Ich habe ein Programm, welches die Systemprogramme von Windiws als Sammlung enthält. In unserer Firma sollen nun der Helpdesk dieses Programm mit Adminrechten auf dem jeweiligen UserPC benutzen

Dazu würde ich gerne den RUNAS Dialog verwenden.

Frage:
Ist es möglich ein Programm zu entwickeln, dass: 1. RUNAS DIALOG aufruft, 2. das gleiche Programm mit dem RUNAS Benutzer startet? --> Es soll nur ein Programm sein

Vielen Dank im Voraus.

[Christian Seehase]

Moin Daywalker,

das sollte grundsätzlich gehen.
Du müsstest halt prüfen, ob schon eine Instanz des Programms läuft, ist nicht der Fall startet es das Programm noch einmal (der Pfad ist in paramstr(0)), und beendet sich selber.
Läuft schon eine Instanz, ist beim Start nichts mehr zu tun.
Diese Prüfung sollte dann in der DPR stattfinden.
Einige grundsätzliche Beispiele für das Auffinden laufender Instanzen eines Programmes solltest Du hier mit CreateMutex bzw. CreateSemaphore finden können.

[Piro]

Ich ahbe jetzt das Forum durchwühlt und bin völlig verwirrt.

Kannst du mir mal kurz theoretisch den Aufruf erklären?

Mein Verständnis.

1. Programm startet und checkt ob es schon existiert - Frage: wie kann ich ein Programm ein 2.Mal starten ohne etwas zu tun?
2. Wenn es existiert - Aufruf des RUNAS Dialoges mit anschließendem erneuten Aufruf des Programmes mit Schließung des 1.Programmes

Richtig? Wenn das so ist, habe ich ein Problem, da ich mich noch nicht damit auseinander gesetzt habe. Kennt da einer gute Tutorials?

[CodeX]

falls du auf den runas dialog verzichten kannst und einen eigenen dialog erstellen kannst, dann mach folgendes:

1. beim programmstart die rechte prüfen. falls rechte nicht ausreichend, wird der eigene dialog geöffnet.
2. benutzername und passwort vom dialog verwendest du um CreateProcessAsLogon von Luckie aufzurufen.
3. wenn 0 zurückgeliefert wird, hats geklappt und du beendest die aktuelle instanz, da das programm dann ein zweites mal mit den erweiterten rechten gestartet wurde.

[uwewo]

Hi,

vielleicht verstehe ich etwas nicht aber...

...normalerweise rechte Maustaste auf das Programm und RunAs auswählen(Englische Version)
...versucht man ein Programm zu installieren und man besitzt keine Rechte öffnet sich
der RunAs Dialog automatisch.

Zumindest in unserer Fa.

Server 2003
Workstations WinXP Prof.

Uwe

[kalmi01]

Oder Dein Prog macht selbst eine Abfrage á la

Benutzername:
Passwort:

und versucht sich dann die Berechtigungen zu holen:

Delphi-Quellcode:

var
  AdminToken : Cardinal;

if LogonUser(PAnsiChar(USERNAME),        // UserName
             PAnsiChar(DOMAIN),          // Domäne oder lokaler Rechner
             PAnsiChar(PASSWORD),        // Password
             LOGON32_LOGON_BATCH or LOGON32_LOGON_NETWORK or LOGON32_LOGON_INTERACTIVE,
             LOGON32_PROVIDER_DEFAULT,
             AdminToken)
then begin
       if ImpersonateLoggedOnUser(AdminToken)
       then begin
              // hier kommt Dein Prog.-Code hin

              RevertToSelf;              // zurückschalten zum angemeldeten Benutzer
            end;
     end;

[MathiasSimmack]

Zitat:

Zitat von uwewo

...versucht man ein Programm zu installieren und man besitzt keine Rechte öffnet sich der RunAs Dialog automatisch.

Das liegt daran, weil Windows (XP und höher, bei 2000 weiß ich es nicht) in dem Fall auf die Dateinamen "setup.exe" und "install.exe" reagiert und den Dialog anzeigt. Diesen Trick kann man sich übrigens zunutze machen. :???:
Es reicht nämlich, unter HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths das eigene Programm mit zwei Werten zu registrieren. Ich habe dort die beiden o.g. Dateinamen gefunden, es mit einem eigenen Programm getestet, und es funktioniert wunderbar. Kleine REG-Datei zum Testen:

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Dateiname.exe]
"RunAsOnNonAdminInstall"=dword:00000001
"BlockOnTSNonInstallMode"=dword:00000001

"Dateiname.exe" ist natürlich durch den gewünschten Dateinamen des eigenen Programmes zu ersetzen. :stupid:


PS: Ich denke, der Wert "RunAsOnNonAdminInstall" dürfte ausreichen (= Ausführen als, bei Nicht-Admin-Installation). Der zweite "BlockOnTSNonInstallMode" bezieht sich, wenn ich raten soll, wohl auf Terminal Server. Was er aber genau bedeutet, weiß ich nicht. :oops:

[Piro]

Danke für die zahlreichen Antworten. Wie ich das sehe verzichte ich wohl auf den RUNAS Dialog von Windows, obwohl es gut wäre, denn man bezieht sich gleich auf die vorhanden Users im Active Directory.

@kalmi01:
Dein Programmcode kommt doch in die *.dpr datei oder wie integriere ich dein Codebeispiel?

Gibt es irgendwo ein Tutorial in dem man sieht, wie ein gestartetes Programm sich erneut aufruft und die das zu erst geöffnete Programm schließt?

Danke.

[kalmi01]

Hi,

der Code kommt in Deine Main-Unit (z.B. Unit1.pas).
Der Code ruft Dein Prog nicht noch einmal auf, sonder verleiht dem laufenden Prog die gewünschten Benutzerrechte, so als hättest Du es mit RunAs gestartet.

[SirThornberry]

ich würde das ganze einfach über parameter machen.

Delphi-Quellcode:

var LStartedWithRunAs: Boolean;
    LCount           : Integer;
begin
  LStartedWithRunAs := False;
  LCount := 1;
  while (LCount <= ParamCount) and not(LStartedWithRunAs) do
  begin
    LStartedWithRunAs := ParamStr(LCount) = 'StartedWithRunAs';
    inc(LCount);
  end;

  if not(LStartedWithRunAs) then
  begin
    //Starten als Dialog hoch bringen
    [...]
  end;
end;

mein Problem wäre dabei jedoch das ich nicht weiß wie man den Dialog "Ausführen als" per Api öffnet.

[Piro]

So ich habe jetzt ein einfaches Programm geschrieben wollte es mal probieren wie ihr es gesagt habt. Irgendwie verstehe ich das immer noch wie ich den Syntax setzen muss bzw. soll.

Kann mir mal einer ein komplettes beispiel geben?

[CodeX]

Zitat:

Zitat von kalmi01

Oder Dein Prog macht selbst eine Abfrage á la

Benutzername:
Passwort:

und versucht sich dann die Berechtigungen zu holen:

Delphi-Quellcode:

var
  AdminToken : Cardinal;

if LogonUser(PAnsiChar(USERNAME),        // UserName
             PAnsiChar(DOMAIN),          // Domäne oder lokaler Rechner
             PAnsiChar(PASSWORD),        // Password
             LOGON32_LOGON_BATCH or LOGON32_LOGON_NETWORK or LOGON32_LOGON_INTERACTIVE,
             LOGON32_PROVIDER_DEFAULT,
             AdminToken)
then begin
       if ImpersonateLoggedOnUser(AdminToken)
       then begin
              // hier kommt Dein Prog.-Code hin

              RevertToSelf;              // zurückschalten zum angemeldeten Benutzer
            end;
     end;

*weißt* du, ob das sicher (immer) funktioniert, oder ist das nur ein theoretischer ansatz?
ich kenne das wirklich nur so, dass man ein programm mit den richtigen rechten starten kann, nicht aber dessen rechte zur laufzeit ändern kann.

[kalmi01]

Moin, moin, CodeX,

Ich habe mehrere Programme bei über 300 Usern laufen, die sich auf diese Weise die notwendigen Berechtigungen holen.
Bis dato gab es nur seeeehr selten Probs und wenn, dann hatte der DC ein Prob, soll heissen: auch RunAs lief dann nicht zuverlässig.
Policies können einem IMMER die Suppe versalzen.

Sicher funktioniert es ab XP/Server2003;
bei NT-Maschinen gibt es manchmal Probs (Service-Pack),
bei 2000 kann ich keine repräsentative Aussage machen, da nur eine handvoll PC damit liefen (aber ebenfalls OK).

Vorteil ist, dass sich das Prog mit

Delphi-Quellcode:

ImpersonateLoggedOnUser(AdminToken)

nur genau dann User-Rechte holt, wenn diese benötigt werden.
Ausserdem kann man in einem Prog mehrfach die User-Rechte wechseln !
Was m it RunAs nicht geht.

[CodeX]

sehr gut zu wissen. danke.

aber dann nochmal zum verständnig:
die benutzerrechte werden beim aufruf von LogonUser auf dem gesamten rechner geändern und nicht nur das programm betreffend, oder?
mit RevertToSelf kehrt man ja dann erst zu den normalen rechten zurück.

das würde ja dann bedeuten, dass wenn man beim starten des programmes LogonUser aufruft und beim beenden erst RevertToSelf, dass dann während der gesamten programmlaufdauer, der benutzer als admin angemeldet ist. das betrifft ja dann auch andere programme. somit müsste man statt dessen die programmfunktionen mit diesen funktionen umschließen, die adminrechte voraussetzen. das würde aber unter umständen doch dann zu ständigen benutzerwechseln führen. dann kann doch nicht gut sein. :?

oder irre ich mich jetzt gewaltig und die benutzerwechel betreffen nur das eigene programm? (was ich mir technisch nicht vorstellen könnte)

[kalmi01]

Zitat:

Zitat von CodeX

......
aber dann nochmal zum verständnig:
die benutzerrechte werden beim aufruf von LogonUser auf dem gesamten rechner geändern und nicht nur das programm betreffend, oder?

Nein !
NUR das Programm selbst erhält die neuen Benutzerrechte.

Zitat:

.....
oder irre ich mich jetzt gewaltig und die benutzerwechel betreffen nur das eigene programm? (was ich mir technisch nicht vorstellen könnte)

Betrifft nur das eine Prog (wie bei RunAs) !
Kannst aber halt als verschiedene Benutzer innerhalb einer Session agieren.

[CodeX]

ich hab mal ein bisschen geforscht.
jetzt lass mich raten: du arbeitest dabei mit services, richtig?

denn ich habe folgendes gefunden:

Zitat:

Zitat von PSDK

The process calling LogonUser requires the SE_TCB_NAME privilege. If the calling process does not have this privilege, LogonUser fails and GetLastError returns ERROR_PRIVILEGE_NOT_HELD.

und das SE_TCB_NAME kann man sich scheinbar nur als service holen.

[MathiasSimmack]

Sagt mal, Jungs und Mädchen, wäre das nicht ein gutes Thema für eine kleine Delphi PRAXiS-DLL? Diese DLL könnte ihrerseits die hier gezeigten Funktionen kapseln, so dass man sie mit wenig Aufwand in eigene Programme einbinden kann.

Die Hauptfunktionen der DLL könnten dabei statisch in die eigenen Programme gelinkt werden, so dass die Anwendung ohne die DLL gar nicht startet. Im Gegensatz dazu sollten die benutzten API-Funktionen in der DLL natürlich dynamisch geladen werden, so dass bspw. ein Aufruf unter 9x/ME immer mit true (oder was weiß ich) beantwortet wird.

Dazu vielleicht ein paar Typen und/oder Klassen bzw. Auflistungen, damit man nicht mit dem API-Zeug hantieren muss. Klappt das Erlangen der gewünschten Rechte nicht, könnte man sicher das API für sich arbeiten und die entsprechende Fehlermeldung direkt aus dem System ausgeben lassen (Stichwort: FormatMessage).

Und wer schlicht und einfach nur den "Ausführen als"-Dialog braucht, für den könnte man ja eine Dialogressource (nonVCL) integrieren, die dem Original nachempfunden ist, und mit der man das Konto auswählen und das Passwort eingeben kann. Selbstverständlich sollte sich der Anwender nicht mit der Nachrichtenschleife unter nonVCL herumschlagen müssen. Für ihn sollte ein simpler Aufruf à la

Delphi-Quellcode:

if RunAsDialog(...) then
begin
end;

genügen.


@Codex: Hast du da nicht ein Zitat vergessen:

Zitat:

The SE_TCB_NAME privilege is not required for this function unless you are logging onto a Passport account.

[TeronG]

Zitat:

Zitat von MathiasSimmack

so dass man sie mit wenig Aufwand in eigene Programme einbinden kann.

Delphi-Quellcode:

var
  AdminToken : Cardinal;

if LogonUser(PAnsiChar(USERNAME),        // UserName
             PAnsiChar(DOMAIN),          // Domäne oder lokaler Rechner
             PAnsiChar(PASSWORD),        // Password
             LOGON32_LOGON_BATCH or LOGON32_LOGON_NETWORK or LOGON32_LOGON_INTERACTIVE,
             LOGON32_PROVIDER_DEFAULT,
             AdminToken)
then begin
       if ImpersonateLoggedOnUser(AdminToken)
       then begin
              // hier kommt Dein Prog.-Code hin

              RevertToSelf;              // zurückschalten zum angemeldeten Benutzer
            end;
     end;

also ich würd ja sagen, daß der Code eh schon recht simpel/kurz/unaufwändig ist. Quasi nur eine if abfrage (mit einer if abfrage) und schon kannste deinen code reinschmeißen.
Hätt ich dden Code nur eher gekannt ..

[Piro]

Das Thema ist ja richtig interessant geworden. Trotzdem bleibt meine Frage, da ich nicht wirklich fit bin in diesem Thema, wie ich diesen Code in meine vorhandene Applikation einbaue.

Ansonsten mache ich es mit CreateProcessAsUser halt für meine Unterprogramme in meinem Programm. Schöner wäre ja nur wenn das ganze Tool mit Admimrechten laufen würde.

Danke.

[TeronG]

Zitat:

Zitat von daywalker299

Schöner wäre ja nur wenn das ganze Tool mit Admimrechten laufen würde.

Und wenn du einfach den code in dein onCreate packst?
evtl./sicherheitshalber im OnClose noch das RevertToSelf rein ... :gruebel:

[CodeX]

Zitat:

Zitat von MathiasSimmack

@Codex: Hast du da nicht ein Zitat vergessen:

Zitat:

The SE_TCB_NAME privilege is not required for this function unless you are logging onto a Passport account.

wir schmeissen hier mit zitatfetzen um uns ... ;)
also hier mal vollständig:

Zitat:

Remarks

The LOGON32_LOGON_NETWORK logon type is fastest, but it has the following limitations:

* The function returns an impersonation token, not a primary token. You cannot use this token directly in the CreateProcessAsUser function. However, you can call the DuplicateTokenEx function to convert the token to a primary token, and then use it in CreateProcessAsUser.
* If you convert the token to a primary token and use it in CreateProcessAsUser to start a process, the new process cannot access other network resources, such as remote servers or printers, through the redirector. An exception is that if the network resource is not access controlled, then the new process will be able to access it.

The SE_TCB_NAME privilege is not required for this function unless you are logging onto a Passport account.

Windows 2000: The process calling LogonUser requires the SE_TCB_NAME privilege. If the calling process does not have this privilege, LogonUser fails and GetLastError returns ERROR_PRIVILEGE_NOT_HELD. In some cases, the process that calls LogonUser must also have the SE_CHANGE_NOTIFY_NAME privilege enabled; otherwise, LogonUser fails and GetLastError returns ERROR_ACCESS_DENIED. This privilege is not required for the local system account or accounts that are members of the administrators group. By default, SE_CHANGE_NOTIFY_NAME is enabled for all users, but some administrators may disable it for everyone. For more information about privileges, see Privileges.

ich habe den code jetzt ausprobiert. unter XP funktioniert das einwandfrei.
unter 2000 jedoch nicht. LogonUser liefert hier false zurück. das wird wohl genau der hinweis sein, den ich als zitat gepostet habe.
kann das bitte jemand auch ausprobieren und bestätigen/dementieren? (btw: als DOMAIN habe ich '' genommen, da ich das lokal machen möchte. ging unter XP, vllt braucht 2000 was anderes?)

für meine zwecke müsste eine solche funktion für 2000/XP/2003 funktionieren. die 2000 user möchste/kann ich auf keinen fall ausnehmen.

[Luckie]

Warum nimmst du nicht CreateProcessWithLogonW? das funktioniert sowohl unter Windows 2000 als auch Windows XP. Und du kannst dir auch mal RunAsUser angucken.

[Piro]

Habe mit mal CreateProcessWithLogonW angeschaut. würde für meinen Fall auch zu treffen. Funktioniert das auch mit delphi3? Bekomme immer ein fehlermeldung das er EnablePrivilege oder CreateProcessAsLogon nicht kennt.

[Luckie]

EnablePrivilege
Und dann brauchst du wahrscheinlich noch die Unit MpuWinNT.pas von meiner Homepage.

[CodeX]

Zitat:

Zitat von Luckie

Warum nimmst du nicht CreateProcessWithLogonW? das funktioniert sowohl unter Windows 2000 als auch Windows XP. Und du kannst dir auch mal RunAsUser angucken.

klar, das geht. nachteil ist hier, dass das nicht im laufenden programm geändert werden kann.
um das in einer exe verwenden zu können, muss sich das programm damit selber aufrufen und die aktuelle instanz beenden.
dürfte den programmstart entsprechend verlangsamen.

[Christian Seehase]

Moin Daywalker,

Zitat:

Zitat von daywalker299

Funktioniert das auch mit delphi3? Bekomme immer ein fehlermeldung das er EnablePrivilege oder CreateProcessAsLogon nicht kennt.

Funktionieren wird das mit D3 grundsätzlich schon, nur wirst Du vermutlich die Funktionen selber importieren müssen.

[kalmi01]

Zitat:

Zitat von daywalker

Schöner wäre ja nur wenn das ganze Tool mit Admimrechten laufen würde

Tut es ja, wenn Du einen Admin-Account kennst :stupid:
Ansonsten müsste man davon ausgehen müssen, dass Du was "Böses" machen willst. :-D

Zitat:

unter XP funktioniert das einwandfrei.
unter 2000 jedoch nicht.
.....
als DOMAIN habe ich '' genommen

Probiers mal mit der realen Domäne, also Domäne oder Computername.

Zitat:

sicherheitshalber im OnClose noch das RevertToSelf rein

Warum ?
Wenn das Prog schliesst ist alles um !
Kein Prog = keine Rechte !

Zitat:

Zitat von TerronG

Hätt ich dden Code nur eher gekannt ..

Na ja, gekannt hab ich ihn auch nicht.
Ich glaub man nennt das "Erarbeiten" :thumb:

Zitat:

Zitat von CodeX

jetzt lass mich raten: du arbeitest dabei mit services, richtig?

Definitiv NEIN.

[CodeX]

Zitat:

Zitat von kalmi01

Zitat:

unter XP funktioniert das einwandfrei.
unter 2000 jedoch nicht.
.....
als DOMAIN habe ich '' genommen

Probiers mal mit der realen Domäne, also Domäne oder Computername.

habe ich nun mit dem computernamen probiert.
XP: geht
2000: geht nicht

[kalmi01]

Zitat:

habe ich nun mit dem computernamen probiert.
XP: geht
2000: geht nicht

Tja, dann weiss ich auch nicht weiter.
Wie ich schon sagte, Win2000-PC waren nur (sehr) wenige bei mir im Test, da wir 2K übersprungen haben (schade).
Mit SP2 und allen/letzen Patches gehts bei mir.

Aber vielleicht kriegst Du es ja raus, woran es liegt :wink:

[Christian Seehase]

Moin Zusammen,

ich habe das gerade mal ausprobiert beide angesprochenen Privilegien zu aktivieren:
Unter XP SP2 und W2K SP4 hat das geklappt, dennoch schlägt der Aufruf von LogonUser unter W2K fehl (Der Client besitzt ein erforderliches Recht nicht) :gruebel:
Vorhanden sein müssen die Privilegien, sonst könnte ich sie nicht erfolgreich aktivieren.
Irgendwie scheint in der Dokumentation eines (oder mehrere) zu fehlen. :?

[MathiasSimmack]

Zitat:

Zitat von TeronG

Zitat:

Zitat von MathiasSimmack

so dass man sie mit wenig Aufwand in eigene Programme einbinden kann.

[...]
also ich würd ja sagen, daß der Code eh schon recht simpel/kurz/unaufwändig ist. Quasi nur eine if abfrage (mit einer if abfrage) und schon kannste deinen code reinschmeißen.

Das habe ich nicht gemeint. Ich dachte an eine Zusammenfassung der Funktionen, so dass der Entwickler letztlich in seinem Programm auch nur eine if-then-Abfrage einbaut. Allerdings sollte er/sie sich nicht darum kümmern müssen, welche Units oder API-DLLs ggf. einzubinden sind, auf welchem OS das ganze läuft, usw.

Ein an den Haaren herbeigezogenes Beispiel: Ich schreibe ein 08/15-Programm, das an einer bestimmten Stelle zwingend etwas in der Registry unter HKLM speichern muss. Ich rufe an dieser Stelle im Programm die (noch fiktive) Funktion "RunAsDialog" auf. Diese Funktion stellt fest, dass ich bereits Admin-Rechte habe und führt den gewünschten Programmcode aus.
Bei einem Einsatz als Benutzer würde an der gleichen Stelle ein Dialog angezeigt werden, der mich auffordert, ein Admin-Konto zu wählen und das Passwort anzugeben. War das korrekt, erlangt das Programm die notwendigen Rechte und kann den Code ebenfalls speichern.
Da es sich um ein 08/15-Programm handelt, könnte auch jemand auf die Idee kommen, es unter Windows 98 einzusetzen. Hier würden die NT-spezifischen Funktionen u.U. Fehler verursachen und im schlimmsten Fall das Programm sogar beenden oder am Programmlauf hindern, obwohl das Speichern in HKLM hier gar kein Problem ist.

Der Entwickler, der so eine Bibliothek verwenden möchte, muss sich im Normalfall also um nichts weiter kümmern. Er ruft nur die Funktionen auf, den Rest erledigt die DLL intern. Und unter Systemen wie Windows 98 kommt es zu keiner Störung im Programmlauf, weil die Funktionen dann generell immer true (oder was weiß ich) zurückgeben, bzw. die nicht vorhandenen NT-Funktionen gar nicht erst aufrufen.

Aber egal, es war eben nur so eine Idee, geboren aus Langeweile ... :stupid:

[CodeX]

ich finde die idee sehr gut. sowas in der art gibt es für delphi nocht nicht. brauchen tuns aber viele.
wichtig wäre aber, dass sich das ganze aber trotzdem noch anpassen ließe. also dialog (ob nun VCL oder non-VCL) und wo und wie (verschlüsselt) die admin daten ev. gespeichert werden.
ganz nebenbei müsste erstmal das problem mit W2K geklärt werden. ob das an den privilegien am token oder sonstwo liegt...

stellt sich nur die frage, ob jemand die erforderlichen kenntnisse besitzt, sich die zeit nimmt und sich die arbeit und mühe macht. :coder:

[MathiasSimmack]

Über das Konzept muss man noch reden. Und für mich stellt sich nicht die Frage, ob jemand mit den Kenntnissen diese Arbeit übernimmt. Für mich stellt sich die Frage, ob die hier interessiert Schreibenden willens sind, daran mitzuwirken. Fehlende Kenntnisse von irgendwas hat mich noch nie davon abgehalten, es dennoch zu versuchen :zwinker:. Ich dachte sowieso an eine Art Gemeinschaftsprojekt, bei dem jeder etwas beisteuern kann.

[Dezipaitor]

ja sowas wäre echt gut.
Das Programm nutzt immer nur dann höhere Rechte, wenn diese notwendig sind.

z.b.

Delphi-Quellcode:

unit SimpleRights

type
   TRightInfo = record
     noch ein paar Infos hier über die Rechte
   end;

   TOnPrivExecute = procedure (Sender: TObject; RightsInfo : TRightsInfo; UserData : Pointer) of object;

{Führt OnPrivExecute aus auf zwei Wegen aus:
1. Der Benutzer hat bereits die notwendigen Privilegien => OnPrivExecute wird einfach aufgerufen
2. Der Benutzer hat nicht die notwendigen Privilegien =>
     Ein LoginDialog wird angezeigt und im Erfolgsfall wird OnPrivExecute aufgerufen.
     
}

function ExecutePrivilegedUser(Sender: TObject; OnPrivExecute : TOnPrivExecute; UserData : Pointer; <*> ForceShowLoginDlg : Boolean = false) : Boolean;
...
<*>Hier sollten weitere Parameterstrukturen rein,
die es ermöglichen anzugeben, welche Privilegien (Administrator?) nötig sind, um OnPrivExecute auszuführen.
Sowie die Dialogeinstellungen.



function ExecutePrivilegedUser(Sender: TObject; OnPrivExecute : TOnPrivExecute; UserData : Pointer; <*> ForceShowLoginDlg : Boolean = false) : Boolean;
var
  AdminToken : Cardinal;
begin
  hier noch überprüfen ob Benutzer genug Rechte hat
  ---> aber wie? vermutlich dieser link:
  [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/accesscheck.asp[/url]

und ggf. den RunAsDialog (selbstgemacht) anzeigen für die Eingaben (<USERNAME,<DOMAIN>,...)
  
   
if LogonUser(PAnsiChar(<USERNAME>),        // UserName
             PAnsiChar(<DOMAIN>),          // Domäne oder lokaler Rechner
             PAnsiChar(<PASSWORD>),        // Password
             <LOGON32_LOGON_BATCH or LOGON32_LOGON_NETWORK or LOGON32_LOGON_INTERACTIVE>,
             <LOGON32_PROVIDER_DEFAULT>,
             AdminToken)
then begin
       if ImpersonateLoggedOnUser(AdminToken)
       then begin
              // hier kommt Dein Prog.-Code hin
              try
                OnPrivExecute(Sender,...,UserData);
              finally 
                RevertToSelf;              // zurückschalten zum angemeldeten Benutzer
              end;
              
            end;
     end;
end;






unit FormTest;
...

procedure TForm.OnMyPrivExecute (Sender : TObject; RightsInfo : TRightsInfo; UserData : Pointer);
begin
  //hier mit anderen Rechten arbeiten
end;

procedure TForm1.ButtonClick(...)
var MyData : Pointer;
begin
  MyData := nil;
  if ExecutePrivilegedUser(Self,OnMyPrivExecute,...[benötigte Rechte],MyData) then
    //ok
  else
    //abbruch
end;

Was haltet ihr von dieser Hülle?


Hier noch ein paar must see links:
http://msdn.microsoft.com/library/de..._reference.asp
http://msdn.microsoft.com/library/de..._functions.asp

Wie man Adminrechte erkennt:
http://www.delphi-fundgrube.de/faq13.htm#topic1315

[Dezipaitor]

gibts hier noch etwas zu sagen?

[CodeX]

Die Rechte kann man zb mit IsAdmin prüfen. (Zumindest, ob Admin-Rechte vorhanden sind.)

Aber meiner Meinung nach ist das "Projekt" hier absolut uninteressant, solange es nur mit Win XP richtig funktioniert.
Es sollte noch mindestens Win2000 dazukommen, dann kann man weiter dran arbeiten. Aber das hat ja bisher noch keiner hinbekommen. (?)

[Dezipaitor]

Nanu?

Ich dachte unter den meisten Windows 2000er funktioniert es?

[CodeX]

Außer kalmi01 und mir hat sich ja sonst niemand dazu geäußert. Bei ihm ging es bei ein paar wenigen Tests scheinbar.
Bei mir gings gar nicht. Microsoft meint auch, dass es unter Win2000 nicht gehen sollte. Siehe meinen Post hier. (Wenn ich das richtig verstanden habe, und wenn MS Recht hat, mit dem was da steht.)

Von Luckie meine ich irgendwo mal gelesen zu haben, dass bei W2K das Problem besteht, das Admin-Token zu holen und es deswegen nicht geht. Aber ich würde mich ja freuen, wenn ich mich irre und es doch irgendwie geht.

[Dezipaitor]

ich werd noch verrückt.

Sobald ich ImpersonateLoggedOnUser aufgerufen habe - was kann ich dann alles machen?

Sagen wir mit LogonUserW habe ich davor den Administrator eingeloggt.

Jetzt könnte ich doch mit CreateProcess usw die Verwaltung (über Explorer) als Administrator starten. Aber das funktioniert nicht.
Ich habe nicht genug Rechte, wenn ich z.b. Computername ändern will.

Delphi-Quellcode:

if LogonUserW(PWideChar(LoginData.UserName),        // UserName
             PWideChar(LoginData.DomainName),          // Domäne oder lokaler Rechner
             PWideChar(LoginData.Password),        // Password
             {<LOGON32_LOGON_BATCH or LOGON32_LOGON_NETWORK or LOGON32_LOGON_INTERACTIVE>}LoginData.LogonType,
             {<LOGON32_PROVIDER_DEFAULT>,} LoginData.LogonProvider,
             AdminToken)

then begin
if ImpersonateLoggedOnUser(AdminToken)
if not CreateProcessAsUser(
      AdminToken,            // client's access token
      'c:\windows\system32\cmd.exe',              // file to execute
      nil,nil,nil,true,0,nil,nil,lpStartupInfo,lpProcessInformation) then
  ShowMEssage(SysErrorMessage(GetLastError))

->> Der Client besitzt ein erforderliches Recht nicht.

Muss ich da irgendwas machen?

Ich dachte nach ImpersonateLoggedOnUser, hat der Prozess (MainThread) alle Rechte des Benutzers ( hier Admin) ???

was mache ich falsch?


ich hab das Beispiel verwendet:
http://msdn.microsoft.com/library/de...ess_in_c__.asp

[edit=SirThornberry]Delphi-Tags gesetzt. Mfg, SirThornberry[/edit]

[Dezipaitor]

Kann es sein, dass man höhere Rechte benötigt, um in die Rolle eines tiefergelegenen Users zu schlüpfen?

Also z.b. Systemrechte, um als Administrator sich einzuloggen?