By default, you require administrator rights to connect to a remote computer via PowerShell. In this post, I explain how to set the permissions for PowerShell Remoting to give non-administrators remote access with the help of Group Policy and by changing the default PowerShell session configuration.
Latest posts by Michael Pietroforte (see all)

Why PowerShell Remoting without admin rights

Some people would argue that requiring administrator rights for PowerShell Remoting is good for security. They believe that allowing remote PowerShell access is a security risk, and the hurdles should therefore be as high as possible. Jeffrey Snover called this secure by default.

In my view, the opposite is true. It reminds me of the days when every Windows user who had the right to log on also had full administrator’s privileges. I guess nowadays no IT pro would claim that this was a good thing. If someone had to write the 10 Commandments for IT security, the principle of least privilege would be right at the top. The UNIX world always valued this principle (Microsoft valued it only since introducing User Account Control [UAC] in Windows Vista); therefore, users without root privileges can remotely connect to Linux machines via SSH by default.

What makes things even worse is that, in its default configuration, PowerShell Remoting even circumvents UAC, thereby turning the clock backward with regard to security.

The point is, of course, that not everyone who needs remote PowerShell access also requires full administrator privileges. I suppose you don’t want to promote helpdesk personnel to administrators just because they have to query remote computers via PowerShell. Windows comes with very sophisticated rights management features, and I see no reason for PowerShell users to be excluded from the security guidelines of your organization.

Allowing access to PowerShell Remoting with Group Policy

If standard users try to create a remote PowerShell session, they will receive an error message telling them that access is denied:

PowerShell Remoting - Access is denied for a standard user

PowerShell Remoting – Access is denied for standard users

I skimmed through quite a few blog posts before I wrote this article, and the solutions to the problem are surprisingly complicated (most articles predate Windows 8). Usually, they recommend changing the security permissions of the default session configuration (also called standard endpoint). I will discuss this option in a minute, but let’s look first at a much simpler solution.

When I said above that, by default, you have to be an administrator to work with PowerShell Remoting, I only told you half of the truth. Let’s check the default permissions:

PS C:\> (Get-PSSessionConfiguration -Name Microsoft.PowerShell).Permission
BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

You see the other half of the truth after the comma. The built-in security group Remote Management Users is also allowed to use the default session configuration to create new PowerShell sessions. (Note that the group was added with PowerShell 4.0.) Thus, all you have to do is add users to this security group.

Adding a user to Remote Management Users

Adding a user to Remote Management Users

This also grants the user access to WMI resources over management protocols (such as WS-Management) on the machine where you added the user to Remote Management Users.

If you want to do this for many computers, adding a single user to a local security group is not the best option. I would rather create a new domain group (perhaps “PowerShell Remoting”) and then add the group to the Remote Management Users group on all machines where you want to allow PowerShell Remoting with the help of Group Policy Restricted Groups.

Allowing PowerShell Remoting for standard users with Group Policy

Allowing PowerShell Remoting for standard users with Group Policy

This will allow all users in the PowerShell Remoting group to create remote PowerShell sessions on the computers to which you apply the policy and where PowerShell Remoting is enabled. These users can then enter remote PowerShell sessions with Enter-PSSession or run commands remotely with Invoke-Command. However, their privileges will be restricted to the rights they have on the corresponding machine.

Note that the Remote Management Users group exists only on computers running Windows 8 (or Windows Server 2012) and above. If you are still running Windows 7 and Windows Server 2008, you have a problem (one of many).

Allowing PowerShell Remoting by changing the session configuration

In most cases, I think the procedure described above is all you need if you want to grant non-administrators access to PowerShell Remoting. However, the method may have a downside. Another purpose of the Remote Management Users group is to allow users to remotely manage computers with Server Manager and RSAT. Thus, if you enabled Server Manager remote management (Configure-SMRemoting.exe -enable), users of the Remote Management Users groups will be able to connect via Server Manager.

