Running on Windows

Archives Ansible Project
, ,
1

Hi folks,

Almost for as long as this thread exists, I've been following it from a far and thinking about ways to use Ansible with Windows.

Steve Irvine has put forth some DevOps PowerShell code. I think using the built-in system is probably a good idea.

But how can you call that from a Linux/Unix box with python/Ansible if you need/want it ?

The problem is how do you do what Michael DeHaan mentioned about not requiring to install anything on the target machine.

Well, in the Windows world there is this tool called PsExec from System Internals (a company aquired by Microsoft):

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Here is a description of how it works:

"PsExec allows redirects of the input and output of a remotely started executable through the use of SMB and the hidden $ADMIN share on the remote system. With this share, PsExec uses the Windows Service control Manager API to start the PsExecsvc service on the remote system which creates a named pipe that PsExec communicates with. This named pipe is what allows for input/output redirection back to the system that launched PsExec."

http://www.windowsecurity.com/articles-tutorials/misc_network_security/PsExec-Nasty-Things-It-Can-Do.html

The good thing about PsExec is it doesn't need any changes on the target Windows machine, you can connect to it with a default install. And the parts it depends on is usually not disabled. You only need some username/password combination (maybe it also possible to use some password-less Kerberos protocol for authentication I don't know).

There is only the firewall on a default install that could get in the way, but if the Windows-machine is part of a Windows-domain and you are on the same network there are no firewall settings to change. it just works.

Turns out there is a Python-project that use pcap to create, send and receive packets of certain protocols, including SMB, called impacket.

And they include a PsExec equivalant:

https://code.google.com/p/impacket/source/browse/trunk/examples/psexec.py

And I just did a quick test and you can use it on your Debian box to run a command on a Windows 2012 machine.

I've use PsExec with Windows before, I believe it also works with Windows 2008 and even Windows 2003.

The packages for impacket in the Debian and Ubuntu stable releases are to old though.

You'll need to download the release from the impacket site.

The other Python packages it depends on can be used from the stable release:
python-crypto
python-pcapy

Hope this is helpful somehow.

Have a nice day,
  Leen.

2

Leen:

It’s great to know a tool like this exists. I’ve been suffering with Windows Remote administration stuff since PowerShell remoting only works from a Windows client, and my laptop runs OS X, so I’ve had to do all remote administration using a Windows VM.

Do you know if the impacket project supports copying files via PsExec?

Lorin

3

Leen:

It's great to know a tool like this exists. I've been suffering with
Windows Remote administration stuff since PowerShell remoting only works
from a Windows client, and my laptop runs OS X, so I've had to do all
remote administration using a Windows VM.

Lorin,

Using PsExec seemed like a good idea, until I figured out that SMB isn't encrypted of course.

So it isn't equivalent to using SSH.

So you end up at PowerShell again, which to me seems to use WinRM/WinRS. It uses the WS-Management
Protocol which are encrypted SOAP-XML-messages over HTTP on a special port.

My guess is if something will be part of Ansible and use impacket then it would only be used to do the
initial setup, run some commands to configure WinRM/WinRS if needed.

It should be possible to create some kind of PowerShell client, it's 'just' SOAP messages, but not the
simple kind.

As far as I know there is only 1 open source implementation that can talk the WS-Management Protocol,
which is written in C and uses the Curl-library:

https://github.com/Openwsman/openwsman/wiki

I don't think it implements PowerShell yet though.

The bigger problem with PowerShell is, I don't know how best to automate PowerShell authentication
yet without storing a username/password somewhere or having to type it every time.

It does support using HTTPS with client certificates. But as far as I could see that doesn't seem
to be used for authentication, that is just the for connecting/encryption.

Adding a Linux-machine to the Windows-domain and using Kerberos seems to be the only way.

Do you know if the impacket project supports copying files via PsExec?

impacket is basically using SMB, so Windows filesharing, you can even use impacket
to build a mini SMB fileserver, so even without looking into it I assume you can
use SMB to transfer the files.

I would be surprised if it isn't possible to use PowerShell to transfer files.

4

> Leen:
>
> It's great to know a tool like this exists. I've been suffering with
> Windows Remote administration stuff since PowerShell remoting only works
> from a Windows client, and my laptop runs OS X, so I've had to do all
> remote administration using a Windows VM.
>

