run as "NT AUTHORITY\SYSTEM" is ideal for scheduled tasks?

Question

I have a backup / autoupdate process for my software, and usually I create a new user for running it in task scheduler (most users don't have a password, and task scheduler needs it, don't know why).

Then I've seen that google chrome installs it's auto-update task to run as "NT AUTHORITY\SYSTEM", I've tested it and it works great with my programs too, and it looks more clean,

there are some hidden drawbacks here I'm not seeing?

Thanks!

Solution

My recommendation

For a single machine, the most straight forward method is to create an account under the Builtin Backup Operators group.

There are two large drawbacks that initially come to mind when running programs under SYSTEM.

Security

Almost always the biggest reason admins create discreet accounts for scheduled processes is to monitor them and grant them access one would normally not grant to a typical running application. In this case, it needs read access to all files and needs write access to your backup storage location, the later tending to have more strict access.

To give any program that runs as SYSTEM amounts to running them as an admin more or less, thus granting it more privileges than it needs. There is a built in Backup Operators group for this reason.

UAC

The SYSTEM account is sometimes mistaken by users as a SuperUser or a root account. It is neither. It is used internally by Windows. It was never intended to be used by programs unless the program specifies it. That said, there are unknown bugs that creep up if running a program not designed for the SYSTEM account. For one, notice there is no user password for it. Nor is it actually a user account if you try to authenticate to it remotely.

---

Anecdotally,, UAC also plays havoc with programs that run under the SYSTEM context. I've seen badly written programs straight up throw up a dialog asking the user to "run as Admin." Go figure.

Also there is an MSDN blog post that comes to mind that I cannot find that the author spent a whole day debuggging SQL Server on a client's machine. Fresh install . . . or so they thought. Turns out, a certain component of the OS itself was switched from NT AUTHORITY\NETWORK SERVICE to SYSTEM, under the guise that it had a more permissions and privileges than any other account. Rather, it just has different ones.