I'm trying to enter a specific session on a remote machine which has credentials.
I have already setup trusted hosts etc.. and have successfully run commands on new virtual sessions.
I would like to enter the session by providing a session ID.
I have seen documentation for each seperate ways but I'm not sure how to combine them, can someone help?
This is what I would imagine it would look like
$username = "exampleUsername"
$password = ConvertTo-SecureString "examplePassword" -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList($username, $password)
$serverNameOrIp = "exampleIp"
$sessionId = 2
Enter-PSSession -Id $sessionId -ComputerName $serverNameOrIp -Credential $cred
However I'm getting very clear invalid argument exceptions which makes sense since the documentation doesn't say anything about this combination:
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enter-pssession?view=powershell-7
Is there a way to do this? I may be missing something obvious or looking in the wrong place. Many thanks in advance
(for more info)
EDIT:
I am trying to connect to the current interactive user session and run some commands for the user to see. The user is permanently logged in/already logged in and I have their session ID. I just need to use it and connect to it however there are still credentials to use for the machine - I'm unsure how to combine these two.
Related
I'm trying to use some credentials so I can connect to MicrosoftTeams using powershell with orchestrator. I need a username and its password. The password is stored as a global variable, encrypted. When I try to connect to MicrosoftTeams it says that the password is incorrent. However, when I put the password hard coded there is no problem, and I can connect to Microsoft Teams.
Here is my code:
$Pass = ConvertTo-SecureString '{password}' -AsPlainText -Force
$admin ="admin#admin.com"
$cred = new-object -typename System.Management.Automation.PSCredential -argumentList $admin, $password
connect-MicrosoftTeams -credential $cred
Has someone had the same issue?
I think my problem was because I was using a PowerShell Script activity. It turns out that this activity can't read encrypted variables. To solve this problem I just enctypted the password and stored it in my C: drive, then I just got the content from that file. If someone wants the code for that, please ask.
I am creating a PowerShell script that a user can just run to edit an entry in registry. My problem is that I cannot figure out how to store local admin username and password in the same script so that the user can just double click the script and run it without having to enter username and password manually.
Here is my code:
$username = "testpc\administrator"
$pasword = get-content C:\Users\test1\documents\testpassword.txt
$credential = new-object -typename system.management.automation.pscredential -argumentlist $username, $password
This does not work at all. Please let me know what I am doing wrong here.
Usually I'd ask for an error, but in this case I'll advise different, just because your approach isn't acceptable.
Don't store passwords unencrpted in script. Never.
Don't store passwords encrypted in scripts, which are meant to be read by someone else, especially not a user with less privileges. Never!
Go, figure other ways to solve your problem. Always!
In this case I see two solutions with the given information:
change the ACL for the registry key that need to be changed by the user
Create a scheduled task which runs as SYSTEM. Make sure the user cannot edit the script.
Actually #vrdse is right.
you can create the script with the KEY as parameter and:
create a scheduled job with the credentials of your user and add the script as task.
give the user the right to execute the job but NOT to edit or to delete
give a shortcut to the scheduled job (or a runner script) to the user and make a how-to document to show him,/her how the parameter should be used.
I use clear text passwords as temporary testing stuff to make sure users CANNOT use my script (so it is exactly the opposite of your action).
You can capture credential during execution:
$cred = get-gredential -message 'This script needs a real admin user'
Enter-PSSession -Credential $cred -ComputerName 127.0.0.127
You can build a credential (do not store privileged user data):
$user = 'SuchAGreatDomainName\IAmLowPrivilegedUserName'
$Password = 'SuperSecretPassEverybodyKnows'
$secpassword = ConvertTo-SecureString $Password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($user, $secpassword)
Invoke-RestMethod -Uri $Uri -Credential $Credential
Hi I have been trying to deploy model to analysis service by using XMLA script. I used deployment wizard and it worked fine. However when I tried to use command Invoke-ASCmd to deploy model to my analysis server. It got a error of targetinovation which I figured out to be my credential argument error.
The command I used:
$user = "myemail#outlook.com"
$PWord = ConvertTo-SecureString -String "password" -AsPlainText -Force
$Credential = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $user, $PWord
Invoke-ASCmd -InputFile AW.XMLA -Server asazure://southeastasia.asazure.windows.net/azurejenkins -Credential $Credential
But when I not use the -Credential argument it prompt the window email login which work fine. How do I use this command without prompting the user to enter email and password?
Solution to this problem.
I need to create webapp/api in active directory of azure. Copy its application id, tenant id and authentication key which you need to go to keys section in your app.
Go to SQL management server program which connected to your analysis server. Go to security and add app:# in manual entry (in case you don't see your app in the list).
Then use the same command I used in the question but change some components. Change user email to your app id and password to your authentication key. Add tenant id.
Add-AzureAnalysisServicesAccount -Credential $Credential -ServicePrincipal -TenantId $TenantId -RolloutEnvironment "xxxxxx.asazure.windows.net"
Invoke-ASCmd -InputFile xx.XMLA -Server asazure://southeastasia.asazure.windows.net/xxxxxx -Credential $Credential
Hope this script help someone who has the same problem as mine.
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 have a client and a server. The client will call a script like:
#Predefine necessary information
$Username = "Niels"
$Password = "password"
$ComputerName = "192.168.1.51"
$Script = {powershell c:/build/jclbuild2.bat}
#Create credential object
$SecurePassWord = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $Username, $SecurePassWord
#Create session object with this
$Session = New-PSSession -ComputerName $ComputerName -credential $Cred
#Invoke-Command
$Job = Invoke-Command -Session $Session -Scriptblock $Script
echo $Job
#Close Session
Remove-PSSession -Session $Session
On the server the jclbuild2.bat will run and access a network drive like \\otherserver\something, it says access denied if I do this command:
cmd.exe /C copy "\\server\file1.pdf" "\\server2\file1.pdf"
How do I access a network drive from a powershell file on a remote server? The user I use with the $username and $password should have access to the network drive.
I think it's a double hop issue, which I don't know how to solve.
You can't do this using the default authentication mechanism. You need to use an authentication mechanism that allows you to flow credentials, not just identity. Kerberos is one of these. CredSSP is another that is built into Windows starting from Vista/Server 2008 onwards.
I have experience setting up CredSSP. Note that there is some security risk because the target machine will have access to the credentials as plain text.
To set it up you will need to run two commands (both from an elevated shell). One on the machine you are running the above script on (the client) and another on the target that you will be connecting to via remoting (the server).
Enable-WSManCredSSP -Role Client -DelegateComputer $ComputerName -Force
This enables delegation to $ComputerName from the client (note you may have to use the FQDN). For security reasons you should avoid using the wild card '*' although you might consider using '*.mydomain.int' to enable delegation to all machines on the domain.
On the target server
Enable-WSManCredSSP -Role Server
Then when you create the session use the -Authentication flag
$Session = New-PSSession -ComputerName $ComputerName -credential $Cred -Authentication Credssp
There are questions on ServerFault on setting up CredSSP. There is also a blog post here with additional explanation. This post has troubleshooting tips for some commonly encountered error messages.
Another option is to use a delegated session on your server.
Basically, you create a custom remote session that uses the -RunAs parameter to designate the credentials that the session will run under. You can also constrain what scripts and cmdlets can be run in the session and specify who can connect to the session.
In this case, the session would run as the Niels account, and everything done in the session would be under that account authority, regardless of who was connected to the session. From that session, you can now make one hop to another server without needing CredSSP.
This also eliminates the security risk involved in storing that account password in the script file on the client computer.
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/03/use-delegated-administration-and-proxy-functions.aspx