PowerShell Remoting without administrator rights

• Author
• Recent Posts

Michael Pietroforte

Michael Pietroforte is the founder and editor in chief of 4sysops. He has more than 35 years of experience in IT management and system administration.

Latest posts by Michael Pietroforte (see all)

• Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
• Pip install Boto3 - Thu, Mar 24 2022
• Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022

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 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

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

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

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
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

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

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

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}

Conclusion

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.