CreateProcessAsUser vs. CreateProcessWithLogonW

[Luckie]

Man kann ja ein Programm unter einem anderen Benutzeraccount mit CreateProcessAsUser oder CreateProcessWithLogonW ausführen. Worin liegen da die Unterschiede bzw. Vor- und/oder Nachteile?

Das PSDK sagt:

Zitat:

The CreateProcessWithLogonW function is similar to CreateProcessAsUser, except that the caller does not need to call the LogonUser function to authenticate the user and get a token.

Aber wo ist da jetzt der Vorteil / Nachteil?

[Luckie]

Ich darf es mal nach oben schieben: *schieb*

[Dax]

Wenn ich das Zitat so durchlese.. du musst eine Funktion weniger aufrufen, sonst anscheinend nichts..

[Sprint]

Zitat von Luckie:

Man kann ja ein Programm unter einem anderen Benutzeraccount mit CreateProcessAsUser oder CreateProcessWithLogonW ausführen. Worin liegen da die Unterschiede bzw. Vor- und/oder Nachteile?

Ich denke mal der große Vorteil von CreateProcessWithLogonW ist, das du dir eine Menge an Zeilen sparen kannst.
Wenn man sich das Beispiel "Starting an Interactive Client Process" unter CreateProcessAsUser im Platform SDK anschaut, ist der Unterschied an der Tipparbeit enorm. Hinzu kommt noch, das man eventuell noch manuell LoadUserProfile aufrufen muss. Ich kann mir auch vorstellen, das es irgendetwas mit Service/Dienst-Programmierung zu tun hat.

[Motzi]

Unter NT/2k benötigt man das SE_TCB_NAME Privilege um LogonUser erfolgreich aufrufen zu können. Diese Privilege besitzen allerdings nur Prozesse die in der System-LogonSession laufen - sprich Services. Ein Prozess eines normalen Benutzers bekommt per LogonUser also kein gültiges Token-Handle das er an CreateProcessAsUser übergeben kann. Bei CreateProcessWithLogonW erzeugt Windows den Token..

[Assarbad]

Zitat von Motzi:

Bei CreateProcessWithLogonW erzeugt Windows den Token..

Sicher? Nach meinen Informationen tut dies der RunAs-Dienst. Wäre dieser also ausgeschalten, dann ginge es nicht mehr. Wenn sowieso jemand gerade Code testet, kann er das ja mal verifizieren - dazu einfach den RunAs-Dienst stoppen und auf deaktiviert setzen.

[Marcel Gascoyne]

Ich hatte es damals mit CreateProcessAsUser nicht hinbekommen und habe wie im SDK beschrieben die Funktion CreateProcessWithLogonW verwendet. Hintergrund: Wir müssen bei Benutzern ohne Admin-Rechte automatisiert Software installieren.

Siehe auch ein älterer Beitrag von mir: CreateProcessAsUser

Gruß,
Marcel

[Assarbad]

Zitat von Marcel Gascoyne:

Hintergrund: Wir müssen bei Benutzern ohne Admin-Rechte automatisiert Software installieren.

Dazu existiert eigentlich MSI. Seit v2.0 hat es ja auch einen Service, an den man diese Aufgaben delegieren kann. Kann die Administration stark erleichtern

[Marcel Gascoyne]

Zitat von Assarbad:

Dazu existiert eigentlich MSI. Seit v2.0 hat es ja auch einen Service, an den man diese Aufgaben delegieren kann. Kann die Administration stark erleichtern

Schon, aber wir haben eine Netware Umgebung wo aus dem Loginscript Batchdateien aufgerufen werden. Teilweise sind dies auch normale Anwendungen die einfach Adminrechte benötigen um z.b. eine Inventarisierung des Rechners vorzunehmen.

Gruß,
Marcel