-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Approach To Facilitate Community Contribution for Undo-WinRMConfig #1
Comments
@DarwinJS you should invite https://github.com/manojampalam to this repo as although he's best known for the OpenSSH port, he's also the expert and one of the owners of WinRM |
@SteveL-MSFT - Done! I also edited my original comment on this thread to simplify to just Pristine .REG files for each OS. If and only if everything can't be done by .REG files we can add back the ability to process .ps1's per OS as well. I am also doing snapshots of where changes for commands like "Enable-WsmanCredSSP" and "Enable-PSRemoting" go so we know if they are covered by reseting the WSMAN reg key or if they have other changes they've made. Getting my list of commands by collecting common methods for configuring winrm for packer. Storing that source info in the repo under the Research folder. /cc @manojampalam |
Please read https://github.com/DarwinJS/Undo-WinRMConfig/blob/master/CONTRIBUTING.md to find out about a fast, simple, compatible registry / file systems snapshot utility. |
First release is done: https://github.com/DarwinJS/Undo-WinRMConfig/releases/tag/v1.1.8 |
It looks like this is going to be an exercise in reverse engineering.
I've done a lot of that, but I don't really have the bandwidth to do it for every Windows OS out there. I work more with server OSes and from Server 2012 R2 and later.
So I would like the community to be able to easily add undo configurations for Windows versions they
need to engineer it for (e.g. Server 2008 R2).
So this is what I am thinking for a possible approach:
I will be trying to publish the undo profiles for Server 2012 R2 and Server 2016 soon.
If the complexity of handling individual OSes goes beyond what can be done in a .REG, we can add .PS1 execution to the mix.
I am hoping this will:
Yeah, Yeah I Know
While technically the above approach does arbitrary code execution - I think the very special circumstances under which this code will be used (on a nearly pristine system that has just been automated for an initial image setup) makes the likelyhood of an "in use" attack. If someone can attack you at that time - then the won't need to use this code to get in.
Why Use This Package If You have Such a Code Set for Each Variant?
/cc @SteveL-MSFT, @LeeHolmes
The text was updated successfully, but these errors were encountered: