>From my understanding non-Administrators cannot create/modify/remove/view Scheduled tasks by default. Each task itself is governed by the NTFS security ACL of the XML definition file located in C:\Windows\System32\Tasks\*.xml, here are the default permissions set when creating a task.
<https://lh3.googleusercontent.com/-HlxGPn4IG-4/WgOGuuwfkEI/AAAAAAAAAQ4/5f_ljlETiCg_k2HUMXXxc3Wa4L_OQlEqQCLcBGAs/s1600/Screen%2BShot%2B2017-11-09%2Bat%2B8.34.47%2Bam.png> >From these permissions, you can see * The user who created the task has Read permissions * All Administrators of the machine have full control over the task (inherited from the parent folder) * SYSTEM has special permissions but is SYSTEM so is god I can prove this works in a playbook running on Ansible (devel) - hosts: Adhoc gather_facts: no tasks: - name: remove test file win_file: path: C:\temp\test state: absent - name: create scheduled task win_scheduled_task: name: Test username: '{{ansible_user}}' password: '{{ansible_password}}' logon_type: password actions: - path: cmd.exe arguments: /c mkdir C:\temp\test - name: check list of groups user is member of win_command: whoami.exe /groups register: groups_output - name: show user's groups debug: var: groups_output.stdout_lines - name: run scheduled task win_command: schtasks.exe /Run /TN Test - name: get stat of test file to prove task ran win_stat: path: C:\temp\test register: stat - name: file folder stat debug: var: stat Here is the output of the main tasks <https://lh3.googleusercontent.com/-ukw3GAhBSsE/WgOK-4w09TI/AAAAAAAAARQ/e3O5nEqLpgwltnS-ETPutdSiHwL8AouzQCLcBGAs/s1600/Screen%2BShot%2B2017-11-09%2Bat%2B8.53.30%2Bam.png> This works on all OS's I've tested so far but unfortunately I can replicate the issue with Server 2016 and non admin users. Usually I can add the user account to the XML ACL and then be able to run the task but not on Server 2016 as you have reported. It seems like Microsoft has restricted the permissions that are required to execute a scheduled task that a normal user does not have permission for but I cannot find out what that may be. Because this is an issue with Windows and not Ansible, I would say there is not much we can do about it and the use case is probably quite minimal but I've happy to be proven otherwise. >From an Ansible standpoint, yes it would be nice for a non-admin account to run a scheduled task but IMO non-admin users should never be able to modify a task. This opens up a pretty big security hole as a non-admin user would then have the ability to change what is run by the scheduled task and potentially allow a custom script to be executed by a higher account without knowing the password. This begs the question, what are you trying to do as scheduled tasks can be fragile and annoying to work with and there may be other options available for you in Ansible. Traditionally scheduled tasks are used by tools to bypass WinRM restrictions such as no access to WUA and DPAPI. This is how the Packer elevated shell process works and is pretty much done everywhere that deals with WinRM as it is simple and get's the job done *most of the time*. This can still be done in Ansible with an admin account (even on 2016) but using become is a way better option, in 2.5 we even have an example on how to do that http://docs.ansible.com/ansible/devel/windows_usage.html#creating-and-running-a-scheduled-task. Even so, using become is generally recommended as we don't need to mess around with creating the task and ensuring it starts, cleaning it up afterwards, and somehow getting the stdout/stderr/rc values from the process. Plus with become we can run it with modules whereas scheduled tasks can only be used to run individual commands. Thanks Jordan -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