Lorin,

Using PsExec seemed like a good idea, until I figured out that SMB isn't encrypted of course.

So it isn't equivalent to using SSH.

So you end up at PowerShell again, which to me seems to use WinRM/WinRS. It uses the WS-Management
Protocol which are encrypted SOAP-XML-messages over HTTP on a special port.

My guess is if something will be part of Ansible and use impacket then it would only be used to do the
initial setup, run some commands to configure WinRM/WinRS if needed.

It should be possible to create some kind of PowerShell client, it's 'just' SOAP messages, but not the
simple kind.

As far as I know there is only 1 open source implementation that can talk the WS-Management Protocol,
which is written in C and uses the Curl-library:

https://github.com/Openwsman/openwsman/wiki

I don't think it implements PowerShell yet though.

The bigger problem with PowerShell is, I don't know how best to automate PowerShell authentication
yet without storing a username/password somewhere or having to type it every time.

It does support using HTTPS with client certificates. But as far as I could see that doesn't seem
to be used for authentication, that is just the for connecting/encryption.

You might be able to use a client-certificate to authenticate as a local user:

http://blogs.msdn.com/b/wmi/archive/2009/03/23/how-to-use-wsman-config-provider-for-certificate-authentication.aspx

Adding a Linux-machine to the Windows-domain and using Kerberos seems to be the only way.

If authentication as a local user is possible, authentication on a domain controller/active directory server
might mean logging in as a domain user. As a domain controller does not have local users.

I would need to do some tests before I know what works.

5

Hi folks,

I would need to do some tests before I know what works.

Well, didn't have a chance to do some testing.

I did make a little progress.

I found a few open source implementations of 'powershell remoting' and I'm now mostly sure what the authentication and
encryption possibilities are with using PowerShell.

PowerShell basically supports these protocols and methods of authentication and encryption:
- HTTP authentication, Kerberos, NTLM, Basic
- encrypted SOAP messages with encryption derived from Kerberos-authentication, based on the 'wrapping' function of the GSS-API.
- HTTPS for encryption
- HTTPS with SSL/TLS client certs for authenitcating as a local user, when you configure it, you need to at least supply a certificate, username and password, and the name of part of the certificate Subject.

I've found out that zenoss has a Python implementation which can talk to PowerShell remotely (I've not tested it).

It does seem to support Kerberos, but doesn't support Kerberos encrypted SOAP-messages though, so there is an issue now:

https://github.com/zenoss/txwinrm/issues/1

I would really like to hear from some other people what they think might be a good model to persue.

Maybe I'm wrong, but it seems to be Kerberos-encrypted messages seems to be Microsoft favorite method.

But it obviously is not going to work for Windows machines that haven't been added to a Windows domain yet or even will never be added to a domain.

So far I only see one method to bootstrap a machine if you don't want to send a username and password over the network and want to be able to setup encrypted communication with a fresh machine that isn't part of a domain yet, but need to add it to an existing domain.

- use username/password of a local user with administrative rights with PsExec method with NTLMv2 auth to setup HTTPS-listener of PowerShell Remoting with a self-signed cert
- connect to it with HTTP-authentication with username/password of that same account over HTTPS
- add the machine to the domain, by sending a username/password of a domain user with administrative rights
(reboot the machine)
- setup the HTTP-listener by connecting over HTTPS again
- use Kerberos-authentication and Kerberos-encrypted messages to communicate with the machine over HTTP for all the messages after that because you probably want to login as a domain user to run commands.

This has far to many steps, but I don't see any other way to automate this or how to setup password-less login.

Anyone have any, hopefully better, ideas ?

Michael ? Do you think such a model could be used to eventually integrate with Ansible in some shape or form ?

Or maybe Windows/pPowerShell at least is just to different ?

Have a nice day,
  Leen.

6

I think assuming it has already joined the domain is perhaps a reasonable thing to do, at least for a first step.

It seems most people would be using something like WinPE to boot machines at least somewhat preconfigured.

7

If the machine is joined to a Domain (which you can do in your WinPE/WDS deployment environment) then Group Policy can be used to do the bootstrap bit. Its the way I was able to configure powershell for remoting when I was doing this stuff.

I guess one could even write a firstrun script with your setup steps (join domain, enable winrm etc etc) and stick it in Runonce in the registry before you sysprep & image your machine.

