Re: Mapping network resources from a service

From: Chuck Chopp (ChuckChopp_at_rtfmcsi.com)
Date: 02/09/05 

Date: Wed, 09 Feb 2005 08:45:51 -0500

Stephane Grobety wrote:

> Thank you for your answer,
>
> Well, here is my analysis: windows works with two concepts: Windows
> stations and desktops. here is MS's description of both concept:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc
> /base/window_stations.asp
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc
> /base/desktops.asp
>
> In short, I think I need to create a new windows station for each
> batch. Now comes the question: how ?

No, that's nowhere near the target you should be aiming for. The
windowstations & desktops have to do with where GUI applications get their
windows placed and in grouping those windows together for purposes of
sending Windows messages to them. Multiple windows can be tied to a
desktop, and multiple desktops can be tied to a windowstation. Only one
desktop on a windowstation can have keyboard & mouse focus at any given
time, but there can one virtual keyboard & mouse associated with each
windowstation when working in a TS environment. All of this has absolutely
nothing to do with the scoping of mapped network resources.

Let's drop back and look at this again.

You state that you need to use the S: and T: drive letters for your Win32
application that is being run as a child process by a service. Can your
application make effective use of environment variables, or does it read its
configuration from command line parameters or the registry? I'm simply
curious as to whether or not you can "fake it out" by substituting a UNC
path in an env var or in the registry just before launching the application.

After reading your additional explanation of Win2K in TS remote admin mode
vs. TS application server mode, I'm surprised at the behavior. In remote
admin mode, TS simply allows only 2 TS sessions to exist, but each one gets
its own separate session id. In application server mode, TS allows more
than 2 TS sessions, with the limit being set by your session licensing
configuration. Regardless of the mode, though, TS is still TS. If the
server is in remote admin mode, I'd expect things to behave properly when
running the application via an admin TS session, and I'd expect it to break
when run from the console session.

I'd post a graphic file showing a venn diagram representing the scoping
rules, but binary attachments are frowned upon here. A TS session sets a
boundary. Usually, within a TS session, there's only a single security
context, so the TS session & security context represent the same boundary as
  they overlap each other completely. However, session #0 is special as the
Service Control Manager [a.k.a. SCM] runs in session #0. Given that all
services are child processes under the SCM process, every single service
runs in session #0, too. Now, within a single TS session [session #0 in
this case], your security context has much to do with the scoping since
there can be multiple security contexts within that same TS session. Each
time a process is created using a specific set of credentials, a security
context is created. All processes that exist within that security context
share the same set of mapped network resources. So, if one service logs on
as "UserA" and another service logs on as "UserB", then each of those
services runs within its security context and their mapped drive letters
don't conflict with each other as they are in separate scopes. However, if
at the system console you logon as either "UserA" or "UserB", you will
discover that the service running under the same user credentials as the
interactive user on the console will share the same security context and
will thus share the same set of mapped network resources.

In your situation, having a service use LogonUser() to estblish a new
security context and then creating a child process within that security is
doing the same thing as running separate services under those user
credentials. You end up with a bunch of child processes in TS session #0,
and each process is in its own security context. If one of those security
contexts is the same as that of the user in TS session #0 [e.g. on the
console], then you'll have a problem.

The simplest solution is to not allow the interactive portion of your
application to run on the system console. Require it to only be run from
within a TS session and you won't have this problem.

HTH,

Chuck 

-- 
Chuck Chopp
ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com
RTFM Consulting Services Inc.     864 801 2795 voice & voicemail
103 Autumn Hill Road              864 801 2774 fax
Greer, SC  29651
Do not send me unsolicited commercial email.

Relevant Pages

  • [NT] Cryptographic Flaw in RDP Protocol Can Lead to Information Disclosure
    ... The Remote Data Protocol (RDP) provides the means by which Windows systems ... The first involves how session encryption is implemented in certain ... An attacker who was able to eavesdrop on and record ...
    (Securiteam)
  • Re: Security Question
    ... This article by Mark Russinovich about "Inside Windows Vista User Account Control" might be interresting... ... is logged into that session where it's displayed. ... Similarly, there is no sharp dividing line between two windows on the same desktop - they share a communication to and from the desktop, and sometimes between themselves. ... So, no, what the original poster describes is clearly _not_ the case - two processes running in different sessions should not interfere, because there is a security boundary between them. ...
    (microsoft.public.windows.vista.security)
  • RE: Spying, admin to user login?, Is it possible?
    ... shadow session could not be created directly on Windows XP computer. ... you could active only one user session at one time ... you need to remote desktop to a Windows 2003 ... Microsoft also publishes a KB to describe this work around in detail. ...
    (microsoft.public.windows.server.sbs)
  • Re: Remote Desktop Re-Connect
    ... does not include Windows 2003 or Windows Server. ... available target OS's are appropriate for Windows Server 2003 SE SP1? ... but my recollection was that the key is to look for event log errors at the ... remote session, and my local printer is not. ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: Security context used for DBPROP_MULTIPLECONNECTIONS sessions
    ... behind using the current security context for the new sessions. ... connections and ensured that only one command is active on a session at ... >> session that already has an open command. ... >> having a dedicated thread for database access. ...
    (microsoft.public.data.oledb)