Running in the name of…

In Active Directory, Chef, DevOps, Powershell, Race Against the Machine on February 14, 2015 at 22:28

During my last post I briefly discussed the issues related to the execution context of the chef-client when developing and testing cookbooks. To summarize: on a windows machine the chef-client runs under the context of the local system account, an account which basically is a local admin but has almost no permissions on other Active Directory joined/secured objects ( such as other machines, Active Directory itself or file shares).

You can always mimic this behaviour by just adding a cookbook to a test node’s runlist and restarting the chef-client service of course. Or create a scheduled task which runs chef-solo or zero. However that leaves you without the direct output from an interactively started chef-run. Also I can’t really see how you could add something like that to a vagrant setup.

Luckily – the need to run stuff under the local system account is not new. Quite some time ago the windows tool legend Mark Russinovich developed a tool which also you to, amoungst other things, to start a process as the local system account. In order to do that it temporarily installs a windows service called PSEXESVC which is used to start a process ( eg. cmd.exe) as the local system account.

The command itself is very simple:

somepath:\psexec /s cmd.exe

You can run this from another command window, or Powershell – doesn’t really matter. Once you do it starts another instance of cmd.exe and everything executed from that instance will be run as the local system account. For instance :


Will return:

nt authority\system

From there you can start chef-client just as you normally would – however you will find out that if you access anything outside of the node that access will be denied – unless the permissions on the resource are set to include the computer account object ( which includes Everyone and Authenticated Users btw). Also the output of the chef-client is a little bit different – more like the output that’s written to the chef log when you run the client as a service.

I’ve tried hacking this into the batch files chef uses to start stuff ( so instead of calling ruby.exe directly I would first open a command console as local system when running chef zero) but that didn’t seem to work – I guess that has something to with the difference between a real interactive session and a session as started by psexec. But I’m sure I’ll find some way to work around that at some point.

But for now – if you really want to know if your cookbook will run as you’d expect in a Windows domain environment – use psexec manually at least once in order to identify any permission issues.


P.S – there is one other fun way to run stuff as local system – replacing the ease of access executable on a box 😉 For more details see Guy’s site.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: