I'm looking for help to properly configure PowerShell Remoting for non-admins on a group of servers. Right now we have a working configuration that allows Admin Domain accounts to successfully connect to the servers with no error. The authentication method we are using is Credssp, using SSL and this works perfectly for a Domain admin account.
On the other hand I have this User Domain Account userTest. This account is mapped to a Domain Group that maps locally (on each server) to the Remote Desktop User Groups. This allows for this user to RDP successfully to this server but has no administrator privileges. It is going to stay that way and it is not an option to make it Local Administrator.
The purpose of this user is to allow non-admin accounts to execute a set of scripts against the server using a Restricted Session, which connecting with a Domain Admin Account. The problem comes when I'm trying to connect with the userTest account. The server responds with a Access is Denied error:
[ServerA] Connecting to remote server ServerA failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (ServerA:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken
Going trough the Analytic EventLogs I found an error message as follows:
The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered.
This is the configuration that I have already setup:
Created a PSSessionConfiguration named RemoteDesktopUsers
Register-PSSessionConfiguration -Name RemoteDesktopUsers -StartupScript C:\Start.ps1
Set-PSSessionConfiguration -Name RemoteDesktopUsers -ShowSecurityDescriptorUI
(Added Remote Desktop Users group to this SessionConfiguration)
So yeah, basically from what I have already Googled, this should be all the necessary configuration that you need to able to PSRemote with non-admin accounts. As I already mentioned using a Domain Admin Account connecting to this SessionConfiguration works fine, so I was thinking that I'm missing some kind of permission/privilege/SDDL that allows this user to access:
Windows Server 2008 R2 SP1
Powershell 4.0
Winrm ProductVersion = OS: 6.1.7601 SP: 1.0 Stack: 3.0
You're probably running into this problem because of using CredSSP
Any particular reason you have to use CredSSP? The most popular use of CredSSP is provided for situations in which you need to configure a jump server to remote from one machine, into another, and from there out again to another server. It's well-known as Second-Hop funtionality and is such a huge security hole that the CredSSP is kind of a pain to configure, intentionally.
You have to configure CredSSP in three places, once on your machine from which you'll be remoting, then again on the machine you'll be jumping to, and finally on each machine you'll be connecting to from the jump server.
If you really have to use CredSSP, follow this great guide here on The Scripting Guy's blog.
If you don't need CredSSP
Try this whole process using Default/WSman authorization, and I bet the problems will go away.
Related
I set up the remote development over SSH from my windows 10 machine to one of our new Windows 2022 servers. This due the fact that I need to use an other account with extra permissions to be able to run the script on the server.
Everything works fine, I can do 'remote development' over SSH with the other account and write & test powershell code on the server.
When I try to contact an external source in my script (like a fileshare or SQL), I noticed the dreaded "Double-hop" problem pops up.
As the first hop is SSH and not a real WinRM session, I thought this wouldn't be a problem?
Can I force VsCode/Powershell to not see the SSH connection as the first hop?
Or is this something Microsoft changed/enforced for security reasons?
By the way, I'm using Powershell 7 on both client and server
Whether SSH or WinRM, it's the OS on the first jump box that knows this is a remote session. If you want to be able to pass credentials off to a second box you'll need to look into enabling CredSSP.
To enable on your Windows server:
Enable-WSManCredSSP -Role server -Force -ErrorAction Stop
This should then allow you to access secondary servers. We do this to support a number of things; example: remoting into box A, and making box A grab some software from box B to do an install.
Always disable CredSSP afterwards:
Disable-WSManCredSSP -Role server -ErrorAction Stop
We have 7 Terminal Servers, and for some reason, I can only use Invoke-Command on those two, when the domain administrator is logged on to the servers.
I will get this error, when I try to use Invoke-Command on them, when the domain administrator isn't logged on to them. The other 5 servers have no issue.
As soon as I log in with the remote administrator, it works flawlessly.
[RDH004] Connecting to remote server RDH004 failed with the following error message : The WSMan service could not launch a host process to process the given request. Make s
ure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (RDH004:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : 2,PSSessionStateBroken
I did doublecheck if the service Windows Remote Management (WS-Management) was running. And I did create a GPO (Allow remote server management through WinRM) to allow remote connections.
Did the same thing, on all servers to attempt to enable it. All servers are a clone from the same template in ESXi. And all servers are running Windows Server 2016.
I've searched far and wide for solutions, but none of the solutions seem to be the same problem. Especially not, since it works if the server I'm trying to send a remote command to, has the domain administrator logged in.
The cause of this issue is due to the Windows User Account Control (UAC). The remote account must be a domain account and a member of the remote computer Administrators group. If the account is a local computer member of the Administrators group, then UAC does not allow access to the WinRM service. This error happens even if the account is a Local Administrator and the command line is run with administrator privileges.
To solve the problem, UAC filtering for local accounts must be disabled by creating the following DWORD registry entry and setting its value to 1:
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] LocalAccountTokenFilterPolicy
Additional Information
https://learn.microsoft.com/en-us/windows/win32/winrm/obtaining-data-from-a-remote-computer
I have an on-premises network and an Azure virtual network that are connected together via a gateway.
With this setup, all machines (on-premises and Azure) are joined to the domain which allows me remote access to the administrative shares as well as remote Powershell sessions on each machine in the Azure virtual network from machines in my office. For example, I can simply open up Windows Explorer and type in the address bar \\machinename\c$ or I can open a remote Powershell session by using the command $Session = New-PSSession -ComputerName machinename.
This works perfectly for one of my Azure subscriptions, but on another Azure subscription that appears to be configured identically, the remote Powershell command is failing with error:
New-PSSession : [machinename] Connecting to remote server machinename failed with the following error message : WinRM cannot process the request. The following error occurred while
using Kerberos authentication: Cannot find the computer machinename. Verify that the computer exists on the network and that the name provided is spelled correctly. For more information,
see the about_Remote_Troubleshooting Help topic.
When I look in DNS on the Azure domain controller, the machine that I am trying to connect to exists. When I look in DNS on-premises, the machine is missing. What it looks like to me is a replication problem between the two domain controllers.
The first thing that is likely to be suggested is to start looking at WinRM configurations on the client machine. To be clear, the same machine is able to connect successfully to machines in a virtual network in a different Azure subscription so it is very unlikely that anything on the client machine needs to be changed. Nevertheless, I Googled the Kerberos error with remote Powershell and have checked that the TrustedHosts setting on the client is set to *.
Interestingly enough, I can successfully open a remote Powershell session from a machine in the Azure subscription to a machine in my office, I just can't go the other direction....from Azure to my office. This would seem to indicate maybe a one-way trust instead of two-way, but I am not sure how to verify this.
I ran the tool and it is reporting that everything is working with regard to replication.
So I guess what I am wondering is if this is truly a replication issue or if someone can give me an idea of what the problem might really be.
Edit 1
Now it looks like the domain controller in the Azure network is replicating just fine but any other VM that I add to the Azure network is not replicating. Based on this I will guess that the replication is working, but it would seem it only works for the domain controller and not any other machine. I have no idea what that means.
Based on the error message, it seems that the DNS records on Azure domain controller are not replicated to the on-premises domain controller.
To verify this, you can run the command below on the on-premises machine, and use the IP address as the value of parameter -ComputerName instead of the machine name. The PowerShell session should be established successfully if this is a DNS issue.
New-PSSession -ComputerName IP address of server on Azure
Also, you can run the following commands on the domain controllers to check the replication status.
repadmin /kcc
repadmin /replisummlry
If the output of commands are successfully, you can run the following command to replicate manually, and check the DNS again.
repadmin /syncall
Finally, to check the trust relationship, you can refer to the following link for step-by-step guide.
https://technet.microsoft.com/en-us/library/cc753821(v=ws.11).aspx
Update
Based on the new information you provided, I would recommend to check the type of DNS zone on the Azure DNS server. Please make sure the type is Primary zone, and store the zone in Active Directory.
You can check this by using the DNS Manager.
My laptop is domain joined and I use PSRemoting just fine from my office. I get an error when trying to connect outside the office via VPN. I have triple checked our firewall but the issue seems to be with the client or server since "Test-WSMan" succeeds with no issues. I have added the machines to each others' trust hosts and try many other things with no success. Please help!
I am a member of Domain Admins and the laptop is on the domain.
Enter-PSSession : Connecting to remote server SERVERNAME failed with the following error message : WinRM cannot
process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: The
are currently no logon servers available to service the logon request.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or
use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession SERVERNAME
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (SERVERNAME:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed
From the issue, my understandings are as follows:
While adding the trusted hosts, you should add the servers with FQDN like
Set-Item wsman:\localhost\Client\TrustedHosts -Value Server01.Domain01.Fabrikam.com
During Enter-PSSession, I would recommend you not to use the Kerberos as -Authentication, you can use default since its a domain admin account.
I believe the ports are open from the network side since you have already done that. But make sure to cross-check the state of the port; Its listening properly or not.
I believe these points will help you. Normally, VPN doesnot give this much issue unless the hops are really complicated.
I have three windows 2008 R2 servers; DEV, UAT and Live. I am deploying web apps between these servers, including IIS setup and config and database backup and restore via a PowerShell script. I use a powershell remote session.
I would like to prevent any machine, other than my deployment machine, from creating a powershell remote session on the host, even if the user is authenticated. Is this possible?
I have looked extensively through the PSRemoting documentation and can't find anything helpful.
Thanks in advance
Read the below link to better understand what needs to be done but I think you need to set the trusted host on the remote servers.
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2008/02/23/remotely-managing-your-server-core-using-winrm-and-winrs.aspx
This is an excerp from the blog.
On the Windows server Core box
Run the following commands on the console of the Server Core box to lower security:
WinRM set winrm/config/service/auth #{Basic="true"}
WinRM set winrm/config/client #{TrustedHosts="<local>"}
WinRM set winrm/config/client #{TrustedHosts="RemoteHost"}
Where RemoteHost is the host you want to be able to connect to the server.
You can also use certificate-based authentication.
http://blogs.msdn.com/b/wmi/archive/2009/03/23/how-to-use-wsman-config-provider-for-certificate-authentication.aspx
If you only want your computer to be able to connect, install the certificate on your computer and don't give it to anyone else.