Warning: Disabling the session configurations does not undo all the changes made by the Enable-PSRemoting or Enable-PSSession Configuration cmdlet. You might have to manually undo the changes by following these steps:

Michael Pietroforte

Michael Pietroforte is the founder and editor of 4sysops. He is a Microsoft Most Valuable Professional (MVP) with more than 30 years of experience in IT management and system administration.
  1. Stop and disable the WinRM service.
  2. Delete the listener that accepts requests on any IP address.
  3. Disable the firewall exceptions for WS-Management communications.
  4. Restore the value of the LocalAccountTokenFilterPolicy to 0, which restricts remote access to members of the Administrators group on the computer.

Note: In a new wiki doc, I covered all the details you need to know to disable PowerShell remoting properly.

Disable PSRemoting does not undo all the changes made by Enable PSRemoting

Disable PSRemoting does not undo all the changes made by Enable PSRemoting

If you've ever tried to disable PowerShell remoting, you've probably scratched your head after you ran the Disable-PSRemoting cmdlet. Since when is disabling no longer the reversal of enabling? Why doesn't Disable-PSRemoting simply do what its name implies?

The technical reason is that enabling PowerShell remoting requires a few security-related changes that might also be necessary for other services in your network. For instance, the WinRM service is also required for managing servers remotely with Server Manager. This also applies to the WS-Man listener, the firewall exceptions, and the LocalAccountTokenFilterPolicy. Thus, if Disable-PSRemoting just quietly performed the recommendations in this warning message, it might break other services.

However, the real reasons involve Microsoft's wrong design decisions in the past. They introduced Windows Remote Management (WinRM) during the web services hype era. The service never played an important role in remote management until PowerShell started to rise. Hooking PowerShell remoting into a service designed for remote management seemed to be a good idea at that time.

"Firewall friendly" was one of the catchphrases during those times. Whoever invented this phrase most likely was not a security expert, because "firewall friendly" essentially means "security unfriendly." Heck, we have firewalls to determine what protocols and services we'll allow through. The inventors of the internet protocol must have had something in mind when they provided the TCP protocol with port numbers. Microsoft had to correct this mistake later and changed the port numbers from 80 and 443 to 5985 and 5986.

However, the deeper design error is the idea of sharing resources among services as much as possible. The phrase "DLL hell" comes to mind. The reason why virtualization and containers are so popular these days is because they help us separate what never belonged together.

What was originally conceived of as a way to optimize the usage of hardware resources now has the opposite effect. Virtualization now consumes enormous resources in our datacenters because multiple instances of the same OS code runs simultaneously on the same hardware. If we had properly designed operating systems (Linux is better here, but not by much), nobody would need virtualization technology, and Disable-PSRemoting would just disable remoting.

Coming back to PowerShell remoting, it was a mistake to tie the command-line language to WinRM and use HTTP as the protocol for remote connections. It appears Microsoft is also about to correct this error in PowerShell Core and use SSH instead, which is certainly better equipped for the task.

The issue with LocalAccountTokenFilterPolicy is another story. First of all, the warning message from Disable-PSRemoting is misleading to say the least. The problem behind this warning is that UAC gets in the way of PowerShell remoting because the security feature is designed for graphical environments. This essentially requires disabling UAC to make PowerShell remoting possible. The LocalAccountTokenFilterPolicy registry entry controls this on workgroup machines.

This means you have less security in place in remoting sessions than when you are logged on locally. It's not really security friendly. Hackers love to exploit such configurations in so-called loopback attacks. I hope that one day Microsoft will also replace UAC with something like sudo. "Just Enough Administration" or JEA is a start, but it's too complicated to configure (and therefore rarely used), and it only applies to PowerShell.

The main problem of these warning messages is that most busy admins will just ignore them. After all, it is just a yellow warning and not one of those intimidating red error messages. The upshot is that unneeded services and weak security settings stay in place in most networks. Even though running Disable-PSRemoting removes the right to connect remotely to session configurations, the WinRM service with its listeners is still exposed on the network.

Thus, I recommend that you take these warning messages seriously. I explained all the details you need to know in a new wiki doc about disabling PowerShell remoting. If you can improve the document, please sign in and edit it.

Win the monthly 4sysops member prize for IT pros


Related Posts


Leave a reply

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



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

© 4sysops 2006 - 2018

Log in with your credentials


Forgot your details?

Create Account