You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to this post the above key is not created when the machine is in a domain - the problem is, a machine being prepared as an image template is rarely in the domain when commands to open up winrm are run shortly after boot, and I'm wondering if it then persists after domain join (especially since a lot of materials mention putting together a policy to force it off). Some of these concerns are covered here: https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/
So far it looks like the only reliable way to handle resetting wsman is to boot a pristine system, export the wsman registry hierarchy, edit the export file to add a deletion of the entire hierarchy (as the first line) and the above two registry keys. Then use this to reset the registry. It seems like this will cover both winrm quickconfig and enable-psremoting
The trouble is,
the pristine statemight be OS specific
so then it would be difficult to make this approach scale for a generally available public package
There are some other challenges with the rest of resetting as well - including multiple approaches to opening up the firewall.
The text was updated successfully, but these errors were encountered:
@SteveL-MSFT (and @LeeHolmes) - I used systemexplorer (https://chocolatey.org/packages/systemexplorer) to snapshot the registry and file system before configuring winrm and after running the following two reset commands:
These commands do make changes - but definitely do not return to a pristine state. Most concerningly they leave the following registry keys intact:
According to this post the above key is not created when the machine is in a domain - the problem is, a machine being prepared as an image template is rarely in the domain when commands to open up winrm are run shortly after boot, and I'm wondering if it then persists after domain join (especially since a lot of materials mention putting together a policy to force it off). Some of these concerns are covered here: https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/
So far it looks like the only reliable way to handle resetting wsman is to boot a pristine system, export the wsman registry hierarchy, edit the export file to add a deletion of the entire hierarchy (as the first line) and the above two registry keys. Then use this to reset the registry. It seems like this will cover both
winrm quickconfig
andenable-psremoting
The trouble is,
There are some other challenges with the rest of resetting as well - including multiple approaches to opening up the firewall.
The text was updated successfully, but these errors were encountered: