Delphi Services and LocalSystem account

We have a service, running under the LOCALSYSTEM account and flagged to
interact with the desktop, that loads a DLL named SYScheduler. This DLL
has a couple of threads that, one, wait for specific times to run
specific jobs, and two, run the jobs, either by calling a function in
another DLL or running an external executable.

We have found that, any time it is trying to run the external
executables, the executable is erroring out, no AV or anything, just the
big dialog that asks if you want to send info to Microsoft, we are
running mostly on XP but will be having to support Vista soon.

Most of these executables are written in Delphi but some are
third-party
exes.

If we run the service under an administrator account, they work
just as planned.

We used to do this using MSSQL Server Agent; but since M$ removed Agent from
SQL2005, we had to create our own scheduler.

SQL Server Agent ran these same executables just fine running in the
LOCALSYSTEM account, why the difference?

Anyone come across this before? What is the cause?
Any idea how to diagnose the reasons behind this and work out what is
going wrong?
LVL 26
Eddie ShipmanAll-around developerAsked:
Who is Participating?
 
ziolkoConnect With a Mentor Commented:
all processes created by give process are running in same user context as calling process, in other words if your service is running as local system all execs it will spawn will also run as local system.
local system account has many limitations so your behaviour may depend on what those apps do, this is not really solution for you but maybe it will ring some bells

ziolko.
0
 
developmentguruConnect With a Mentor PresidentCommented:
Run the service with a higher level access account.  Your service may need to run as an administrator or super user.
0
 
TheRealLokiConnect With a Mentor Senior DeveloperCommented:
You could try "ImpersonateUser" to run the process as another authorised user
0
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

 
RemkoEBConnect With a Mentor Commented:
The applications you ran might not have access to the Desktop.
Use this to run your process in the console session:
uses
  Windows, SvcMgr,
  JwaWtsApi32;

...

var hToken: THandle;
  si: _STARTUPINFOA;
  pi: _PROCESS_INFORMATION;
begin
  ZeroMemory(@si, SizeOf(si));
  si.cb := SizeOf(si);
  si.lpDesktop := nil;
 
  if WTSQueryUserToken(WtsGetActiveConsoleSessionID, hToken) then
  begin
    if CreateProcessAsUser(hToken, nil, 'cmd.exe', nil, nil, False,
      CREATE_NEW_CONSOLE or CREATE_NEW_PROCESS_GROUP, nil,
      nil, si, pi) then
    begin
      // Do some stuff
    end;
  end;
  Self.DoStop;
end;

JwaWtsApi can be found in the Jedi ApiLib project (http://jedi-apilib.sourceforge.net/)
0
 
Eddie ShipmanAll-around developerAuthor Commented:
Hmm, will take a look at it.
0
 
RemkoEBCommented:
You need to test if from a service because only SYSTEM account has permissions to execute WTSQueryUserToken. WTSQueryUserToken obtains a full access user token so you can in fact just execute something in a specific terminal session. In this case the console (glass screen) session which is the interactive logged-on user.
0
 
Eddie ShipmanAll-around developerAuthor Commented:
I am not using a console. I am running external applications.
0
 
RemkoEBCommented:
I understand.
What I meant was that starting from Windows XP you can use a Remote Desktop session to remotely connect to your system. If you logon locally this is refered to as the Console Session.
Just try the sample code, run it your service application and run your service under the SYSTEM account. This will work!
0
 
RemkoEBCommented:
Did you test?
0
 
Eddie ShipmanAll-around developerAuthor Commented:
We've decided to goa different route and use a 3rd-party solution.
0
All Courses

From novice to tech pro — start learning today.