However, because they don’t have administrator rights, their privileges are heavily restricted. For instance, they can read AD objects with Active Directory Users and Computers (ADUC), but they can’t modify them. With the method described below, you can work with your own local group; however, as far as I can see, the users will have essentially the same rights. The only difference I noticed is that Server Manager reported “access denied” instead “Online Data Failures occurred.”

An advantage of modifying the session configuration is that you can quickly grant a single user access to PowerShell Remoting on a single machine without requiring the user to log off:

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

After you confirmed that you are sure of your actions, a dialog window will appear where you can add the user. Make sure that you grant at least permission to execute/invoke.

Changing PSSessionConfiguration to grant PowerShell remote access

Changing PSSessionConfiguration to grant PowerShell remote access

Of course, the GUI makes things difficult if you want to automate the procedure. Unfortunately, it appears that no straightforward way exists to avoid the dialog window. Set-PSSessionConfiguration offers the -SecurityDescriptorSddl parameter for this purpose, which expects a security descriptor in the Security Descriptor Definition Language (SDDL) format.

In short, the security descriptor can be assigned to all kinds of Windows objects, such as files, folders, and—you guessed it—PowerShell session configurations. It determines the permissions users and groups have on the object to which you assign the security descriptor. The SDDL string is supposed to be the human-readable format of its binary counterparts. This is how you can display the default PSSessionConfiguration SDDL string:

PS C:\> (Get-PSSessionConfiguration -Name "Microsoft.PowerShell").SecurityDescriptorSDDL

You can’t read this? Then maybe you are not human. Essentially, it says that the Administrators group and the Remote Management Users have full control. If you want it to be a bit more precise, you convert the SDDL string into parsed format that can also be read by ordinary mortals with Matthew Graeber’s ConvertFrom-SDDL filter. You can copy the filter from here.

Converting a security descriptor in SSDL format into a parsed descriptor

Converting a security descriptor in SSDL format into a parsed descriptor

To modify the permissions, you are supposed to understand SDDL. Even though this is easier than the above output might make it appear (this post helps you get started), it might be overkill if you want to change the permissions on a couple of computers with a script.

The simplest way I know is to simply use the -showSecurityDescriptorUI parameter of Set-PSSessionConfiguration to assign the permissions you need (as demonstrated above). Then, you read the corresponding SDDL string and apply it on the other machines in your Active Directory domain:

$SDDL = (Get-PSSessionConfiguration -Name "Microsoft.PowerShell").SecurityDescriptorSDDL
Set-PSSessionConfiguration -Name Microsoft.PowerShell -SecurityDescriptorSddl $SDDL

I didn’t find a function that would allow you to convert from an easy-to-read format to SDDL. However, you can use Anders Wahlqvist’s Add-PoShEndpointAccess function to add users and groups to session configurations on remote computers. There is one little hiccup. The function requires that the Credential Security Support Provider (CredSSP) is enabled on the remote machine.

CredSSP allows you to delegate the authentication to another computer. In our case, authentication is delegated to the remote machine where you want to modify the session configuration. You enable CredSSP remotely this way:

Invoke-Command -ComputerName "myRemotePC" -ScriptBlock {Enable-WSManCredSSP -Role server}

After you have loaded the Add-PoShEndpointAccess function (for instance, by executing it in PowerShell ISE), you can add a user remotely this way:

Add-PoShEndpointAccess -SamAccountName "myDomain\myUser" -ComputerName "myRemotePC"

Remotely allowing a user access to PowerShell Remoting

Remotely allowing a user access to PowerShell Remoting

You will receive a warning that you have to restart the WinRM service. However, in my case, that wasn’t necessary. Just in case:

Invoke-Command -ComputerName "myRemotePC" -ScriptBlock {Restart-Service WinRM}


PowerShell is not secure by default because it encourages organizations to give administrator privileges to users who don’t really need them in their remote PowerShell sessions. However, ways exist to change the default configuration. Unfortunately, giving non-administrators access to PowerShell Remoting is more complicated than it had to be.

