Forum Discussion
Scheduled Task
- Respectfully, it is far better to run a scheduled task as NT AUTHORITY\LocalService or NT AUTHORITY\NetworkService . Scheduled tasks should emphatically _not_ be run as NT AUTHORITY\SYSTEM. That account includes Full administrative credentials. Many easy to make mistakes in the task, such as having the script file in a writeable directory would permit an attacker full escalation to local machine admin.
Hi Tom_S
I could try to use a different "System Authority" to run the Task.
The problem using a "System Authority" is, that this (discoverd that in the test with "NT-Authority\System") Authority DEOS NOT have read and/or writing privileges on our server where the scheduled task is "stored".
I guess you could probably use a hidden folder in windows where only Domain-Admins and System has read/wirte rights on it, but is there an easier way to do that?
You know: "The less, the better."
Greetings
Yannik Schulz
I suggest a little clarification about your environment is in order. I think there is a script, stored in a server folder that is being run from a scheduled task on a separate workstation. Am I correct? May I ask in general terms, is the action of the script targeted @ the server or to multiple other systems in the environment?
To run this from the workstation, it would be necessary to have the task run under https://docs.microsoft.com/en-us/windows/win32/services/networkservice-account. That account will authenticate to the server with the computer's credentials. AD computer groups would be used instead of user groups for security filtering on the server share.
Have you considered running the script from a task scheduled on the server and using Powershell remoting to fan out to systems that are the target of the script?
P.S. https://docs.microsoft.com/en-us/windows/win32/services/localsystem-account behaves the same way on the network. It accesses remote machines with the credentials of the computer, not the user.
