Service account has different database behavior under IIS and task scheduler

Question

I run the same script as an application account under IIS, and as a Scheduled task, and i get very different results.

From IIS (as a web page), i can read eg field properties, and run very simple queries like

SELECT * FROM SYSTEMINFO

So connection to database is there.

Anything more "advanced", gives get all sorts of errors:

SELECT SYSTEMINFOID FROM SYSTEMINFO
or
SELECT COUNT(*) FROM SYSTEMINFO
or
INSERT INTO SYSTEMINFO ( SYSTEMINFOID ) VALUES (1)

typically gives "[Microsoft][ODBC Microsoft Access Driver] Unknown (SQL-42000)" or "[Microsoft][ODBC Microsoft Access Driver] Overflow (SQL-42000)" which means "missing access or syntax error" according to some ms error message overviews (Quite broad group of errors...)

If the application account is member of Administrators, all works fine (but not a good solution), any other memberships (user, power user, backup operator) gives the same error. (need to reboot server for such changes to take effect, so debugging is time consuming.)

User has local policies to "Replace a process token", and "Adjust memory quotas" granted (as well as run as batch + service).

Environment looks the same (except that in IIS web environment is added), and i can see in task manager that the scripts are run as the application account.

connection string is

DBI:ODBC:driver=Microsoft Access Driver (*.mdb);DBQ=C:\folder\Demo.mdb;

running CGI, Perl 5.18, DBI, on IIS 8.5 Win2012 std, appliction pool uses the application account,with load user profile, and Impersonate user as True

Setting up the same on Win 2008 R2 works fine.

Connection to eg a local ms sql express database gives SSL errors, even if SSL is not in use, and using a sql account for authentication.

Spent four days on looking at all odd combinations, any suggestions for settings I may have overlooked?

(summary: when running as application account, not being an administrator under iis 8.5 the script is running, connection to database works, but anything more than trivial queries results in odd errors. )

Answer 1

Finally found a solution: in IIS 8.5, for a service account to work, the same user (as pool user) must be set as Application Pass-trough authentication.

Creating an application under the Web Site, Selecting Basic Settings for this Application, assigning it to a separate pool run by the service account was not enought.

In addtion, the "Pass-throught autentication" must be set as the same user, by selecting the "Connect as..."-button.