Another problem you might face is that you may sometimes want to give non-administrators particular privileges that usually only administrators have. Instead of promoting these users to administrators, you can work with constrained endpoints. I will cover this topic in my next two posts.

  1. Avatar
    Jay Adams 7 years ago

    You can also delegate PowerShell scripts through a tool like System Frontier. You’ll also get a full audit trail and many other features. With a few clicks, you can have it automatically build a GUI for your script that will collect user input and pass it to the command-line for execution against a remote host.

  2. Avatar
    viki 4 years ago

    how can I execute winrm command in windows 7 with non admin privelages

  3. Avatar
    Mani 4 years ago

    Thanks for the response.

    But as I mentioned:

    If I log on to the machine directly using the same non-admin account (through RDP) then I am able to execute the command.

    So the command does not need admin rights when executed locally.

    What could stop it from running when executed through PS remoting is what I am trying to figure out.

    I appreciate your help.

  4. Avatar
    Axel LIMOUSIN 4 years ago

    # Without CredSSP

    $SAMAccountName = 'MyDOM\MyGroup'
    $SID = (New-Object System.Security.Principal.NTAccount($SAMAccountName)).Translate([System.Security.Principal.SecurityIdentifier]).Value
    $ACE = 'Execute'

    $ComputerName_List = @(',')
    Invoke-Command -ComputerName $ComputerName_List -ArgumentList @($SID,$ACE) -ScriptBlock {

        switch ($ACE)
                    $ACE_Str = "(A;;GR;;;{0})" -f $SID

                    $ACE_Str = "(A;;GW;;;{0})" -f $SID

                    $ACE_Str = "(A;;GX;;;{0})" -f $SID

                    $ACE_Str = "(A;;GA;;;{0})" -f $SID

        $ACE_Str = $ACE_Str + 'S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)'

        $Name = 'Microsoft.Powershell'
        $SecurityDescriptorSddl_Str = (Get-PSSessionConfiguration -Name $Name -ErrorAction Stop).SecurityDescriptorSddl

        $SecurityDescriptorSddl_Str = $SecurityDescriptorSddl_Str -replace 'S:P\(AU;FA;GA;;;WD\)\(AU;SA;GXGW;;;WD\)',$ACE_Str
        Set-PSSessionConfiguration -Name $Name -SecurityDescriptorSddl $SecurityDescriptorSddl_Str -Force -Confirm:$false
        Restart-Service WinRM

    Prefx : O:NSG:BAD:P
    Administrators: (A;;GA;;;BA)
    Remote Management Users: (A;;GA;;;RM)
    Sufx : S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

  5. Avatar
    Mani 3 years ago

    I have enabled PS remoting for a non-admin account. I am able to run wmic and PowerShell commands but not this particular command:

    wmic service get

    If I log on to the machine directly using the same non-admin account (through RDP) then I am able to execute the command as this command.

    How do I enable the execution of the command remotely? Please explain.


  6. Avatar
    Monty 2 years ago
  7. Avatar
    Jake 2 years ago

    I am seeing some unexpected results running remote commands such as invoke-command, with admin rights vs just the Remote Management Users right.

    When running an invoke-command {get-child-item -path c:\test} with a non-admin user that has been added to "Remote Management Users" the query takes 11 seconds for a folder with one file in it.

    Running the same command from the same machine in a different powershell window running with a user with admin rights on the remote machine produces the result in less than a second.\

    Seems like a bug to me.


    • Avatar Author

      When it comes to bugs, we can usually assume that Microsoft is guilty until proven innocent. However, in this case it could be that you have an authentication issue. Are you working in an AD domain? Perhaps your local machine is unable to connect to a domain controller. I would try a similar procedure without PowerShell. For instance, you can try to connect to local shares in Explorer with involving local groups and a domain account.

  8. Avatar
    Kav 11 months ago

    Thanks, finally a solution that is simple!

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account