chucknorris/dropkick — pull request #58 by mmooney (2013-11-04 21:46:02+00:00)
Title: Ability to provide username/password for remote administrator account

This is a second (better) attempt at https://github.com/chucknorris/dropkick/pull/56.

It's more complete, plus I had screwed up the other pull request and included some code from another feature.

The core change is to add an option WMI username/password to the WmiHelper.Connect method, so that you can impersonate an administrator account on the remote machine.

This is necessary in scenarios like Amazon EC2 where you don't have domain users who have access to multiple boxes. Instead you usually have local administrator accounts on each machine.

What's included:
- The WinService methods have been expanded to take a WMI user name and password. If provided, they will use the WmiService class instead of ServiceController to manage the service. If those credentials are not provided, it will use the existing ServiceController code (obviously it would be better to use the same code for both situations, but I was trying to reduce the chance of introducing any issues)
- There is a OpenFolderShareAuthentication task, which will takes a UNC and user account credentials, and will open a share with those credentials. After that point, anything accessing the remote system (like XmlPoke, CopyDirectory, SecurityOptions.ForPath, etc) will automatically use that net share session.

What's not included (yet):
- IIS management - Since ServerManager doesn't take a username and password, and I'm pretty sure LogonUser/ImpersonateUser won't work, another (more complicated approach) would be required. In the meantime, since the IIS setup is usually a one-time thing, I think the current enhancements have a lot of value even with the IIS stuff.
- SecurityOptions.LocalPolicy - I tried to find a way to pass credentials to the LsaUtility/LsaSecurity stuff, which not very well documented, but was unsuccessful. Again, this is usually one-time setup, I think these changes are valuable (at least to me) without the local policy stuff.

Testing:
- I copied the existing WinService tests to test them against a remote VM. The first time you run the tests, it will give you an error that you need to create a settings file (with the machine name, user name, and password). For my testing, I spun up a dumb Amazon VM for this purpose, which I'd be happy to give you guys access to if you wanted to test it out. Otherwise, I'll spin it down and save the AMI in a public place so it could be used for future testing. ALSO, setting up the remote WMI access in Amazon is no trivial task, so I wrote up the steps in a blog post: http://mooneyblog.mmdbsolutions.com/index.php/2013/11/01/accessing-an-amazon-vm-through-wmi/
- In the comments of the original PR, I had mentioned pulling the static WMI classes apart into some instance objects, so that they could be testable/mockable/etc. I got pretty far into this, but it was REALLY invasive, rewriting large chunks of the WMI code, and it was almost certainly going to introduce more bugs that it was fixing. So instead, I put in the some integration tests
- Also my main goal is to get this working so that my Team City build server (in Amazon) can publish an application to another Amazon EC2 instance. Coincidentally the application it is deploying is a automated deployment system (like Octopus, but with some differences). Anyhow, I've been dogfooding it by using this branch to deploy that application. If you wanted to see it in action, the code is at https://github.com/mmooney/Sriracha.Deploy, and the DropkicK code is in the Sriracha.Deploy.SelfDeploy project.

Thanks,
Mike