Kind of breaks the no-bootstrap thing though.

8

OTOH, it’s windows, and it’s a starting point.

Should someone wish to try to write a windows connection plugin, I think that would be pretty interesting even with that as a starting point.

9

OTOH, it's windows, and it's a starting point.

Should someone wish to try to write a windows connection plugin, I think
that would be pretty interesting even with that as a starting point.

Is there some information how Ansible and Kerberos fit together right now ?

Because if I'm not mistaken Ansible supports Kerberos already, if not indirectly, right ?

10

Ansible supports Kerberos via “-c ssh”, where openssh supports Kerberos, basically :slight_smile:

11

I’ve been going back and forth on this many times, psexec looked like a good connection plugin but then you still need python and json on windows and a way to bootstrap. Getting raw to work didn’t seem hard, but remote installing python …

Cygwin gives us some of the tools (ssh + python + posixyness) but is itself a pain to setup on scale (unattended?).

last thing i was looking at was wmi, with the wmic linux C program, its all remote and would ‘work’ (setup/gather facts was very easy) but requires re-implementing all modules and it becomes more remote and less ‘execute at target’.

In all cases most base module have to be redone or at least have major re-factoring to allow for windows particulars on the user, group, files, permissions and services levels.

At this point I’m considering that the solution is “ansible-win”,a dedicated tool that works mostly the same (probably can use most of the base api) but needs it’s own modules, plugins, etc, that should be able to use wmi,powershell, cygwin and psexec. Probably using something like ‘unattended’ as a pkg manager. Unless windows 8 app store adds this, has an API and has all the apps you’ll need (not holding my breath).

12

Yeah, I know what you mean, the philosophy of native tools and no bootstrapping makes it more difficult for stuff to be cross platform.

I think our windows hosts will need to be prepared with python and json and a few other bits as well.

I was wondering if we could leverage fireball at all for part of this? At least that would handle the transport using code that’s already written and part of Ansible. If we make sure our windows hosts already have python plus the 0mq prerequisites, then we just need to work out how to start a 0mq listener at the right time with the right keys. Which might be achievable using psexec or powershell.

13

I just thought of something, there is WinExe, I’ve used this once and is appears to be psexec for Unix.

http://sourceforge.net/p/winexe/wiki/Home/

It worked the one time I tried it. Maybe we could use this to execute 0mq in Python on Windows and then we have our command channel.

I guess it might pass the 0mq keys in cleartext which would be a security hole.

14

“but then you still need python and json on windows and a way to bootstrap. Getting raw to work didn’t seem hard, but remote installing python …”

This is not the way it needs to happen.

If this happens, it will transfer Powershell and parse … something. Whether that is INI output or JSON output or XML or whatever, we can do that on Ansible side. No need for Python.

We are DEFINITELY not going to do Cygwin or a separate tool, and things need to stay agentless.

I’m willing to allow some bootstrapping here in terms of configuration settings.

15

We will not be using fireball on Windows.

A native solution here would be a requirement.

16

I think that remote powershell would be the best way to acheive the
native connection. To my knowledge an out of the box windows machine
handles it this just fine (not certain, but I don't think it needs any
firewall opening either).

I've been researching sqlcmd and the sqlps module, I should be able to
provide something more detailed this week but my initial thought is
that a module built over powershell would extend nicely. It's
different for everyone I think because environments that use windows
more heavily, tend to use their full feature set from AD, GPO, WSUS or
WDS.

MS priorities imo :

Firewall
MSSQL
Files
IIS
Active directory

-luke

17

Yep, this is precisely what we should do!

(and the only thing I’d accept, if that makes it a little more clear)

18

Something else I was thinking about, I think this would require a
central ansible windows server to execute. Unless there is a way to
port powershell to linux (lol?). 0MQ would probably have the potential
to solve the agent type of deployment, it does have a windows
installer but I agree that the agentless priority is my favorite
feature of ansible.

If it was me, I'd want a single small resource to handle this. FINALLY
a reason to use the windows server core mode!!!

19

No to 0mq.

Need to find a way to execute remote powershell.

20

Clarifying, remote powershell is the priority. I'm doubt there will
ever be a way to get powershell to work on linux... so the small
windows vm would still be a requirement in the implementation?