Currently I'm using LOCAL SERVICE as the user account for various regular tasks, and was wondering if it was possible to use a Virtual Account instead.
Task Scheduler seems to reject NT SERVICE\ style account names.
SnapOverflow
No you cannot. Virtual Service Accounts are designed to run Windows Services and that's it. A Virtual Service Account has its own SID and Windows periodically and automatically changes the password of the VSA for security. The account can be assigned access control entries on an ACL. However, the account is not even stored in the SAM registry hive, which is why you won't see the account in most administrative tools.
From Chatper 6 of Windows Internals, Sixth Ed., by Mark Russinovich, David Solomon and Alex Ionescu.
Edit: It should also be noted that if a Virtual Service Account, which is running a Windows Service, attempts to access a network resource, it does so using the account of the computer it's running on, such as [email protected].
edit: Actually it depends on what you really want to achieve. Provided you want to secure resources the task is accessing with ACL - here is the way:
Ability in Windows 7 and Windows Server 2008 R2 to apply a SID to every scheduled task and use that SID to apply permissions elsewhere in the Operating System. http://blogs.technet.com/b/craigf/archive/2011/03/15/using-delegation-in-scheduled-tasks.aspx
Scheduled Tasks do have a specific SID
edit: Added descripton for link.
You can't run it as a virtual user account. But you can run it with a virtual group account. (But since that that "group" has a 1:1 relationship with the task, it effectively is a user).
Lets say you run your scheduled task as the Local Service user. That group has a series of SIDs in its token:
Local Service:
S-1-1-0)S-1-2-0)S-1-5-11)S-1-5-32-535)Task Scheduler runs tasks with an additional SID that computed from the tasks's name.
S-1-5-87NT TASK\[Task Name]The relative id
87comes from the constant defined inwinnt.h:You can manually "hash" a task name into an SID by running:
The task doesn't have to exist; it shows you the SID it will use when a task with that name runs.
The quick brown fox jumped over the lazy dogS-1-5-87-2312335432-65297056-3549082870-2589977271-250352331NT TASK\The quick brown fox jumped over the lazy dogThis means that when your scheduled task runs, it will have a new SID in it's security token:
Local Service:
S-1-1-0)S-1-2-0)S-1-5-11)S-1-5-32-535)S-1-5-87-2312335432-65297056-3549082870-2589977271-250352331)With the tag of this new group SID in the token, you can edit the permissions on files and folders so that only the scheduled task can access them:
Bonus Chatter
Kudos for running your tasks as
Local Service- that is the right choice. It is a special row-rights account, which nobody can login as, and has no rights (aside from the same rights "anonymous" users get) on the network. Many "security experts" have it in their head that tasks need to be run with a special account they create in Active Directory with a complex random password. It makes me so crazy that these people don't understand the basics of security.Bonus Reading