I have a simple task, which for the purposes of testing, consists of a batch file with two lines:
whoami >result1.txt
copy \\server\share\test1.txt C:\Users\xxx\Documents > output.txt 2> error.txt
When I run this from an interactive login, it works fine, because I have domain credentials which give me access to the share.
When I run it from Task Scheduler, it fails. The first command succeeds (and incidentally demonstrates that the scheduled task is running with my identity) but the second command fails, presumably because it isn't using the right credentials to connect.
After the task is run, error.txt is empty and output.txt contains "Access is denied." There is no useful information in the task history – just Action Completed and a Last Run Result of (0x1) because the copy failed.
The General Options on the Scheduled Task properties are to run with my domain user account and to "Run whether user is logged on or not". I have tried both with and without "Run with highest privileges" set – doesn't seem to change anything. I also tried changing the "Configure for" option – again with no effect. "Do not store password" is not checked – but I tried checking it just for completeness and it doesn't change the behaviour.
On the server side I have checked the Security Event log. When the command fails I can see an Audit Success Anonymous Logon logon event, an Audit Failure entry which looks like the Anonymous Logon is trying to use SeBackupPrivilege:
A privileged service was called.
Subject:
Security ID: ANONYMOUS LOGON
Account Name: ANONYMOUS LOGON
Account Domain: NT AUTHORITY
Logon ID: 0x180e12c36
Service:
Server: Security
Service Name: -
Process:
Process ID: 0x4
Process Name:
Service Request Information:
Privileges: SeBackupPrivilege
and then an Audit Success Anonymous Logon session destroyed.
The client is Windows 10, and the server is Windows 2008 R2. The credentials are a Domain user account in Active Directory.
If I use a different server, a Windows Server 2016 box running IIS and WebDAV, then the task runs fine via the Task Scheduler. So, going via WebDAV, my credentials are being used, whereas going via CIFS they are not.
Can anyone elucidate why the copy is failing and if there is any workaround? Any next steps for testing? I have got it to work by hard-coding credentials in the batch file but obviously that's not really acceptable.
It was suggested that this policy might be relevant but it's disabled so I don't think it is:
Network access: Do not allow storage of passwords and credentials for network authentication
at
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Best Answer
I've seen more anecdotal evidence of permissions behaving differently interactively compared to from a Scheduled Task. And the event log message seems to point towards the fact that it needs the seBackupPrivilige ( which probably really means it wants to change the objects Owner).
Putting the user you run the task under in a built-in local group like Backup Operators on the target server might do the trick ( don't have a test bed to test this, but if unsure start with local admin on both servers and then use elimination).
In theory you could also use the domain GPO to set similar permissions for the specific user or even better their group.
EDITED: Have you tried to omit or change the error output? The security event could be a red-herring ( NTLM auth will always have a failed anonymous entry for instance).
If I run your script it errors out in a scheduled task because there is no path in front of > output.txt and 2> error.txt - but this works:
Your script will work if you run it from a command prompt or by double clicking because it will use the parent directory, that works differently when not running interactively (I'm assuming it tried to write somewhere where domain admin does have permissions while your user does not).