Time based event, console application on Windows Server -- security implications

Question

I'm a software engineer, and I've written several discreet utilities that run at specific times on Windows Server 2008. Generally speaking, they are console applications, need to access SQL Server, are configured for trusted access and are running under a service account.

Our security folks tell me I need to re-architect these since they don't wish to allow local logon to the service accounts. They suggesting I create Windows services which will be run by the service account with trusted access to the database.

As a programmer, running a service that waits for a specific time of day to do some work seems like an anti-pattern, and it's harder to debug issues. But if it's more secure I'm happy to get behind it -- thoughts?

Answer 1

If your applications run at specific times, then they must make some allowance for the fact that they may run at times when there is nobody to see them running. This means that you must have some logging system (e.g. using Windows events, or simply by writing into some files). Your debugging should go that way.

Anyway, though writing your own service is not hard, reinventing the wheel is always wasteful. In that specific case, Windows offers a specific task scheduler which is perfectly able to launch your applications (even scripts or console applications) at configurable times, starting in a configurable directory and running under a configurable account. Moreover, there is a specific local policy (called "log on as a batch job") which controls which account(s) may be used for that. This ought to appease your local security people.

(Of course, in many places, there are people with more power than knowledge, who will force you to perform elaborate somersaults through many hoops because of some irrational fear they have. Though the Windows task scheduler is the method recommended by Microsoft to launch tasks at programmable times, you might have to write your own service because otherwise some guy will go into uncontrollable fits -- and be warned that the same guy will deny everything in the event that the loss of time, flexibility or money induced by this needless re-engineering is noticed by somebody in upper management.)

Answer 2

It is a good idea not to have your service accounts able to login to the computer interactively since they could then be misused if compromised more easily. A slightly better ideal might be to run a simple scheduler service as the service user that would call your command line tool. If memory serves, it isn't the console application that requires local logon, it is the scheduler you are using trying to launch as another user.

I believe running the scheduler as the service should let you avoid the local logon without having to rewrite your tool, so long as it doesn't require interaction with the user console.