I am trying to run a Jenkins job that asks for a users credentials and sets global variables. This is a Powershell script in Jenkins Job I use:
$pscredential = Get-Credential
$global:uname=$pscredential.UserName
$global:upwd=$pscredential.Password
Write-Host $global:uname
Write-Host $global:upwd
The job is run from a remote machine initiated by the user, so i would have thought they would get a pop up and the details they provide would be passed through to the Jenkins job.
The call to Get-Credential doesn't bring up the login screen for the user. How can i get the user credentials or is there another cmd i should be using?
Related
Problem statement: I want to run some scripts into a Virtual machine created in Hyper-V. The virtual machine has a Username and a password.
The problem is Whenever I use invoke-command or enter-pssession, it prompts for username and password. I need to do it without Entering details manually every time and should be able to do it through scripts.
You will need to run the scripts as a Hyper-V admin (local admin on the host), but you can automate the process of providing the VM credentials by export a [pscredential] object to disk:
# Enter the credentials when prompted
$VMCredentials = Get-Credential
$VMCredentials |Export-CliXml path\to\credentials.xml
Export-CliXml will automatically use DPAPI to encrypt the password part using a key derived from the current security context - meaning only the same user on the same machine will be able to decrypt it again.
In order to use these stored credentials, simply call Import-CliXml:
$VMCredentials = Import-CliXml path\to\credentials.xml
Invoke-Command { ... } -VMName VM01 -Credentials $VMCredentials
How do I start PowerShell with a gMSA account. I right click on the PowerShell icon, run as different user, then input domain\msa$ with no password. It errors out about credentials being incorrect.
I've installed the service account on the machine and running the Test-ADServiceAccount return true. I've granted it the 'log on as a service' and 'log on as a batch job' permissions (I don't really think this was needed but tried it anyway and it didn't work).
Any ideas?
There are different ways to set up tasks running a PS script with a gMSA, this is what I personally do because I find it easy to do.
First you need to develop your .ps1 to download the file from your FS with your user or with a service account with permissions to download the file.
Once the script is tested and running correctly, set up and test a Scheduled Task with your user or service account used in step 1. It's a good idea to configure all the triggers / extra configurations beforehand because once you update the scheduled task you can't modify it without doing all the process again.
Once the Scheduled Task is fully functional and all triggers set, you proceed to update the task using the gMSA instead of your user or service account. I personally use this:
$taskName = "My Scheduled Task Name"
$gMSAName = (Get-ADServiceAccount gMSA_Name).sAMAccountName # Or hardcode your gMSA Name with a $ at the end
$runLevel = "Highest" # Limited, etc
$principal = New-ScheduledTaskPrincipal -UserID $gmsaName -LogonType Password -RunLevel $runLevel
Set-ScheduledTask -TaskName $taskName -Principal $principal
After running this and if everything went OK, once you re-open the Task Scheduler and search for your task you should see the name of your gMSA here:
Remember, once you update the task if you need to edit it later, Task Scheduler will force you to use a different user and the whole process of updating the task via PS will have to be repeated.
To have in consideration:
The gMSA will need the same permissions as you or your service account over the File Share to read / modify / etc.
The server where the task will run has to be a member of the associated Security Group of your gMSA:
(Get-ADServiceAccount gMSA_Name -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword
This is the associated AD Group and your task server MUST be a member of this group in order to use the gMSA.
psexec DOES work, at least interactively. On the machine where the gMSA is 'installed' use this:
psexec -u DOMAIN\gMSA_acct$ powershell.exe
When prompted for password just hit enter. That will launch Powershell as the gMSA. You can verify with a WHOAMI from that session.
If there is a commandline switch to make psexec skip the prompt for password (or possibly using <NUL STDIN redirect) you can make this work non-interactively as well.
However this doesn't change the recommendation to run the task as the gMSA. That is 100% correct, you should NOT be running tasks as LocalSystem, especially if you need to access remote resources. Perhaps the file copy task can be split out from the rest.
I'm using InstallAnywhere and due to security reasons, I need to change the Server (our application server) "Log on as" to other user than System.
I'm asking the user during the Pre-Install to supply me with a username (in a format of <Hostname\Username> or <Domain\Username>) and a password. Now I need to verify these credentials supplied by the user are valid, and if not prompt the same Panel again.
The problem is that with command line using the net start... command - I can't supply username & password.
Using the runas command - can give it the username as a parameter but not the password. (also - it was stucked on "attempting to start..." and couldn't start the process)
I've also tried PowerShell script which used the start-service command, using the -Credential parameter, but it didn't work.
another idea - is there a way to verify this using Regedit?
I'm having a problem getting a PowerShell script which queries objects in a cloud-based Exchange resource to work in an Orchestrator runbook.
The PowerShell script (which works correctly from my desktop computer's command line and when stepping through it in ISE) sets up a remote management session to the cloud and looks like this:
try
{
$user = "username#domain.com"
$pword = convert-toSecureString -string "password" -asplaintext -force
$creds = new-object -typename system.management.automation.pscredential -argumentlist $user, $pword
$o365 = new-pssession -configurationname Microsoft.Exchange -connectionuri https://ps.outlook.com -credential $creds -authentication basic - allowredirection
import-pssession $o365 -allowclobber -prefix o365
get-o365Mailbox 'Doe, John'
}
catch
{
throw $_.exception
}
As I mentioned, it runs fine when I step through it in the editor on my desktop but when executed inside the Orchestrator runbook it fails on the "import-pssession" command (because the $o365 is never set).
I've taken the PowerShell script and run it manually on the actual runbook server and it works there as well as it does on my own desktop -- it's only when run inside of an Orchestrator runbook that it won't function. I only have a few weeks experience with Orchestrator and didn't know I'd run into a problem like this so quickly -- I am trying to run the script in a "Run .Net Script" activity with the language set to "Powershell," which I believe is the recommended method.
I've tried saving the script as a file on the runbook server and then used the "Run Program" activity to run PowerShell with this file (recommended by someone during my searching) and that doesn't work either.
Is the Orchestrator service account that's running the script a member of the Exchange RBAC role groups? If not, it won't be allowed to connect to those Exchange management sessions.
The problem turned out to be related to the client's firewall and proxy settings for the service account they set up to be used by Orchestrator. They (the clients) would not grant the service account Internet access as a matter of policy.
A couple of different solutions came up: One was installing the PowerShell integration pack from CodePlex and using that -- the CodePlex PowerShell activity allowed me to explicitly set the security context of the activity, which let me get around their firewall issue by running the activity under an account which did have Internet access.
The second solution was installing the Exchange Admin integration pack and configuring a connection to the cloud host. Using the "Run Exchange PowerShell Command" activity rather than the more generic "Run .NET script" activity also allowed the code to work as expected.
Orchestrator is still x86 and the commands in your script will only run in x64.
Test this in your x86 ISE and see the same failure.
My workaround is to call the script using the "Run Program" activity within the System activities list.:
Program execution
Computer = I always start with initialize activity and then subscribe to the computer here
Program path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Parameters: full path to the .ps1 of your script
Working folder: c:\temp
I want to write a Powershell script that will validate a large number of service accounts that was provided to me by my AD team. Not that I don't trust them but I want to cycle thru each domain username and password to see if it logs in or fails. I am looking for some suggestions so far my attempts have failed (see post http://tjo.me/fKtvPM).
Thanks
P.S. I don't have access to AD so I have to try to login using the credentials to test.
This is really hacky (ugly for least-privileged model), but if you know that all of the service accounts have access to a particular program / file, you can try to start a process using their credentials.
$cred = get-credential # however you're getting the info from AD team, pass it hear to get-credential
start-process powershell -argumentlist "-command","exit" -cred (get-credential)
$? # if $true, process started (and exited) successfully, else failed (either bad creds or account can't access powershell.exe
Unfortunately, since you can't query AD directly, I think any solution is going to be a bit of a hack, since by definition you're going to have to simulate logging in as the user account.