Running a Service Script with Both Interact with Desktop and Network Access

Question:

Has any progress been made on the previous service limitations (you can't read environment variables, etc)? Also, what exactly does "can't interact with the desktop" mean? Does it just mean you can't ask users for input boxes, display messages, etc and that's it?

Finally, what do people typically do as far as the account the service runs with? What if you need network access and desktop interaction - are you only limited to one of the other and that's it? Wouldn't a local or domain adminstrator account be able to do both, or is this a Windows security limitation?

Answer:

A native NT service [any service, not just a WinBatch script running as a service] has 2 possible configurations:

Run as the Local System account and be allowed to access the interactive desktop by sacrificing access to network shares [except for NULL-session enabled shares].
Run under a specific account and have access to network resources as that account by sacrificing access to the interactive desktop.

Those are your choices and they are enforced by the design of WinNT/2K/XP/03.

To complicate things, there's actually some additional special case configurations involving new built-in accounts like "Local Service" and "Network Service" on WinXP & newer, but we won't worry about those here.

Your service script could run under a specific domain account and it could access the current copy of the login script on a remote network share in order to copy it locally. Just because your script lacks access to the desktop doesn't mean it can't communicate with the login script if the login script is left running continuously. Your login script could periodically poll the registry or a .INI file looking for a value that would cause it to restart itself if necessary, or else look for the existence of a file that does the same thing.

User Reply:

Ah - Null shares! I forgot about that. That's exactly what I need. My service can run as localsystem (to be able to interact w/desktop), and the seperate winbatch script that the service calls and keeps up-to-date (which is located on the network) can just be put in a null share.

Will this work - have the service run as localsystem, but only "do stuff" when a user is logged in. In other words, the service would check to make sure the machine is NOT locked or logged out before firing off the seperate script that does all of my settings and stuff (including accessing the network). This way, it will be able to access the network (as the logged in user) and interact with the desktop. Or is anything started as localsystem NOT allowed to access the network period end of story no matter if a user is logged in or not?

Answer:

Having the service detect the presence/absense of a window named "Program Manager" will tell you if anybody is logged on to the system console, but it won't tell you if the workstation is locked.

As for running as Local System and accessing a NULL session share, yes, a script can do that. You simply need to set up your script to run properly as a service and then enable NULL sessions on the share that script is going to access while running as a service.

User response:

I was under the general impression that enabling null session shares was basically the same as allow full access to the target system, not just the share intended.

Answer:

No, not really. It all depends on how your NTFS & share permissions are set up. Obviously, it would be a bad idea to do this to the C$ or Admin$ shares on a system that has default permissions [WinNT or Win2K]. WinXP is better about the default "Everyone - Full Control" issue, but not perfect.

You simply go into the registry and add the share name to the list of NULL Session Shares. Then, when the "server" service starts up, it will accept connections to those shares from remote users that are lacking an access token. Users who have authenticated have an access token, and the defintion of "NULL Session" is session on a NT/2K/XP/03 system that never authenticated and thus has a NULL pointer where the pointer to an access token would be located.

If the share that is to be NULL session enabled is an isolated folder with read-only access for "Everyone", then there shouldn't be any serious security concerns. Just don't enable NULL sessions for any shares that share out the root of the boot drive or the directory where Windows is installed and you shouldn't get yourself in trouble. Also, don't do this for any shares that provide access to program files that execute on the server where the share itself is located. The reason for this is that a NULL session share that is not properly protected from write access can very easily be infected with a virus as infected workstation on the network could then access the share and propagate a virus to any executable files on the share.

Due to a restriction enforced by Windows NT on services, the application can either be interactive (have a Console, read keyboard input etc.) or have network access (not both at the same time).

This limitation is less problematic than it would appear at first glance. Here is why:

If you know which servers your interactive service application needs to access, it is possible to configure these servers (or selected shares on them) to allow your service (running under the LocalSystem account) to access these servers.

a. To allow LocalSystem services on any machine in the domain to access a specific share on a server, use the Registry Editor to add the name of that share to:

        
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionShares

If named pipes on that server also need to be accessed by LocalSystem services, add them to:

        
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes

b. To allow ALL shares & pipes on the server to be accessed by LocalSystem services, add a value:

        
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RestrictNullSessAccess, type DWORD, set to value 0
WARNING: method b) effectively allows everyone in the domain to access that server - make sure this is acceptable for you.













Article ID:   W16676

File Created: 2005:02:18:12:21:50
Last Updated: 2005:02:18:12:21:50

Database Search

TechHome