Prev: easy I hope: how to copy and paste a textbox control (designtime)
Next: Sendkeys not working for an uninstall
From: Ataru on 28 Jan 2010 11:42
Paul Clement ha scritto:
> 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.

I need to launch the external application (i.e. notepad just for testing
purposes but, in the final release, it'll a 3rd party customized
application) because:

1) the external application needs to be run as administrator
2) the user who'll start and use it is not an administrator and, of
course, must not know admin credentials
3) those credentials will be different from one workstation to another
(different passwords but same username on all of them) and they must not
be hardcoded in the project (vb code)
4) because of pt.3, I thought that a DCOM or Windows Service approach
would be fine, since you can configure identity through snap-ins (so you
can type and store elevating credentials in a more secure way)
5) because of pt.4, the DCOM serverside application or a Windows Service
runs with the proper grants (admin grants: the ones that are specified
by dcomcnfg or services.msc) and - consequentelly - the serverside app
or service can launch the external app, because they automatically know,
load and use the elevating credentials


Of course, if unprivileged user launches psexec with the proper
parameters (elevating credentials and application binary) everything
goes well: the elevated app (i.e. notepad) is properly displayed even if
it's running as elevated user. Unfortunately, as I previously wrote, the
unprivileged user must not know elevating credentials.

:((((
From: Ataru on 28 Jan 2010 11:44
Paul Clement ha scritto:

> 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.

I'll try, but if I'm not wrong LogonUser requires that you hardcode the
username and password and provide them to the function. Unfortunately,
this scenario does not fit my requirements :(((
From: Paul Clement on 28 Jan 2010 13:21
On Thu, 28 Jan 2010 17:44:06 +0100, Ataru <ddd(a)ddd.ddd> wrote:

� Paul Clement ha scritto:
�
� > 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.
�
� I'll try, but if I'm not wrong LogonUser requires that you hardcode the
� username and password and provide them to the function. Unfortunately,
� this scenario does not fit my requirements :(((

You don't have to hard-code the credentials. You can encrypt the credentials and store them
elsewhere (either the Registry or app config file) so that they are almost impossible to figure out.


Paul
~~~~
Microsoft MVP (Visual Basic)
First  |  Prev  | 
Pages: 1 2
Prev: easy I hope: how to copy and paste a textbox control (designtime)
Next: Sendkeys not working for an uninstall