I don't know why I can't figure this out, this can't be as hard as I'm making it. I'm trying to create a powershell script that will elevate itself using explicit credentials from AzureAD. I create a PSCredential object with:
$ss = ConvertTo-SecureString "p#ssw0rd" -AsPlainText -Force
$cred = New-Object PSCredential -ArgumentList 'username#domain.com', $ss
Start-Process PowerShell -Credential $cred "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`""
exit;
When I execute this I get Start-Process : This command cannot be run due to the error: The user name or password is incorrect.
I know the username and password are correct but I am guessing that it has to do with the fact that this is an AzureAD user? Do I have to format the AzureAD username differently? I've tried reformatting it every way I can think of. I've tried using Connect-AzureAD and using Get-AzureADUser to try to see if I could use some property of that to sign in but I'm coming up empty.
Is this even possible?
With Start-Process you must specify username in format "DOMAIN\user". I am not sure where from this limitation is coming.
Is the domain that the azure ad user account you are trying to run the command as accessible to the domain that your machine is connected to? Without more information, I can only speculate that powershell is throwing the error because it does not recognize the user or the domain the user is a member of.
Related
I want to run one command with saved credentials on powershell, i have the following script
$user = "test"
$passwd = ConvertTo-SecureString -String "ExtremelyStrongPassword" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $passwd
Copy-Item -Path "C:\Temp\*" "C:\Program Files\Test\" -Credentials $cred
The user doesn't have administrator permissions, but in the localhost we have an user with administrator permissions to run these process.
The error returned is "Access Denied"
How do i pass these parameters to run a command with elevation?
Never pass plain text credentials in a script. Use the Get-Credential cmdlet to collect and use them. Even doing this, the user will get prompted for a password.
This is what the -RunAs switch of Start-Process is for
Or set your script to auto elevate
Or use the credential switch of a cmdlet
Or use a scheduled task with whatever creds you need, and let the user run it.
Use the Requires statement at the top of your script
Store the need creds in the Windows Credential Store and call them
from there
about_Requires - PowerShell | Microsoft Docs
Short description Prevents a script from running without the required
elements.
#Requires -RunAsAdministrator
Start-Process
Example 5: Start PowerShell as an administrator This example starts
PowerShell by using the Run as administrator option.
Start-Process -FilePath "powershell" -Verb RunAs
Using what you have this way:
Copy-Item -Path 'C:\Temp\*' 'C:\Program Files\Test\' -Credentials (Get-Credential -Credential 'Domain\UserName')
With exception of the scheduled task approach, each will prompt the user for a password, which sounds like what you wanting to avoid. So, consider the following:
Accessing Windows Credentials Manager from PowerShell
This simple PowerShell class can be used for working with Credentials
Manager and Password Vault in Windows: checking if account information
is present in the vault, saving credentials to the vault and reading
stored login and password information from the vault.
https://gallery.technet.microsoft.com/scriptcenter/Accessing-Windows-7210ae91
Using the registry to store credentials:
Save Encrypted Passwords to Registry for PowerShell
I am trying to run a powershell script from another powershell script passing in the credentials of a different user and then using the credentials:
Start-Process powershell.exe -Credential "LON\my-user" -NoNewWindow -ArgumentList "-file C:\DevopsScripts\stuckApps.ps1"
I have this is numerous different ways all get the same error. I have tried setting the username and password before the command:
$username = "LON\my-user"
$password = "pass"
$PSS = ConvertTo-SecureString $password -AsPlainText -Force
$cred = new-object system.management.automation.PSCredential $username,$PSS
$env:USERNAME
Start-Process powershell.exe -Credential $cred -NoNewWindow -ArgumentList "-file C:\DevopsScripts\stuckApps.ps1"
But everything I try gets the error:
Start-Process : This command cannot be run due to the error: The user name or password is incorrect.
I know the username and password are correct as they have been tested on the cmd which it works fine:
C:\Users\ADM-me>runas /noprofile /user:LON\my-user"powershell.exe C:\DevopsScripts\stuckApps.ps1"
What am I doing wrong here and how could I fix this, preferably by setting the password beforehand, so this can be automated. Also this does not need to be done using Start-Process, just this is the closest thing I could find to working.
I think the problem I am having is this, in stuck apps it has this:
$conn = New-Object System.Data.SqlClient.SqlConnection
$conn.ConnectionString = "Server = mssql.co.uk; Database = mydata; Integrated Security = true;"
$conn.Open()
I need this to run the credentials that I am trying to pass through it or else I get this error.
`Exception calling "Open" with "0" argument(s): "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication."
But I can't pass the credentials through as the only ones that work are admin ones, (which I have but then that will throw the error above). Is it possible for me to use the admin logins to access stuck apps then use the logins needed to connect on stuck apps as an AD login.
Your first attempt with -Credential "LON\my-user" can't work, but your second attempt is correct, building the object of class PSCredential, as required (see the type in Get-Help Start-Process -Parameter Credential, it is PSCredential and not String). I tried the same with some reused code here, and it works here both or CMD and PS1 calling a PS1 test script via Powershell.exe, using a local test account (sorry, no domain #home).
So even though my code ist not identical and the domain of the user is the local machine, the approach is the same compared to yours and - sorry that this does not solve your problem - I don't see that you are doing sth. wrong.
To play safe, please make sure though to test with the same Powershell version, the below scripts executed under W10 1607 (so Powershell 5.1.14393.1198), all scripts in the same directory.
testscript.ps1
write-host "Testscript is run with user: $($env:USERNAME)"
Start-Sleep 2
testrun.cmd
runas /noprofile /user:%COMPUTERNAME%\myaccount "powershell.exe -NoProfile -ExecutionPolicy ByPass -file %~dp0testscript.ps1"
testrun.ps1
$Username = "$($env:COMPUTERNAME)\myaccount"
$Password = 'mypassword'
$SecurePassword = ConvertTo-SecureString -String $Password -AsPlainText -Force
$ScriptFile = Join-Path -Path $PSScriptRoot -ChildPath 'testscript.ps1'
$Credential = New-Object System.Management.Automation.PSCredential( $Username, $SecurePassword)
$StartOpts = #{ 'FilePath' = 'powershell.exe'
'Credential' = $Credential
'NoNewWindow' = $false
'ArgumentList' = #( '-f', $ScriptFile,
'-ExecutionPolicy', 'Bypass',
'-NoProfile'
)
}
Start-Process #StartOpts
Some remarks on testrun.ps1
Don't mind the parameters for Start-Process being passed as a hashtable, it's just better readable for me, otherwise it makes not difference
The ArgumentList is being passed as a string array here - I prefer it this way so that it is automatically taken care for double qouting parameters, e.g. when the pathname of the script directory would contain spaces
The parameter -NoNewWindow passed to Start-Process seems not to have any effect here - a new window is opened
I always recommend to add the parameters -Noprofile and -ExecutionPolicy Bypass when using Powershell.exe to launch scripts or execute commands, just to make sure it works despite of the Execution Policy set or any present user or machine profile scripts.
However, at least the parameter -NoProfile seems not to work the same when Powershell.exe is being called fom the above CMD or PS1. Called from PS1, my machine profile gets nevertheless executed, but not fom CMD... interesting! The MSDN: PowerShell.exe Command-Line Help just says about this parameter: "Does not load the Windows PowerShell profile." Funny! There are six of them, see Technet: Understanding the Six PowerShell Profiles. I use "Current User, Current Host – console" and "All Users, Current Host – console". Lesson learned, but I am not sure if it's a bug or a feature.
So I have this powershell (or vbs or batch) script I'm trying to write. All it needs to do is a map a network drive persistently using alternate credentials. For some reason, it seems like the credentials aren't persisting. It maps fine initially then on login the drive will have a red X and when trying to open it I'll get prompted for the password.
When running powershell as the admin, upon re-logon, the drive isn't even shown anymore. I'm guessing because of a scope issue, but I thought the global flag was supposed to take care of that?
I've also tried the "net use" method and the "Wscript.Network" method from within powershell... same results.
I'm new-ish to windows scripting so it's probably something really dumb. Here's the essentials of the script I'm using. I'm pasting it directly into the powershell window. Where have I gone astray?
$user = "USERNAME"
$pass = "PASSWORD"
$cur_share = "\\192.168.1.100\websites"
$drive = "X"
$PWord = ConvertTo-SecureString -String $pass -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $user, $PWord
New-PSDrive -Name $drive -PSProvider "FileSystem" -Root $cur_share -Scope "Global" -Persist -Credential $Credential
You are seeing this behavior because you are using alternate credentials. If I use your code with my own credentials the drive persists even across reboots but if I use alternate credentials it does not. This is apparently as designed.
Relevant details from the cmdlet help:
Mapped network drives are specific to a user account. Mapped network
drives that you create in sessions that are started by using the Run
as administrator option or by using the credential of another user are
not visible in a session that was started without explicit
credentials, or by using the credentials of the current user.
Reference:
https://technet.microsoft.com/en-us/library/hh849829.aspx?f=255&MSPPError=-2147217396
Thanks Jon. Just as you post that I found a workable solution. The key is to store the credential in the manage before using the network path.
$result = cmdkey /add: "192.168.1.100" /user: "USERNAME" /pass: "PASSWORD"
That stores the credentials persistenty. Then mapping the drives persistently works with no password prompt.
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 need to execute application which will be running under System user account (powershell itself is running under standard user account with administrator rights). I tried Start-Process cmdlet with custom credentials:
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList #("system", (ConvertTo-SecureString -String "" -AsPlainText -Force))
Start-Process -Credential $cred "app.exe"
But i have a two problems with that. First I can't create credential object without or with blank password (system user doesn't have any) and when I use credential with just any password I get error message that password is incorrect. Any ideas how to do this?
Btw I can't use psexec for this.
I think itsn't possible with powershell. You can try to use the at (dos command):
at TIME /interactive app.exe
where TIME is the hour hh.mm when start process...
You can use Invoke-TokenManipulation.ps1 script:
This script requires Administrator privileges. It can enumerate the Logon Tokens available and use them to create new processes. This allows you to use
anothers users credentials over the network by creating a process with their logon token. This will work even with Windows 8.1 LSASS protections.
Copy-paste it or save alongside with your script as Invoke-TokenManipulation.ps1 and use dot-sourcing to load:
$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path
. (Join-Path -Path $ScriptDir -ChildPath 'Invoke-TokenManipulation.ps1')
And then you can use Invoke-TokenManipulation function.
Example:
# Spawns cmd.exe as SYSTEM.
Invoke-TokenManipulation -CreateProcess "cmd.exe" -Username "nt authority\system"