By default, to connect to a remote computer using PowerShell (PowerShell Remoting) you need administrator privileges. In this article, we’ll show how to allow remote connection using PowerShell Remoting (WinRM) for common users (without administrator privileges) with the help of a security group, a Group Policy, and modification of the PoSh session descriptor.

When trying to create a PowerShell session with a remote computer as a non-privileged user account (Enter-PSSession lon-srv1) an access error occurs:

Enter-PSSession : Connecting to remote server lon-srv1 failed with the following error message : Access is denied.

Remote Access to WinRM and Remote Management Users Group

Check the standard permissions of the PoSh session:

(Get-PSSessionConfiguration -Name Microsoft.PowerShell).Permission

As you can see, the access is allowed for the following built-in groups:

1. BUILTIN\Administrators — AccessAllowed,
2. BUILTIN\Remote Management Users — AccessAllowed

So, to let a user connect to a remote machine through WinRM, it’s enough to be a member of the built-in local group of administrators or Remote Management Users security group (this group is created by default starting from PowerShell 4.0). This group also has access to WMI resources via management protocols (e.g., WS-Management)

A user can be added to the group using Computer Management snap-in:

or using the command:

net localgroup "Remote Management Users" /add jsmith

If ?you need to provide such permissions on multiple computers, you can use Group Policy. To do this, assign the GPO to the computers you need, and add the new Remote Management Users group to the Computer Configuration -> Windows Settings -> Security Settings -> Restricted Groups policy. Add to the policy users or groups that need to be granted access to WinRM.

After a user becomes a member of the Remote Management Users group, he can create a remote PowerShell session using Enter-PSSession or run commands using the Invoke-Command cmdlet. User privileges in this session will be limited to user rights on this machine.

Make sure if the remote connection is established.

Security Descriptor of PowerShell Session

Another way to quickly give a user permission to use PowerShell Remoting without including him to the local security group Remote Management Users is to modify the security descriptor of the current Microsoft.PowerShell session on the local computer. This method will allow to quickly grant temporary (till the next restart) remote connection rights to a user via PowerShell.

The following command displays the list of current permissions:

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

In this dialog window, add a user or group and grant them Execute (Invoke) permissions.

After you save the changes, the system will prompt for confirmation and restart of WinRM service.

If you have to automatically modify the security descriptor (without GUI), you will need to make changes manually first and then to get the current access descriptor in SDDL format.

(Get-PSSessionConfiguration -Name "Microsoft.PowerShell").SecurityDescriptorSDDL

In our case, the command returned the following descriptor:

Then you can use this SDDL string to grant access to PowerShell on any other server or workstation.

$SDDL = “O:NSG:BAD:P(A;;GA;;;BA)(A;;GXGR;;;S-1-5-21-2323243421-3342677354-2633435451-55422122)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)”
Set-PSSessionConfiguration -Name Microsoft.PowerShell -SecurityDescriptorSddl $SDDL

Remote Hyper-V Management Also Needs WinRM Privileges

In Windows 10 /Windows Server 2016 to connect to a Hyper-V server remotely using Hyper-V Manager, PowerShell Remoting began to be used. Thus, by default remote users without administrator privileges won’t be able to manage the Hyper-V server, even if they have the corresponding permissions in Hyper-V.

When trying to connect to the Hyper-V server as a common user from a computer running Windows 10, the following error appears:

An error occurred while attempting to connect to server “server1”, Check that the Virtual Machine Management service is running and that you are authorized to connect to the server

To allow a remote connection to the console, it’s enough to add a Hyper-V user to the local group Remote Management Users in the same way.