PowerShell and Scheduled Tasks

This topic contains 2 replies, has 3 voices, and was last updated by Profile photo of Rob Simmers Rob Simmers 1 year, 5 months ago.

  • Author
  • #25482
    Profile photo of Rob Poirier
    Rob Poirier

    Hi Folks,

    I have a series of scripts that automate some tasks that my team and I used to perform manually at my job. I have these scripts set up to run via scheduled tasks (whether the user is logged into the server or not) on a dedicated server every few hours (or whatever the requirement may be). I'm running these in an Enterprise Active Directory environment with my team's generic account (we're basically a NOC and it's a shared account). My challenge is this: The password to this account expires every 90 days which causes the scheduled tasks to fail if I'm not around to update them in time. My security team won't allow me to use a generic account with the same access and a password that doesn't expire. So I need a way easily update the password for these scheduled tasks. Is it possible to automate this process:

    1. Detect when a password has been updated
    2. Prompt a user for creds (my team is there 24/7)
    3. After authenticating against AD to ensure password is correct, update the server's scheduled tasks with the new password.

    2 & 3 I'm fairly certain I could handle. I'm assuming it would just be a matter of making a script that runs Get-Credential and Set-Scheduled task? As for the first one, detecting when the password has been updated...I was going to take the route of querying the account via Get-ADUser on timed intervals, but that seems so inefficient. Please don't tell me that's the only way to go lol.

    Not sure if this makes things easier or not but the account that's used to run the scheduled tasks is also always logged into about 6 PC's (our NOC workstations). Therefore, as soon as the password expires we would know because we'd start getting prompts for different things such as Outlook and our proxy through IE.

    Any advice here would be appreciated.


  • #25538
    Profile photo of Don Jones
    Don Jones

    1. is going to be hard. Probably impossible. At least in terms of a "notify me when it happens." I suppose you could rig up some daily check to try and log into a resource, and if it fails, then you assume the password has changed.

    2. Scheduled Tasks run in the background. They can't (normally) interact with the desktop. How will you provide the password?

    3. This is pretty straightforward.

    What would be easier (and I think better) is to automate the changing of the password, so that it could also update the scheduled task at the same time. My suggestion is a script that runs every 30 days, comes up with a new random password, sets it, and changes the scheduled task. Use a unique account. You'll never "know" the password for this account, which actually makes it more secure, since you wouldn't be able to log on as that account. Essentially cobbling together your own Managed Service Account. Using a shared account for this isn't an awesome idea, anyway. Very poor security practice. Only takes one compromise on that account and a bunch of stuff could be screwed.

  • #25549
    Profile photo of Rob Simmers
    Rob Simmers

    #rant It is amusing that the Security team doesn't want to create a service account but having a team of people having the password to a elevated [b]generic[/b] account is fine. Typically, generic (service) account are locked down tight only having access to do exactly what they are for with no local logon permissions, strict delegation, explicit permissions. Even with setting up strict permissions on account, the days of setting the service account password and forget it are coming to an end. Credentials are easy to steal and I know places that are resetting their elevated accounts every 24 hours to 2 days, because even if you get them you might have 10 hours until it resets. Granted these are high security businesses, but credentials are not that hard to get. Changing a service account password every 3 years after a security event is bound to bite you in rear.

    Don's approach is along the same lines I was thinking, basically creating a process to manage the password lifecycle. I've done similar implementations and we usually make the passwords complex and really long, nothing a person would ever want to type in.

You must be logged in to reply to this topic.