Use WinRM for Windows management

[jamiees2]

I just wanted to pitch using this: https://github.com/diyan/pywinrm instead of winexe for windows management.

Using Winexe along with windows shares is a fairly hacky solution, and Microsoft has already made this (relatively) cool API for managing windows machines remotely, and pywinrm looks like a fairly mature implementation.

If this seems like a good idea, I can get to work on implementing it straight away.

[Kami]

I agree with you that it would be reasonable to switch a backend implementation to pywinrm (it's also something we have discussed before).

When I did the initial research, winexe seemed like a most stable (albeit hacky) and portable solution, but this doesn't really seem like the case now. Another reason was that WinRM is not available by default in the older versions of Windows server.

In any case, a pure Python solution is definitely always preferred over "spawning a process" or library with C extensions approach and pywinrm fits that bill :)

In short - yes, this change will likely happen some time in the next couple of months, but we don't have an ETA right. Good thing is that the "public" API should stay more or less the same (we will probably just get rid of the share parameter).

[jamiees2]

Yes, exactly. For what i'm working on right now, I actually need this, so if you don't mind, I could get to work on this straight away and send a PR?

[Kami]

Yeah, a PR would be great and appreciated.

We are also working on hooking up some end to end tests for Windows runners right now. Since the public API should stay more or less the same, those tests should also pass with the changed backed implementation.

This should help us increase confidence and make sure this are still working like they should.

[dzimine]

Go for it.

On Jun 16, 2015, at 07:25, James Sigurðarson notifications@github.com wrote:

Yes, exactly. For what i'm working on right now, I actually need this, so if you don't mind, I could get to work on this straight away and send a PR?

—
Reply to this email directly or view it on GitHub.

[Kami]

@jamiees2 Have just had the time / made any progress on this yet? Need any help?

[jamiees2]

I went on vacation for a week, but I have been looking into it, but had alot of trouble getting pywinrm to work. I'm not sure if it is my setup (a network of computers under a single domain controller), or if it is an issue with pywinrm.

[jamiees2]

Sorry for the slow updates, but I have been getting back to work. Currently, I'm looking into the possibility of ditching WinRM altogether, and instead write a script in python which accepts HTTP requests from a specific server containing PowerShell scripts and executes them.

I have already written the basic code for the server: storm-executor, and am currently working on the runner.

I am at least convinced that this is the way to go for my purposes(although I am not sure in general). This may add some security issues, which can possibly be mitigated by using IP filtering, or HTTP authentication. In a proper server space, sysadmins are probably very capable of limiting this in the firewall. In some sense, it might be easier to tune the security settings of this, than for WinRM.

My problem with WinRM was that it didn't support double-hop, which this resolves. I was trying to set up a CentOS machine running StackStorm alongside a Windows machine running as a slave to the machine for all PowerShell tasks, which included remotely managing other windows machines. The current setup at my workplace doesn't really allow for a different solution(except maybe running StackStorm on Windows). After some research, I realized I either needed CredSSP support, or something along the lines of this. CredSSP isn't open, so I couldn't find a linux implementation of it.

PyWinRM has fewer of the problems than with the current winexe approach, but still isn't optimal. I would suggest distributing an easy to run windows executable which does this.

[Kami]

Thanks for the update.

I agree about the server / agent approach. I would like to avoid doing that for the general use case. Doing the agent approach correctly and securely is not trivial and takes time. You can of course hack something up quite fast, but that thing probably won't be secure and efficient.

We created and maintained our own agent for Rackspace Cloud Monitoring product (https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent) and there were multiple people working on the project for quite a long time before we released a first version. Granted, we had some specific requirements (HA, low memory and resource usage, secure signed auto updates, etc.) and we also made specific technology choices (Luvit) which added a lot of overhead and substantially slowed things down, but what I am trying to say is that even if we scoped it down, doing it securely would still take a lot of time and we simply don't have the bandwidth for it right now (and probably in the future as well since this wouldn't really be a one time thing, but something we need to maintain and keep up to date).

As far as using server / agent approach for yourself and writing a custom non-official runner - we are totally fine with that and we can also help there.

The code will most likely require some changes to allow you to register a custom runner locally, but those are good changes and something which is generally applicable and useful.

[jamiees2]

I agree. I had a long discussion with the sysadmins at work before I got started, and they said it would be fine, and they could review it after I was done. This is just a demonstration for work though. For efficiency, I believe the same thing could be written in C/C++.

I am not sure I agree that doing it securely requires a lot of work, if the script is kept simple, then the attack vectors are minimized, and restricting traffic to come from the IP of a specific server is fairly trivial in most web frameworks. That aside, the only vulnerability I can think of is local privilege escalation, which can probably be fixed similarly. I'm not a security researcher, so I might have missed something, but as I said, minimizing the attack surface makes security simple. For other attacks, from looking into it, I can't seem to find many attacks which WinRM isn't vulnerable to, but this would be.

Actually, the best long term solution would be to figure out a way to run StackStorm on Windows, which might be ok, from my research, I saw that most dependencies should work, but that would almost require a fork, and most bash/ssh runners wouldn't work.

But it is an ongoing project :) and most likely in the future something better will come along and allow us to do things properly instead of constant hacking. Windows 10 supports SSH, which is perfect for what we're trying to do, but it just came out yesterday :v. In a year though, I imagine that that, along with someone probably backporting the client will allow for much better windows-linux integration.

[jamiees2]

Actually, another note, I just tested an SSH server for windows, and found that it worked! I tried this one: http://www.kpym.com/2/kpym/index.htm

[jamiees2]

Also tried this one: http://www.freesshd.com/ , Works much better :)

[daBONDi]

A WinRM Solution i think would be the best, MS Invested heavily in WinRM and the underlying Powershell, and it will not go away i think.

Someone Tryed that ?
http://www.powershellserver.com/

[daBONDi]

Thinking about writing an agent in .net core as powershell host service with an json api and an api key for authentication and it returns the Powershell Objects as json result to overrule all the dependencies on winrm and ssh and so on...

Stackstorm > Action > http call > Powershell Host Service(API Key Auth) > Executing Local as a Powershell Host > Result > Json Convert > http response > Action Result in Stackstorm

[Mystere]

Hmm.. any progress on this?