 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General / January 2010RunAs using a DCOM Client/Server app
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 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 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 [quoted text clipped - 6 lines] > 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! ¤ 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) 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 :((( ¤ 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) ¤ 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) Paul Clement ha scritto: > ¤ Hi all, > ¤ [quoted text clipped - 12 lines] > 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. :(((( |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.