Disclaimer: I am not a DevOps guy so please forgive any ignorance. I'm learning this stuff to expand my understanding.
I've enabled remote Powershell on a Windows Server 2019 instance in order to stop/start scheduled tasks during deployment of files from my build server (also Windows Server 2019).
I followed the below steps in an Administrator Powershell as the Adminstrator user on the remote server:
1. Enable RSRemoting.
2. Remove existing listener.
3. Create self-signed certificate and export to crt file.
$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "<subdomain.domain.com>"
Create listener.
Create firewall rules to allow secure PSRemoting and disable unsecure connections.
Copy certificate to build server.
Import certificate on build server.
From the build server, I've tested the configuration using the following commands in Powershell:
$username = 'Administrator'
$pass = ConvertTo-SecureString -string '<password here>' -AsPlainText -Force
$cred = New-Object -typename System.Management.Automation.PSCredential -argumentlist $username, $pass
Invoke-Command -ComputerName <subdomain.domain.com> -UseSSL -ScriptBlock {whoami} -Credential $cred
Which responds nicely with win-<some stuff>\administrator. However, when I execute a remote Powersehll command from within a TeamCity build step, I get a big ugly Connecting to remote server <subdomain.domain.com> failed with the following error message : Access is denied..
The weird part is, this worked two days ago and I have several builds that were able to complete all remote operations. From this morning, it's just stopped working - poof!
If I fudge the credentials, I do get an incorrect username/password error so it is definitely reaching the server.
Another interesting find is that if I run
[bool](Test-WSMan)
on the remote server, I get True returned, but if I run the same command with -ComputerName <subdomain.domain.com> on the build server, I get
WinRM cannot complete the operation. Verify that the specified computer name is
valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits
access to remote computers within the same local subnet. returned.
Both the remote host and build server are logged on as the default Administrator.
Any ideas?
After more research and calling in a few favours, I was advised to tweak the TeamCity Build Agent and TeamCity Server services. These need to Log On As a User and not Local System. I can't explain how my previous settings worked. The Access is denied error I experienced has nothing to do with the Remote Powershell configuration mentioned above.
Related
Been able to do it against Microsoft.PowerShell (5.1), but today I hit a known issue on 5.1 with remote Copy-Item so I installed PowerShell 7 on the remote server (checking "Enable Remoting" in the installer) and am trying to get it working.
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String $Password
$credential = New-Object -TypeName system.management.automation.pscredential -ArgumentList $Username, $securePassword
$session = New-PSSession $targetMachineHostName -Credential $credential -ConfigurationName "Microsoft.PowerShell"
Enter-PSSession $session
Above works. But if I change ConfigurationName to "PowerShell.7.1.0" I get:
[myserver.com.au] Connecting to remote server myserver.com.au failed with
| the following error message : <f:WSManFault
| xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2689860592"
| Machine="myserver.com.au"><f:Message><f:ProviderFault provider="PowerShell.7.1.0"
| path="C:\Windows\system32\PowerShell\7.1.0\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> For more information, see the about_Remote_Troubleshooting Help topic.
On the remote server I've run enable ps remoting in a 7.1 powershell so if I run Get-PSSessionConfiguration it returns a bunch of configurations, including the following:
Name : PowerShell.7.1.0
PSVersion : 7.1
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote
Management Users AccessAllowed
The dll the error refers to exists on the machine.
The user credentials I'm using are for a Local User on the remote machine that isn't an Administrator, but belongs to the Remote Management Users group.
Also worth noting from the remote machine itself (as a different Adminstrator local account, I can start a session to localhost).
After making the user an Administrator I was able to connect, but I'd gone to great lengths earlier to make non-Adminstrator possible on 5.1.
Out of interest, I tried giving the user Full Control to C:\Windows\system32\PowerShell\7.1.0 and then I could connect...
Still would love to know what's going on though and whether I'm doing the right thing or minimum permissions required.
It seems like the minimum security permissions to the folder are:
Read & Execute
List folder contents
Read
Write
Write is bizarre, but without it I get that error. I've assigned those permissions to the "Remote Management Users" group.
Docs here touch a little bit on v5.1 vs v7, and then link to here mentioning an install script so maybe something has fallen through the cracks.
I was getting the same error. I installed PowerShell 7 from Microsoft Store and then ran Enable-PSRemoting. I got this error so I uninstalled it and reinstalled it from WinGet which uses the MSI. That didn't work either. I tried running Enable-PSRemoting again, but nothing changed.
I ran Install-PowerShellRemoting.ps1 and it gave me two errors about things already existing and did not fix the problem. However, I was able to resolve the problem by doing the following:
Delete the PowerShell 7 plugins: Remove-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\PowerShell.7','HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\PowerShell.7.1.1'.
Run Install-PowerShellRemoting.ps1 again.
I'm not sure what the difference was, but deleting and allowing the script to generate it again fixed it for me.
Summary
As part of our build process on DevOps, I'm trying to copy over the build artifact to a specific folder on an internal network share. Problem is, although the build agent is on our internal network, the DevOps service does not have permissions to access any of the network shares.
I think I can get around this by supplying valid login credentials in the PowerShell script that does the work, but I'm having trouble getting the credentials to be accepted. Though viewing the folder structure without credentials seems to be possible, actually making modifications (create/delete files and/or folders) is giving me access denied or authentication denied messages.
What I've Tried
At first, I was doing a very simple create folder command:
# NETWORK_SHARE would be the internal IP of the target public folder on the network, like 12.345.678.90
New-Item -Path "NETWORK_SHARE\path\to\folder" -ItemType Directory
But that was giving me an Access Denied error:
New-Item : Access to the path 'folder' is denied.
Then I did some research and thought that perhaps if I supply the credentials of a valid user, it would allow me to do this. Here's the simple test command. It's supposed to create a new folder in a specified location:
$username = "MyUsername"
$password = ConvertTo-SecureString "MyPassword" -AsPlainText -Force
$credentials = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password
# NETWORK_SHARE would be the internal IP of the target public folder on the network, like 12.345.678.90
Invoke-Command -ComputerName "NETWORK_SHARE" -ScriptBlock { New-Item -Path $args[0] -ItemType Directory } -Cred $credentials -Authentication Credssp -ArgumentList "NETWORK_SHARE\path\to\folder"
The error that I'm getting is the following:
Connecting to remote server NETWORK_SHARE failed with the following error message : The WinRM client cannot process the request. CredSSP
authentication is currently disabled in the client configuration. Change the client configuration and try the request again. CredSSP authentication must also be enabled in the server configuration. Also, Group Policy must be edited to allow credential delegation to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com
It doesn't even look like it's trying to authenticate, it just immediately spits back the error above. I'm not sure how to go about debugging this. I can make changes to the build agent if necessary, but I do not have the ability to change any configuration on the target network share, as that is maintained by the IT team and they are very strict about opening up our drives to the internet. Is there a way to authenticate successfully to create a new folder on the network share without changing any configuration on the target?
I ended up taking a non-Powershell approach to this. Since I had access to the build agent, I configured the DevOps service to run with the credentials of a valid user instead of the default "Network Service" user. This granted the DevOps service all the permissions it needed, and I was able to write a trivial PS script that creates/copies/deletes folders on the network share.
I have created a W10 VM (guest) running docker, pulled microsoft/nanoserver image and hosted a container of the image.
(tutorial here: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_10)
Everything runs great, even host can ping the container running under guest W10. But what i cannot do, is to connect a remote powershell to container.
Enter-PSSession -ComputerName "<container ip>" -Credential ~\Administrator
This pops up a dialog asking for user and password. I cannot leave it blank or etc - the result is access denied. Any ideas how to connect or set a password for nanoserver container ?
I've been struggling with this for a few days now. However, think my problem is slightly different though, as I'm trying to do an Enter-PSSession to a windows docker container, but from another machine, not the container host.
In this tutorial (http://dinventive.com/blog/2016/01/30/windows-server-core-hello-container/), the guy makes a nested container PSSession inside a host PSSession.
He uses this command, which is only available in the latest versions of Powershell. (not in v3)
Enter-PSSession -ContainerId "<container ID>"
Get the ID by doing :
Get-Container | fl
You also have to check your Powershell version and make an upgrade if needed.
To check PS version :
$PSVersionTable
And to download Powershell latest version : https://www.microsoft.com/en-us/download/details.aspx?id=50395
When connecting to a PS-Session using a IP address it adds some requirements, You must either have the remote device configured to use ssl or have the IP address listed in your trusted hosts.
The solution is to either try use the host name for the device, I have had great success with this. Or play with the trusted hosts list. In my experience it works consistently if you add trusted list entries on your machine and the remote machine as well. You can also specify:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*"
This will basically set all machines to be in the trusted hosts list, It has its cons like all machines being trusted but in certain restricted networks its acceptable. Doing this on the host and client machine seems to yield best results.
When specifying -Credentials it expects a credential object, You can craft one before the cmdlet to avoid entering it every time like so:
$secpass = convertto-securestring "Password Here" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "Username Here", $secpass
Enter-PSSession -ComputerName "<container ip>" -Credential $cred
Coding credentials like this in a script is bad practice, You should look in to storing credentials in scripts properly, there are plenty of good resources on it.
I've a commandline program (c#) that encrypts config files based on machine key.
A powershell script copies the build to a Target Server, modifies configs accordingly and installs windows services.
All the windows services run as local system account (standard user, non-admin) - let's call this account "locuser".
The Target Server is a Win 2012 R2 Server. All of the above is achieved by PS remoting from the Build Server to this Target server.
Now, I need to run the encrypt commandline program as "locuser", so that the program can use the account specific key to do the encryption.
I know that this can be easily achieved by calling Start-Process cmdlet with -Credentials parameter. Well, here's the catch, the above works fine, if I remote in (RDP) to the Target Server and then run the Start-Process .... -Credential $cred from a Powershell Console.
However, I need this to be working while I remote-in (using my scripts) to the TargetServer whilst deploying. When I remote-in to the TargetServer I use credentials that has Admin privileges.
I've tried the following
I've granted "locuser" both "Full Control" and "Invoke (Execute)" permissions by using the Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI command. I've run this command for both Microsoft.Powershell and Microsoft.Powershell32 - Still get Access Denied
I've edited the "Local Security Policy"->"Local Policies"->"User Rights Assignment"->Impersonate a client after authentication - and added both the Admin account (that I login with) and the "locuser" account - Still get Access Denied
I've also granted locuser admin rights - Still get Access Denied
I'm pretty sure, there is some configuration on the PS Remoting Side of things that I'm missing out but can't figure out what - because all Powershell throws me is a Access Denied error (see screenshot) with little to no useful information to troubleshoot further.
Also, checked Event logs for any traces but to no avail.
You've fallen prey to the dreaded Double Hop. Basically you're authenticating from computer A to computer B, then trying to authenticate again from computer B to computer C (which also happens to be B in this case).
If at all possible, you would be better off ending the session and starting a new one with the locuser credentials, then just calling Start-Process. Another, more messy approach is to use schtasks.
I can tell you how to do it in the same session but it's a bit messy and very complicated, and should only be a last resort:
On the originating server (Build Server):
Run the command Enable-WSManCredSSP -Role Client -Delegate [name] where [name] is an IP or DNS address / range including any target servers (eg "192.168.1.*")
Open GPEdit.msc, navigate to Computer Configuration\Administrative Templates\System\Credentials Delegation and check that the rules Allow delegating fresh credentials and Allow delegating fresh credentials with NTLM... are enabled and include [name]
On the Target Server:
Run the command Enable-WSManCredSSP -Role Server
Running the command:
Invoke-Command [targetserver] [-Credential $cred] -Scriptblock {
## do stuff
Invoke-Command . -Credential $locusercred -Authentication Credssp -ScriptBlock {
Start-Process -FilePath $sc #etc
}
}
Some things to be aware of:
Firstly I used this setup to create a local session, then remote from there (so A-A-B instead of A-B-B) so the Group Policy stuff might be in the wrong place but pretty sure it's right.
Secondly I found that credentials are a pain to get working in sessions (in this case $locusercred). I did get it going natively but weirdly it suddenly couldn't decrypt the securestring. I ended up saving a securestring with a defined key to the registry so it can always be decrypted from any account, you may need to come up with your own solution there.
All this stuff is explained in the free eBook "The Secrets of PowerShell Remoting", if you go for the double-hop approach I recommend giving it a read.
I have a WiX MSI installer for an ASP.NET website that runs on my_server. The package is installed via a very simple Powershell script install.ps1 that just calls msiexec with some parameters.
The problem
When I run install.ps1 directly on my_server, everything is fine. But when I want to run install.ps1 on my_server from a remote machine (e.g. build_server), the installation fails with error code 1603 and the MSI install log reveals the the following error:
Action start 14:22:30: ConfigureUsers.
ConfigureUsers: Error 0x80070005: failed to add/remove User actions
CustomAction ConfigureUsers returned actual error code 1603
Any suggestions?
Extra information
I run install.ps1 remotely with the following command:
Invoke-Command -ComputerName my_server -ScriptBlock { path\to\install.ps1 } -Authentication Negotiate
I use the same user credentials on both my_server and build_server.
In the WiX definition, the website is set up with a specific user account for the app pool, like this:
<Component Id="AppPoolCmp"
Guid="a-fine-looking-guid"
KeyPath="yes">
<util:User Id="AppPoolUser"
CreateUser="no"
RemoveOnUninstall="no"
Name="[APP_POOL_IDENTITY_NAME]"
Password="[APP_POOL_IDENTITY_PWD]"
Domain="[APP_POOL_IDENTITY_DOMAIN]">
</util:User>
<iis:WebAppPool Id="AppPool"
Name="[APP_POOL_NAME]"
ManagedPipelineMode="Classic"
ManagedRuntimeVersion="v4.0"
Identity="other"
User="AppPoolUser">
<iis:RecycleTime Value="5:00" />
</iis:WebAppPool>
</Component>
This is likely to be the double hop issue, your credentials are not valid beyond the scope of the first server.
Can you do the command with the option:
-Authentication CredSSP
Rather than Negotiate.
You will also need to specify credentials manually using the -Credentials flag as well as set up the client and server for CredSSP:
Enable-WSManCredSSP -Role Client -DelegateComputer HOSTNAME -Force
Enable-WSManCredSSP -Role Server -Force
The steps are explained in more detail here.