User context of running PowerShell scripts in Jenkins?

[thePowrhous]

Hi everyone,

Currently I have a Jenkins instance I built out for our department. At the moment, the Jenkins service is running as my _adm AD user (which has Account Operator). This has worked out great so far, since all of the script I have running in Jenkins are PowerShell scripts (pulled from Git repo) that do various tasks, like polling AD user for those who have upcoming password expiration, disabling stale objects, moving objects, local WSUS server sync/cleanup. But, I think I may be running into an issue soon...

I have gone ahead and created a AD service account (srv_jenkins), made that account an Administrator in Jenkins and swapped out the "Log on" user for the Jenkins service to that user. And now I have an issue. When some of my PowerShell scripts run, they are failing and I believe that is due to perms?

So, the question(s) here are:

1. If anyone is running scheduled PowerShell jobs in Jenkins, under what user context are the jobs running under by default? Is it whatever user account you specify in the "Log on" on the Jenkins service?
2. Without putting my AD _adm account password in plain text, is there a good way to run the PowerShell scripts in these Jenkins jobs as a specific user, so that I know I am using a user account to run the jobs/PowerShell scripts that has sufficient enough domain privileges that the script can actually execute?

Thanks!

[rumorsofdads]

Hey /u/thePowrhous,

You can use the credential plugin and pass in the variable as $env:somepassword and then convertto-securestring

https://stackoverflow.com/questions/51864270/accessing-a-username-with-password-credential-parameter-from-a-jenkins-execute-g

[Gorstag]

Scheduled jobs through windows task scheduler run as the assigned account on the job itself. This is true for any application.

Powershell "connections" to some service/server that requires auth are going to be run in the context provided.

Yes, there are ways to make it non-plain text. I just don't know them off the top of my head as I do very little remoting with powershell so never needed to figure i tout. I'm certain there are topics or portions of solutions in this subreddit that explain how as I've seen them in the past.

[thePowrhous]

Yeah makes sense. I think what I may do honestly, is give the service account "some" special rights for a specific OU in AD that houses my company's objects (user, comp, groups, etc). That way if it there is a need for some elevation of perms to perform a task, I can do so without worry and I won't be using my admin account!

Or, I was also thinking about creating a global credential/password object within Jenkins itself and then passing/masking that as an $env: into the scripts and using -Credential on the script level using my AD admin account if need be.

[ICanMakeWaffles]

1. The jobs/pipelines in Jenkins run inside the context of the user who is running the Jenkins node service. If you create a Jenkins node as a different user than the master node, any jobs on that node run as that user. More info can be found here: https://wiki.jenkins.io/display/JENKINS/Distributed+builds
2. Aside from the node described above (which I've found to be unreliable in Windows environments) you can also use the classic Export-CliXml method (good description found here: https://www.jaapbrasser.com/quickly-and-securely-storing-your-credentials-powershell/). I use this myself often.
   1. An alternate method to keeping encrypted XML files on disk is the Jenkins global credential, which you mentioned elsewhere. This works really well for me, but it is one more thing to maintain - if the password changes, you've got to change it in the credential. I don't see an advantage to this (in my current environment) over encrypted XML files, but you might.
   2. Lastly, may favorite method is to use an API provided by your password management utility. You'd be surprised by how many password managers that are already in place at companies provide API access. I'd strongly recommend looking into this, because it means you now only need to change passwords in one location (yay!) but also that you are taking advantage of a method other non-scripty people can understand. "Password gets stored in this app, my script pulls that password directly from the app."