From: Ataru on
Hi all,


I recently needed to develop a DCOM client/server application to execute
an external application as the user whose identity is configured through
dcomcnfg (this user is a local administrator of the machine that hosts
the server side of the application).
The client side is made by a button that invokes the server to launch
the external application (i.e. notepad.exe).

I have a big problem: when the client is executed, then notepad.exe is
properly started and shown inside Task Manager but, unfortunately (and I
obviously think that this issue is related to security context matters),
I can't see it interactively.

I'm a newbie to VB (and, generally speaking, to developping :)) and I
just don't know how to solve my problem. I'd be very grateful if someone
would help me :)

So...Is there a way to make the launched application interactive (such
as, for example, a task that is runned by "at" command)?

Thanks in advance!




Here's the code:


---client side---

Private Sub Button1_Click()
Dim exObj As DCOMRunAs_Srv.Class1

Set exObj = CreateObject("DCOMRunAs_Srv.Class1")
MsgBox "Execution timestamp: " & exObj.execAsAdmin
End Sub




---server side---

Public Function execAsAdmin() as String
Dim notepadPID As Integer

notepadPID = Shell("C:\Windows\notepad.exe", vbMaximizedFocus)
execAsAdmin = Time
End Function
From: Nobody on
Which version of VB are you using?

Since you are new to VB, I recommend that you use PsExec tool to run what
you want interactively using "-i" command line option. Try this tool in a
Command Prompt to see if it runs Notepad fine. This is ok for in-house
solution. If it's for general use, then you have to use something else,
because PsExec is not redistributable. You have at least make it a
requirement for your software, and tell the user that they have download it
separately.

PsExec:
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

The API solution could be complicated for you. First you call
WTSGetActiveConsoleSessionId(requires XP+), then WTSQueryUserToken(), then
CreateProcessAsUser(). This is assuming that someone is actually logged in
to the console. Also, the call to WTSQueryUserToken() could fail unless the
caller is running as SYSTEM. I think Administrator is not enough.

Yet another option is to use Task Scheduler which has a COM interface. Look
in MSDN for "ITaskScheduler". I think that IScheduledWorkItem::Run can be
used to run a task immediately, even if the task is disabled. If you want to
run a task as SYSTEM, specify "SYSTEM" as the user id, and leave the
password blank.

For a VB6 sample, see "Using the Task Scheduler" sample at this link:

http://www.mvps.org/emorcillo/en/code/vb6/index.shtml


From: Ataru on
Nobody ha scritto:
> Which version of VB are you using?

VB6sp6 Enterprise Edition

> Since you are new to VB, I recommend that you use PsExec tool to run what
> you want interactively using "-i" command line option. Try this tool in a
> Command Prompt to see if it runs Notepad fine. This is ok for in-house
> solution. If it's for general use, then you have to use something else,
> because PsExec is not redistributable. You have at least make it a
> requirement for your software, and tell the user that they have download it
> separately.
>
> PsExec:
> http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

I know psexec and its features :)
Unfortunately, I must implement my solution on -about- 50 workstations
and, because of corporate security policies, each workstation has its
own administrative account with, of course, a different password value
for each workstation.
Moreover, the "launching user" is obviously not an administrator and
must not know the elevated credentials, so the user has only to click on
the client side and not to know the implementation details :)

Our ICT team will install the server side and assign, machine by
machine, the proper administrative credentials inside dcomcnfg.

Maybe now the situation is clearer :)

> The API solution could be complicated for you. First you call
> WTSGetActiveConsoleSessionId(requires XP+), then WTSQueryUserToken(), then
> CreateProcessAsUser(). This is assuming that someone is actually logged in
> to the console. Also, the call to WTSQueryUserToken() could fail unless the
> caller is running as SYSTEM. I think Administrator is not enough.

Yes of course, there will be an unprivileged user logged interactively
on the console. That user should activate and use the client side to
invoke the elevated application through the server side.

> Yet another option is to use Task Scheduler which has a COM interface. Look
> in MSDN for "ITaskScheduler". I think that IScheduledWorkItem::Run can be
> used to run a task immediately, even if the task is disabled. If you want to
> run a task as SYSTEM, specify "SYSTEM" as the user id, and leave the
> password blank.

Yes...I know and already tried this kind a solution by creating a
Windows Service in VB.Net, assigning it the localsystem account as the
launching user and activating interaction checkbox. This solution works
because - whenever the service is started - the application shows on the
desktop of the currently logged user.
But...Because of the same corporate security policies, we couldn't run a
"custom service" as localsystem :(((

It looks like an application can be made interactive only if it runs as
localsystem...This doesn't fit my requirements :(


> For a VB6 sample, see "Using the Task Scheduler" sample at this link:
>
> http://www.mvps.org/emorcillo/en/code/vb6/index.shtml

I'll certainly surf this site, thanks!
From: Paul Clement on
On Wed, 27 Jan 2010 18:33:51 +0100, Ataru <ddd(a)ddd.ddd> wrote:

� Hi all,


� I recently needed to develop a DCOM client/server application to execute
� an external application as the user whose identity is configured through
� dcomcnfg (this user is a local administrator of the machine that hosts
� the server side of the application).
� The client side is made by a button that invokes the server to launch
� the external application (i.e. notepad.exe).

The bottom line is that you shouldn't be running interactive applications from non-interactive
processes such as services, web apps, web services and COM+ applications. The key issues are
security, the inability to respond to application prompts and threading limitations.

I'm not sure why you need to launch Notepad from DCOM (security context maybe?) but I would
definitely consider doing this from the client application instead.


Paul
~~~~
Microsoft MVP (Visual Basic)
From: Paul Clement on
On Wed, 27 Jan 2010 22:20:00 +0100, Ataru <ddd(a)ddd.ddd> wrote:


� Unfortunately, I must implement my solution on -about- 50 workstations
� and, because of corporate security policies, each workstation has its
� own administrative account with, of course, a different password value
� for each workstation.
� Moreover, the "launching user" is obviously not an administrator and
� must not know the elevated credentials, so the user has only to click on
� the client side and not to know the implementation details :)

� Our ICT team will install the server side and assign, machine by
� machine, the proper administrative credentials inside dcomcnfg.

� Maybe now the situation is clearer :)

Just to follow-up on this, can you use the LogonUser and ImpersonateLoggedOnUser API function calls
to temporarily elevate security in your code? Below is an example for ASP but it uses a VB 6.0
component containing code that you should be able to use in your application.

http://support.microsoft.com/kb/248187


Paul
~~~~
Microsoft MVP (Visual Basic)