This topic contains 3 replies, has 2 voices, and was last updated by
February 26, 2018 at 9:15 pm #94707ParticipantPoints: 0Rank: Member
I want to create ScheduledTask (using powershell) with the following requirements:
– Use specific Domain User
– Run whether user is logged on or not
– Store password because I need access to shares on another servers.
It looks like I can use "New-ScheduledTaskPrincipal" for "Run whether user is logged on or not"
But in this case password is not saved.
I don't know if I can supply password with "New-ScheduledTaskPrincipal".
My commands are
$principal = New-ScheduledTaskPrincipal -UserID "MYDOMAIN\user_for_scheduled_task" -LogonType S4U -RunLevel Highest Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "Task-1" -Description "Very Important Task-1" -Principal $principal
After executing these commands I see "Do not store password" checked in "Task Scheduler".
And when I tried to manually run "Task" in "Task Scheduler" I am getting "PermissionDenied" during external server share access in script transcript.
How can I allow access to external shares for Register-ScheduledTask ?
February 27, 2018 at 2:39 am #94719ParticipantPoints: 226Rank: Participant
allow access to external shares
This is not controlled by ScheduledTasks. This is of course, controlled by Windows ACL's on the shared resource.
You should validate the access to shared location using whatever credentials you plan to use well before trying to automate it in any form.
So, have you first used the creds you are referencing to just hit a few of the shares you are needing to access?
If you cannot do it natively via Explorer, net use, etc., then you need to correct that first. If the remote shares are in a different domain, then you can hit the Windows one-hop auth constraint.
For scripting, gets or sets the security logon method that is required to run the tasks that are associated with the principal.
Use an existing interactive token to run a task. The user must log on using a service for user (S4U) logon. When an S4U logon is used, no password is stored by the system and there is no access to either the network or encrypted files.
Security Contexts for Tasks
Tasks registered with the TASK_LOGON_PASSWORD or TASK_LOGON_S4U flag will only launch if the specified user has the Logon as Batch privilege enabled. Administrators and Backup Operators group users have this privilege enabled by default.
Configuring Advanced Scheduled Task Parameters Using PowerShell
creating a scheduled task with the specific parameters that were needed is not as simple as it might seem. In this blog post I am going to show you how to create a scheduled task using Powershell, call a PowerShell script using that scheduled task, and configure parameters of the scheduled task that are not provided through the PowerShell Scheduled Task cmdlets. So lets go ahead and create an example scheduled task that meets all of the requirements.
Help! My Scheduled Task does not run…
With that, we explain that Task Scheduler was completely re-written in 2008/Vista, with one of the main changes being in Security. Here is a snippet from a Technet Article published back on March 3, 2006:
February 27, 2018 at 9:43 pm #94767ParticipantPoints: 0Rank: Member
I ran my powershell script (manually) from powereshell window working under user I want to schedule this Task.
Everything works OK. Script can access remote share.
I am using UNC-path inside the script.
But the scheduled script can not access remote share after I register Task using the following command:
$principal = New-ScheduledTaskPrincipal -UserID "MYDOMAIN\user_for_scheduled_task" -LogonType S4U -RunLevel Highest Register-ScheduledTask -Action $action ` -Trigger $trigger ` -TaskName "Task-1" ` -Description "Very Important Task-1" ` -Principal $principal
I tried to run the Scheduled Task from Task Scheduler manually and got "PermissionDenied" error.
I was working under Domain User (in RemoteDesktop) I scheduled this Task under.
Also I managed to schedule my Task using the following commands:
Register-ScheduledTask -Action $action ` -Trigger $trigger ` -TaskName "Task-2" ` -Description "Very Important Task-2" ` -User "MYDOMAIN\user_for_scheduled_task" ` -Password "Passw0rd"
It works as a scheduled task when I close RemoteDesktop. It has access to remote shares.
But I don't like "hardcoded" password.
I want to open RemoteDesktop and execute "Register-ScheduledTask" command with parameters that will schedule my Task
using my current Domain User password.
After this I want to close my current RemoteDesktop session but my Task should continue to run (according to my schedule) and has access to the remote shares.
I am not sure if it is possible?
Probably I should use another "-LogonType" in New-ScheduledTaskPrincipal command?
February 27, 2018 at 10:54 pm #94769ParticipantPoints: 226Rank: Participant
Remember, as per the MSDN link I pointed to above.
When an S4U logon is used, no password is stored by the system and there is no access to either the network or encrypted files
Meaning, this is no different than using 'local system' for a ST. LS has not authorization to operate anywhere other than the local host. You must be able to pass the full domain credential to a remote resource. Since with S4U you are not doing this, the credential is not complete, and thus will not work.
You should never store passwords in plain text in script files. You should prompt for them each time or prompt for the once and permanently store them on the host where they are to be used.
Saving Credentials for Office 365 PowerShell Scripts and Scheduled Tasks
Using a Stored Credential for a Scheduled Task
The Get-StoredCredential function can also be easily integrated into scripts that you are running as scheduled tasks. The most important thing to remember is that the password can only be decrypted by the user account that encrypted it in the first place.
If your scheduled tasks run using a service account, you'll need to log on as that service account to run New-StoredCredential, or use Runas to launch a PowerShell console as the service account. The stored credential file will also need to be located in a folder that the service account can access, and that location needs to be defined as $KeyPath in your script as well.
Quickly and securely storing your credentials – PowerShell
During the last PowerShell event I quickly demo'ed the Export-CliXml functionality to quickly, easily, and most importantly, securely store credentials to a file. In this article I will describe the following three steps:
• Store credentials in a variable
• Export the variable to a file
• Import the credential object from the file into a variable
How to run a PowerShell script against multiple Active Directory domains with different credentials
A while back I stumbled onto this handy blog post by Jaap Brasser, a PowerShell MVP from the Netherlands. He was using a hash table to store multiple credentials in a script, and then cache them to disk securely using Export-CliXML. The XML export is a quick way to dump the secure string passwords to disk for later re-use. This has been a popular technique for several years now, but he is the first one I saw doing this with a hash table of credentials. Nice touch! In this post I am building on his technique.
The topic ‘New-ScheduledTaskPrincipal and need for unchecked "Do not store password"’ is closed to new replies.