TeamCity executes builds using the build agents. The build agent I have is an agent on Windows that is running as a service under domain credentials.
I need to Invoke-Command on a remote web server in one of my build steps.
When I do this (lot's of stuff removed for simplicities sake):
$password = ConvertTo-SecureString "actualpasswordhere" -AsPlainText -Force
$credentials = New-Object System.Management.Automation.PsCredential("domain\teamcityagent1",$password)
...
Invoke-Command -computername $IISComputerName -Credential $credentials -ScriptBlock ${function:BackupSite} -ArgumentList $IISSiteName, $IISBackupDirectory
It works. But when I provide credentials for currently executing user like this:
$credentials = [System.Net.NetworkCredential]::DefaultCredentials
(surrounding code is the same)
I get the internal waiting and not execution at the point of Invoke-Command. I haven't waited too long, but nothing happens even in 5 minutes.
I would like not to have to provide login and password explicitly in the script, since the credentials are basically for the same user that the build agent is running under. How can I work around the need to provide the login and password in script code?
I did two things and it worked:
Unchecked -NoProfile argument in PowerShell runner parameters. (Didn't help alone)
Removed -Credentail parameter from Invoke-Command.
This executed my code as current user - service user.
Related
I have an environment formed by a Jenkins Server, a couple of Jenkins Slaves (windows) and several remote windows computers all part of the same domain.
I need to run a jenkins job, which executes a powershell snippet consisted of several functions (part of a custom modules loaded on the Jenkins Slave) against other windows remote computers in the same domain (which do not have the modules installed).
These modules needs to run under a specific domain account with permissions to access the remote computers.
If I logon with on any of the jenkins slave (with that specific domain account) everything works fine.
By default, Jenkins executes the job on the slave using the NT authority\system account which, of course, returns me denied access errors.
Question: is there a way to tell Jenkins to execute the Job on the windows slave with another specific Domain Account and not the NT Authority\System one?
Tried already:
Invoke-command using credentials: this is not an option since the remote computers do not have the modules
Impersonation: tried a couple of functions found on the PS gallery but do not work
You can run powershell as a process in a script and call that from Jenkins. In the script also you can use like:
$username = 'username'
$password = 'password'
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential $username,$securePassword
Start-Process Powershell.exe -Credential $credential
Hope it helps.
I'm attempting to provision a Windows VM and I need to map some Azure fileshares to drives for the VM user that will be interacting with the VM.
I've been trying to make "az vm extension set"/Custom Script Execution work for me by calling some PowerShell scripts to setup the mapping to the fileshare, but since the process runs as NT AUTHORITY\SYSTEM, the mappings aren't working, obviously. I've tried to switch user contexts in my scripts via having an intermediate script that changes context to my VM user and then calling another script that does the work, but that doesn't seem to be working.
$scriptFile = $args[0]
$username = $args[1]
$password = $args[2]
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential $username,
$securePassword
Start-Process Powershell.exe -Credential $credential $scriptFile
Unfortunately it seems nothing gets run in the $scriptFile that I call, and I can't get any errors out of standard out/err, so I'm at a loss as to how this can be done.
Certainly someone out there has had to run scripts as another user via the Custom Script Execution method before, I'm hoping they happen to read this post.
Is there a way to set what user the Custom Script Execution runs as?
No, there is no way of setting a user under which script extension runs.
You also should use -PassThru and -Wait and\or -RedirectStandardError\-RedirectStandardInput to your command invocation. Also, add -ErrorAction Stop to your commands to propagate errors.
I have a simple Powershell script (that's being run in a step in Octopus deploy) that I'm trying to run as another user. We need it for future steps (each application on our platform runs as its own user account, and I need to be able to run an arbitrary script as that user during the deployment process).
The problem is that even the simplest script fails with completely unhelpful error messages, such as this:
$secpasswd = ConvertTo-SecureString $OctopusParameters["runAsPassword"] -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ($OctopusParameters["runAsUsername"] , $secpasswd)
$job = Start-Job -scriptblock {
whoami
} -credential $credential
$job | Receive-Job -Wait
Which fails with the message:
The background process reported an error with the following message: .
The Octopus tentacle is running as a domain account with admin privileges on the machine.
I've completely exhausted all avenues of investigation now, but we really need to get this working. I think if we can't run a deployment script as a certain user then we're completely screwed.
Nearly three years later I have the same issue... I tried writing the code to a temporary file and using Start-Process, but couldn't get that to work either.
In the end, I wrote the code to file, and then ran it through the Windows task scheduler.
I'm writing an 'Action Script' in VMWare AppDirector 'AppD' which installs MS Dynamics. (My action script is actually a powershell script). The way this works is that AppD will execute a powershell script on a newly deployed server, using a builtin administrator account. This script is one of the last steps in a highly orchestrated deployment. At this stage my SQL server has been deployed, the databases loaded, and I'm performing the final deployment.
When I run my script logged in as myself, everything works great. But of course that's executing under 'mydomain\myusername' which has access to the SQL server etc. However, when AppD executes this script under a local builtin account, it doesn't have the credentials needed by setup to authenticate against SQL, and make proper connections for install to succeed.
My first attempt was to just call a script, that invokes my actual deployment script, so I can pass credentials;
$user = "mydomain\myusername"
$pword = ConvertTo-SecureString -String "mypassword" -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $pword
Invoke-Command -FilePath "C:\Scripts\DeployAOS.ps1" -Credential $credential -Computer localhost
This looked like it might have worked, but when reviewing the install log I see the following error;
2015-03-09 13:15:19Z Property DbSqlServer set to: 'SQLSERVER001'
2015-03-09 13:15:23Z Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
My original DeployAOS.ps1 script contains this line, which kicks off the install;
# Perform AOS Installation
Start-Process -FilePath $exeAOSSetup -ArgumentList $cfgAOS -Wait
I have also tried just modifying my DeployAOS.ps1 to set the 'System.Management.Automation.PSCredential' object w\ Username\Password, and doing something like this;
# Perform AOS Installation
Start-Process -FilePath $exeAOSSetup -ArgumentList $cfgAOS -Credential $credentials -Wait
And it really didn't like that. It feels like the AOS setup needs to be executed under a domain user, that has access to the SQL server, and maybe even have a user profile loaded while setup runs (So it can create a desktop shortcut, etc.)
Any ideas how I might go about solving this problem? I'm fairly new to scripting in powershell, so any help would be appreciated.
I'm a Powershell newbie and am trying to use this article to create a way for another user to kick off an SSIS package on a remote server.
The Powershell code I'm using is:
$pass = convertto-securestring "myPassword" -asplaintext -force
$mycred = new-object -typename System.Management.Automation.PSCredential -argumentlist "myUsername",$pass
invoke-command -computername myServer -scriptblock { dtexec.exe /File "d:\myPath.dtsx" } -credential $mycred
Even though I've tried passing my credentials in Powershell, the SSIS package doesn't seem to be executing with them and is executing as an Anonymous user. The package is failing validation for a number of reasons -
The package can not connect to a remote file that requires permission to access (I have permission but the Anonymous User does not). The user that I would like to have run this script does have permission to the folder.
The SQL Server login is failing. I tried forcing a SQL user in the connection details of the package but that doesn't seem to have worked.
Can I use change the Powershell code to use Windows Authentication? How do I execute the SSIS package using those permissions?
you need to enable CredSSP first (see this), and use invoke-command -Authentication Credssp