Overriding "Interact with desktop" property of service
-
We are trying to get an interactive command prompt,running with 'SYSTEM' user credentials The sequence of steps are as follows: 1) Get the local time (through the TIME shell command, for example) 2) Add one minute to this time 3) Run the AT command with this new time. 4) Wait one minute for the command window to appear. An example set is as below: E:\Documents and Settings\Adi>time The current time is: *16:29*:00.96 Enter the new time: E:\Documents and Settings\Adi>at *16:30* /interactive cmd.exe Added a new job with job ID = 1 We do get a command prompt with 'SYSTEM' privileges. Next,we attempt to do this on a remote w2003 host through REMOTE login. In this case,though we find the cmd.exe running in the task manager,we DO NOT see the command prompt in the foreground. What service/security setting prevents the command prompt to interact with the desktop in this case? We also confirmed that in certain other environments ,we do see the command prompt on the foreground ,even via remote login. Unfortunately,we have not been able to work out the security 'tweak',which obstructs our first environment from doing so. Any help will be much appreciated.
-
We are trying to get an interactive command prompt,running with 'SYSTEM' user credentials The sequence of steps are as follows: 1) Get the local time (through the TIME shell command, for example) 2) Add one minute to this time 3) Run the AT command with this new time. 4) Wait one minute for the command window to appear. An example set is as below: E:\Documents and Settings\Adi>time The current time is: *16:29*:00.96 Enter the new time: E:\Documents and Settings\Adi>at *16:30* /interactive cmd.exe Added a new job with job ID = 1 We do get a command prompt with 'SYSTEM' privileges. Next,we attempt to do this on a remote w2003 host through REMOTE login. In this case,though we find the cmd.exe running in the task manager,we DO NOT see the command prompt in the foreground. What service/security setting prevents the command prompt to interact with the desktop in this case? We also confirmed that in certain other environments ,we do see the command prompt on the foreground ,even via remote login. Unfortunately,we have not been able to work out the security 'tweak',which obstructs our first environment from doing so. Any help will be much appreciated.
rana74 wrote:
What service/security setting prevents the command prompt to interact with the desktop in this case?
Everything. Because of the MASSIVE security risk, interactive processes are not allowed to be visible when launched on remote systems.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
rana74 wrote:
What service/security setting prevents the command prompt to interact with the desktop in this case?
Everything. Because of the MASSIVE security risk, interactive processes are not allowed to be visible when launched on remote systems.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008Well this definitely does not seem to be the case for all hosts - as we have this 'interactivity' working even for remote login into most of our w2003 host environments,where we have out-of-box security settings. So,there is some security switch which 'hardens' this property - as we see in some other environments. We are eager to find out what that 'switch' is.
-
We are trying to get an interactive command prompt,running with 'SYSTEM' user credentials The sequence of steps are as follows: 1) Get the local time (through the TIME shell command, for example) 2) Add one minute to this time 3) Run the AT command with this new time. 4) Wait one minute for the command window to appear. An example set is as below: E:\Documents and Settings\Adi>time The current time is: *16:29*:00.96 Enter the new time: E:\Documents and Settings\Adi>at *16:30* /interactive cmd.exe Added a new job with job ID = 1 We do get a command prompt with 'SYSTEM' privileges. Next,we attempt to do this on a remote w2003 host through REMOTE login. In this case,though we find the cmd.exe running in the task manager,we DO NOT see the command prompt in the foreground. What service/security setting prevents the command prompt to interact with the desktop in this case? We also confirmed that in certain other environments ,we do see the command prompt on the foreground ,even via remote login. Unfortunately,we have not been able to work out the security 'tweak',which obstructs our first environment from doing so. Any help will be much appreciated.
It's very straightforward: 'interactive' services display in session 0, the 'console' session. This is the session you see when you log on on the physical keyboard/mouse/screen (or emulation of it, if you're using a virtual machine). Normally, a remote connection with Remote Desktop (Terminal Services Client) to a Windows Server OS gives you a new session. Windows Server 2003 allows you to connect to the console session by passing the
/consoleswitch tomstsc. You can also specify '/console' after the computer name in the connection dialog. This feature is only supported in Windows Server 2003; Windows 2000 ignores the setting. Other 'remote desktop' tools like VNC and LogMeIn actually give you the console session. Windows Vista and Windows Server 2008 have 'session 0 lockdown' - users log on to session 1 and above, even if logging on at the physical computer. UI created by 'interactive' services is not shown - session 0 is now only used to allow interactive services to communicate with each other. See Impact of Session 0 Isolation on Services and Drivers in Windows Vista[^].DoEvents: Generating unexpected recursion since 1991
-
Well this definitely does not seem to be the case for all hosts - as we have this 'interactivity' working even for remote login into most of our w2003 host environments,where we have out-of-box security settings. So,there is some security switch which 'hardens' this property - as we see in some other environments. We are eager to find out what that 'switch' is.
rana74 wrote:
Well this definitely does not seem to be the case for all hosts - as we have this 'interactivity' working even for remote login into most of our w2003 host environments,where we have out-of-box security settings.
Not out of the box you don't. Unless you're using a third party tool that does this to get around the limitation, like PSEXEC. Using the Win32 API, you cannot launch an interactive remote process and there is no "switch" to get around it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008