4

I am trying to troubleshoot an issue on a Windows 2008 server where running attempting to connect to a "Timberline Data Source" ODBC driver crashes if the call is in a "service" context, but succeeds if the call is initiated manually in a Remote Desktop session.

I have set the service to run as my user.

I'm wondering if, all else being equal (user, machine, etc), are there any fundamental security/environment differences between running a process as a service vs manually?

--- Implementation Details ---

In case it is helpful for anyone, I had a system that started as an attempt to connect to a Timberline Database using ODBC and a Python CGI script called via IIS 7. The script itself works fine, however, as soon as I attempt to perform the ODBC connect function, the script crashes without throwing an exception. The script was able to connect fine when executed via command line.

The same thing happened when using a C#/.net service, attempting to run via Apache, Windows Scheduler or even a 3rd party scheduling tool.

With the last option (the 3rd party scheduling tool, pycron) The service is configured to log in as my domain user and had the same issue (I confirmed via Task Manager that the process running user was, in fact, me).

Also, if it's important, the Timberline DSN is configured to locate the database via UNC ("\\timberline-server\Timberline Office\Accounts\AT" or something to that effect)

The DSN is set up at the "System DSN" level which, according to the ODBC Administration Tool, means that the DSN is available to users and services

I also realized that, as Joel pointed out, the server DOES have a mapped drive ("Y:" which is mapped to "\\timberline-server\Timberline Office")

zashu
  • 143
  • 6
  • Does it depend on any mapped drives or other things that do not run until you log in? – Joel Coel Sep 06 '12 at 17:48
  • Not that I am aware of. The database is on a network computer (not referenced via a mapped drive) and the ODBC DSN is listed under "System DSN" so I'm assuming it's persistent. Is there a way to tell using procmon or anything like that? – zashu Sep 06 '12 at 17:59
  • ACTUALLY: It might. While the DSN refers directly to the network machine location ("\\timberline-server\Timberline Office\Accounts\AT") I am noticing that I do have "Timberline (\\timberline-server) (Y:)" showing in "My Computer". I'm not super familiar with network drives, unfortunately, but does this sound problematic? – zashu Sep 06 '12 at 18:07

3 Answers3

2

It looks like the database is on the share. By default service is running under System on Network account and most likely does not have access to share where database is. When you run it under your account, script can access database because you can access windows share.

Serhiy
  • 174
  • 1
  • 1
  • 9
  • That was one of the things that I tried. However, I can get the service to log in as my user (and the service process shows as running as my user). In addition, I was able to test file permissions by attempting to open a file. While an important troubleshooting step, it isn't my issue. – zashu Sep 06 '12 at 19:18
  • From post [here](http://www.unlockthedata.com/ax_ODBC_Setup.htm) I see that DSN is per user. – Serhiy Sep 06 '12 at 19:45
  • Also a good point, but the DSN is configured at [System level](http://webcheatsheet.com/asp/dsn.php) which should keep it safe for services (if the UI is to be trusted). Honestly, I think it was related to the mapped drive thing – zashu Sep 06 '12 at 20:32
  • Mapped drives are available only thru interactive login. Hence, services must use UNC. – Alfabravo Sep 06 '12 at 21:30
0

You'll want to set the service to run with a service account (i.e. create a user for this purpose called something like YOURDOMAIN\svc_timberline), then grant that service account rights to the folder containing the database.

It should work after that.

Driftpeasant
  • 3,207
  • 2
  • 20
  • 28
0

As some users mentioned, mapped drives are only set up through an interactive login session, i. e., not available in background services. After looking into this, I realized that, while my DSN referred to a network location via UNC, the actual ODBC connector was designed to refer to a mapped drive.

Since it wasn't possible for me to alter the driver configuration in this instance, I was able to update my service to map the drive on the fly. Thus, when my python script was called, it would map the drive prior to calling ODBC connect which, in turn, resolved the crash.

If anyone is having a similar problem, I used these python functions to map the drive in my script.

Thanks for all of the help!

Community
  • 1
zashu
  • 143
  • 6